Introducing Grafana Alloy, A Distribution of the OTel Collector | GrafanaCON 2024 | Grafana

[@simon3121]

Of course it has to come with it's own config file syntax. Because there are too few to choose from. So a dedicated VScode plugin is needed.

[@jakemana]

Perfect video and presentation! Thank you.

[@kwesikwaa]

does alloy replace prometheus node exporter for example?

[@godpa8083]

it does

[@kwesikwaa]

@@godpa8083 wow thanks

[@hugosxm]

And windows exporter too ;)

[@kwesikwaa]

@@hugosxmthank you. it is a lot of tools from grafana and it is easy to lose track. i just realised this replaces agent. i am trying to wrap my head around how theres prometheus exporters, and then agent and now this. and also promtail for loki. it is a lot of pieces. if this puts all together then that cuts out the confusion.

[@kwesikwaa]

@@godpa8083 thank you

[@LieberLois]

Two very great presenters! Thank you for the great presentation and congrats to the release of v1.0.0. Two (at least for me) unanswered questions: - Why not an Operator? I get that it requires effort to maintain, but it also takes away much operational effort, which can be critical for Observability when things get rough - The presentation didn't really show the benefits when compared to the official OTEL collector. Could you maybe follow up on this? :) Again, thank you very much guys!

[@Grafana]

Hi there! To answer your first question - why not an operator?: The built in components for service and pod monitors handle most of the shared functionality. By being in the shared binary allows for easier development and testing. It also simplifies the clustering capabilities. And for your second question - What are the benefits over the official OTEL collector?: Full support for prometheus and loki pipelines. Also Alloy native components help with security. For example remote.vault and using the windows certificate store. Additionally the Alloy runtime allows for constant evaluation if keys or values change this allows a more responsive dynamic application.

[@m19mesoto]

Now not only we have the bizarre Grafna agent all-in-one Swiss knife, but we also have the second generation..of the same confusion.. I remember open telemetry was the way to instrument your application to support any vendor metrics format.. Now we have open format with opinionated collectors.. great, we are just right where we were in the beginning.. Do one thing but do it right, how cares I have to deploy 6 agents instead of one, if we have the right automation, also putting all ribbits in a single bucket is never a good idea.

[@AlexGGSandro]

How is this better? with OTEL we have pipelines that connect all components together. Tha makes mangaement of config easy. With Alloy if you need to insert or remove something from the chain you always going through obscure breaks. Then one config file for all make literally 0 sense, single Prometheus scrapping in Alloy format is way too verbose, add loki and otel and this is complete mess no one understands. And this is a new iteration of the same idea as in Grafana Agent! The need of such agent is there but you are not making life easier for us, you are making it harder. (I understand that this make it easier for Grafana to sell the service). I beg you, please reconsider the approach!

[@east4ming]

In my opinion, Alloy's philosophy is somewhat similar to Dynatrace's OneAgent.