-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
opentelemetry-collector vs grafana-agent #642
Comments
Hi, thanks for your question. The Grafana Agent is strongly tied to the Prometheus ecosystem and its related projects, which we've picked for its history of stability and performance under high load. The tie to that ecosystem gives it a narrow focus, centering around first-class support for Prometheus, Cortex, Grafana Loki, and Grafana Tempo. Relying on stable protocols allows us to solve higher-level problems such as the out-of-box user experience. Grafana Agent ships with a set of 11 Prometheus exporters (tools that expose metrics), allowing you to collect metrics from common applications without having to install extra tools. The Grafana Agent defers to Grafana for interaction with telemetry data from tools outside of the Prometheus ecosystem. The OpenTelmetry Collector has a much broader scope, aiming to translate telemetry data from multiple input and output protocols. Adding this translation within the collector allows users to arbitrarily switch between backend projects and vendors. However, the translation adds necessary complexity, and is very challenging to do in a completely generic and correct way. For example, the Prometheus team recently reported that the OpenTelemetry Collector is not currently compliant with the Prometheus remote_write protocol. The OpenTelemtry team is working on fixing the compliance issues. OpenTelemetry is split into different categories. At the moment, only its Traces signal is ready for use. Given its strong adoption, the Grafana Agent uses it for collecting spans to send to Grafana Tempo. Both projects have an interest in scalability. The Grafana Agent currently supports sharding your telemetry ingestion load (scraping service, hashmod, host filtering), with a focus on being able to scale both inside and outside of Kubernetes. OpenTelemetry is working on scalability too, but within the context of Kubernetes by using an Operator. Hope this helps! |
Thank you so much for your detailed explanation. |
This is good. Maybe add it as a README.md/FAQ.md? |
hi @RichiH , today grafana agent also can collect metrics、logs and traces, so what‘s the really defferent between them. |
Just to update, I believe OpenTelemetry Collector is now compliant with the Prometheus remote_write protocol: https://prometheus.io/blog/#agent-collector In addition to tracing, as mentioned above, it also looks like metrics is ready to use (although support depends on which language-specific SDK you need): https://opentelemetry.io/docs/reference/specification/status/ |
hi @modulitos thank your comment. I do a test with OTel Collector ( receiver is prometheus, exporter is prometheusremotewrite) , but I found the Collector don't support here is my test code https://github.com/grafanafans/prometheus-exemplar/blob/remote_prometheus/config/otel-collector.yaml#L7 |
Hi all, a lot has changed since my original comment last June. As noted, OpenTelemetry Collector is now fully compliant with the remote_write protocol. The OpenTelemetry Collector contrib distribution also now contains integration-like receivers, such as the MySQL receiver. Grafana Agent still remains primarily interested in providing first-class support for sending telemetry data to Prometheus, Grafana Loki, Grafana Mimir, and Grafana Tempo. We do this by using upstream code directly, allowing us to avoid potential tradeoffs one might find in OpenTelemetry Collector's approach of converting everything into a common format. However, we are considering changing our strategy for how we support OpenTelemetry Collector. Stay tuned for an announcement later this month. As a small spoiler: we are considering allowing users to optionally use all of OpenTelemetry Collector inside Grafana Agent. This would give users the choice of which ecosystem to use, either opting for the native ecosystem (like Prometheus) or a generic one (like OpenTelemetry). I'll post back with an update later this month once we've made that announcement. The announcement should make it more obvious what the future of Grafana Agent looks like and how it'll be possible for us to enable OpenTelemetry Collector as an option. |
|
Thanks @rfratto for the follow-up. Aside from Flow mode (which is a much nicer DX than static mode) and the Web UI (which is also very nice), what advantages does Grafana Agent have over OTEL Collector for Grafana users (assuming they're all in on OTEL)? |
What's the main difference between opentelemetry-collector and grafana-agent projects?
Thanks 🙂
The text was updated successfully, but these errors were encountered: