New Sink: stdout

[JustAnotherDevOps]

trafficstars

Is your feature request related to a problem? Please describe. Previously I have used eventrouter to write the kubernetes event API logs out to stdout and then pick them up in another monitoring tool to trigger events. With eventrouter no longer being maintained and the comments thread on https://github.com/vmware-archive/eventrouter/issues/126. I came over to Robusta to find a maintained project which could fulfil the same function.

Describe the solution you'd like An additional sink to be able to route events from the Kubernetes API to stdout.

Describe alternatives you've considered I've had a look at a few alternatives and there doesn't appear to be much available which meets the above.

Additional context Link to the stdout sink for eventrouter

[aantn]

Yes, it's a good idea.

Do you want to write all events or only specific ones? From stdout where are you sending them?

[JustAnotherDevOps]

I'd say give the options for both to allow more configuration. For my use case I'd still look to use the triggers and actions in conjunction with the sink but set it on_event_all_changes to capture all of the event outputs.

There are quite a few monitoring systems which advise to set up eventrouter to stdout then scrape the logs. E.g. Honeycomb.io.

I originally considered asking for a sink to Honeycomb but figured there are likely others in my situation using other tools given the popularity of what eventrouter provides.

[lictw]

Any updates? I also interested in ability to gather all events, not just warnings, filter them and send to slack for logging purposes.

[aantn]

Slack or stdout?

On Mon, 16 Jan 2023, 5:50 Tw1ce, @.***> wrote:

Any updates? I also interested in ability to gather all events, not just warnings, filter them and send to slack for logging purposes.

— Reply to this email directly, view it on GitHub https://github.com/robusta-dev/robusta/issues/393#issuecomment-1383442040, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADYUBZE4H2SCRVP6LH2R2DWSTAR5ANCNFSM5ZKWH3TA . You are receiving this because you commented.Message ID: @.***>

[lictw]

I think it's just about a new trigger for all severities, on_kubernetes_event_create for ex., and after that any capability action and sink can be used like with other ones.

[arikalon1]

We already have triggers for any event:

    on_event_all_changes
    on_event_create
    on_event_delete
    on_event_update

Is that what you need?

[lictw]

Yes! Maybe I'm blind, but the documentation miss this, thank you!

[lictw]

@arikalon1 I found it in the docs along with other standard resources, so, it seems that special for warning events field include doesn't work for this triggers like for other 'resource' (pod, job, node, etc) triggers, right? Or can I filter this all events?

What I need: I use similar to Flux's controller without such (as in Flux) notifications, and want to implement this notifications with Robusta (along with other things, Robusta is really great!). I just need a stream in some channel about all controller's events, just to check that it works after changes. Cause this I need Normal events too. I can fill include with all available reason, but better to have filter by kind of event's producer.

Also, can you understand me in small description how this events actually works? What is create, update event? Flux's controllers produce messages after each reconciliation, every minute for ex., but Kubernetes seems doesn't create an event from every message.. Does the first message of same Reason produce new (create) event, while when only message changed with same Reason it's considering as update? So delete when a new event with different Reason created?

[arikalon1]

Hi @lictw

As you described, the include option is only available for warning events. The *_create, *_update, *_delete for for the operation on the k8s api server. For example, when a pod is created, there will be a pod create event. When deleted, a pod delete event. the *_all means to run on any operation. create/update/delete

K8s has a resource kind which is called Event. (Pod is a kind, Deployment is a kind etc)

Regarding the flux notifications, when would you like to be notified? After flux is changing a Deployment? Something else?

[aantn]

@JustAnotherDevOps would love to get any feedback on the new sink.