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

Say hello to Grafana Alloy! Grafana Labs’ distribution of the OpenTelemetry Collector brings together the very best of OTel and Prometheus to offer a truly optimized hybrid experience, especially when paired with Grafana Cloud.

Grafana Alloy uses components to build observability pipelines for telemetry collection, processing, and delivery. In this session, Senior Software Engineers Matt Durham and Paschalis Tsilias dive into the core concepts around Alloy and its configuration language, explore its new debugging capabilities, and show how to migrate to Grafana Alloy. They also discuss Grafana Alloy’s position in the OpenTelemetry landscape, its role as a collector, and how you can use it to collect OTel signals in parallel with your existing infrastructure.

You will learn how to build OTel-native and hybrid pipelines using the supported OTel components.

Chapters:
0:00 Introduction
2:36 Say hello to Grafana Alloy
4:32 Alloy configuration syntax
5:13 Alloy components
6:04 Programmable pipeline architecture
8:25 Native Kubernetes support
11:43 OpenTelemetry phase (demo)
16:00 How Alloy supports clustering
18:57 Modules in Alloy
25:24 Fleet management

Helpful links:

-----
👍 If you found this video useful, be sure to give it a thumbs up and subscribe to our channel for more helpful Grafana videos.

📱 Follow us for the latest and greatest on all things Grafana and our other OSS projects.

#Grafana #Observability #Alloy #OpenTelemetry #Prometheus

[betterwithrum]

Woof, these two are why companies have technical marketing teams that are able to present a topic clearly

[simon]

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.

[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!

[kwesikwaa]

does alloy replace prometheus node exporter for example?

[mmesoto]

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.

[eastming]

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

[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!