How does Alloy relate to OTel Collector?

Grafana Alloy
1

I’m starting to investigate migrating from Promtail to Alloy - given that the former is being deprecated in favour of the latter. However, as a newcomer to Alloy (but having previously done some work with OTel Collector) I’m struggling to understand exactly what Alloy is.

At Grafana Alloy | Grafana Alloy documentation it says:

Grafana Alloy is a vendor-neutral distribution of the OpenTelemetry (OTel) Collector.

That immediately begs several questions:

  1. Is Alloy a fork of OTel Collector?
  2. What are the differences between Grafana Alloy and the standard distribution of OTel Collector?
  3. Why should I use Alloy instead of OTel Collector?
  4. In what sense is Alloy “vendor neutral”? Is this implying that somehow the standard OTel Collector is not?
  5. To what extent are they compatible, or configurations interchangeable?

It looks to me like they’re completely different. The OTel Collector configurations are in YAML with a particular structure (receivers, processors, exporters, service pipelines to connect them). The configuration snippets for Alloy look like HCL to me, although I can’t find anywhere that actually says so. Rather it is described as “Alloy configuration syntax”. [EDIT: I found the older Grafana Agent documentation called it River and says it’s HCL-inspired, but it’s now officially “Grafana Alloy configuration syntax.”]

It has a different structure with “configuration blocks” and “components”, where each component has “forward_to” to connect it to the next, and introduces its own concepts such as “capsules”.

Hence I’m struggling to see the relationship between Alloy and OTel Collector.

Another issue is: I’m currently using promtail to receive syslog and forward to loki. If I search for “syslog” in the Grafana documentation, I find loki.source.syslog.

  1. Why is this module specific to loki? Is it essentially an import of the promtail syslog receiver code?
  2. Is it only compatible with other loki components? For example, can I only modify the message using loki.process?
  3. How does this differ from the OTel collector’s own syslogreceiver?
  4. I can’t see the OTel syslog receiver in the otelcol components of Alloy, so is loki.source.syslog the only choice available in Alloy? (If so, that would tie Alloy rather closely to Loki, which seems to go against the “vendor neutral” claim)

Sorry if I’m being dense here. If there’s a more detailed description of how Alloy relates to OTel Collector, please point me at it (I couldn’t find one).

Thanks, Brian.

2

I am not an Alloy expert, but I’ll try to answer your questions best I can.

1. Is Alloy a fork of OTel Collector?

No it’s not.

2. What are the differences between Grafana Alloy and the standard distribution of OTel Collector?

I think this mostly comes down to configurations and how things are done.

3. Why should I use Alloy instead of OTel Collector?

The biggest reason we use Alloy is simply because it’s provided by Grafana, who also provides Loki. And we had a bit of experience with Grafana Agent flow mode already (the predecessor of Alloy), so it wasn’t much work for us to migrate. Hopefully others with more knowledge can chime in, but this might just be a preferene thing.

4. In what sense is Alloy "vendor neutral"? Is this implying that somehow the standard OTel Collector is not?

I think it’s just the fact that Alloy tries to support OTel collector and other standard protocols such as prometheus.

5. To what extent are they compatible, or configurations interchangeable?

Alloy supports OTel protocol, configurations are not interchangeable.

Hence I'm struggling to see the relationship between Alloy and OTel Collector.

There is no relationship between the two other than Alloy attempting to also support OTel protocol.

1. Why is this module specific to loki? Is it essentially an import of the promtail syslog receiver code?

I am not sure what you mean by this. It wouldn’t make sense to have a syslog receiver for prometheus would it?

2. Is it only compatible with other loki [components](https://grafana.com/docs/alloy/latest/reference/components/loki/)? For example, can I only modify the message using `loki.process`?

Yes, Loki components are compatible with Loki components, I believe.

3. How does this differ from the OTel collector's own [syslogreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/syslogreceiver/README.md)?

Limited experience with OTel, can’t comment.

4. I can't see the OTel syslog receiver in the [otelcol](https://grafana.com/docs/alloy/latest/reference/components/otelcol/) components of Alloy, so is `loki.source.syslog` the only choice available in Alloy? (If so, that would tie Alloy rather closely to Loki, which seems to go against the "vendor neutral" claim)

syslog receiver is not an OTel thing. It’s a protocol that’s been around long before. So I am not sure why you’d expect OTel 's syslog receiver in Alloy, when it has its own.

At the end of the day it’s a preference thing. Pick what works best for you.

1 Like
3

No, but it would make sense to have a syslog receiver which accepts generic syslog messages and then forwards them to some destination other than Loki (e.g. Kafka, Clickhouse, InfluxDB, syslog over TCP, upstream OTLP receiver etc)

If the only syslog receiver in Alloy were the Loki syslog receiver, and if it could only output to a Loki destination, that would be fine as a replacement for promtail and/or Grafana agent, but would not be “vendor neutral”.

However, digging further, I found the otelcol.receiver.loki component which can accept loki messages and convert them to OTel Collector format, and that in turn can be be connected to other otelcol.exporter components to send to other destinations like Kafka.

At least, that’s how I’m currently interpreting the compatibility guidelines - the terminology used is a bit weird. If I understand correctly:

  • The message data types which pass between “components” are called “capsules”, and:
  • A component “consumes” a type if it outputs messages of that type
  • A component “exports” a type if it inputs messages of that type

e.g.

Further confusion is given by some components being called a “receiver” (e.g. otelcol.receiver.kafka) and some a “source” (e.g. loki.source.kafka), both of which read messages from a kafka queue.

These are classified by the types of messages they output, so otelcol.receiver.kafka is an otelcol.Consumer “consumer”, and loki.source.kafka is a loki.LogsReceiver “consumer”. But “consumer” does not mean they ingest messages of those types - rather, they output messages of those types.

None of this terminology, as far as I can tell, comes from OTel Collector. The data types used by OTel Collector are just “traces, metrics, and logs”. So from this, it seems that Alloy is wrapping the messages (hence encapsulated → “capsules”) to support additional message types which are not in the OTel Collector format, such as “prometheus.MetricsReceiver” or “loki.LogsReceiver”, rather than mapping all messages to OTel Collector “metrics” and “logs”.

It would have been really helpful to have this explanation up-front - assuming I’ve made the correct interpretation, that is.

Rather than being a distribution of OTel Collector, Alloy seems to be a layer on top of it. In many deployments you could use Alloy without using any of the OTel Collector components or otelcol.Consumer message types at all.

4

I am not sure why you would expect Alloy to support products that they aren’t affiliated with.

I am not part of the Grafana company, so I can’t speak for them, but to me that’s a marketing term, and you should treat it as such and perhaps not be so stuck on it. Vendor neutral can mean many things, and by being open source there is a good chance it can be considered as such. After all, you could put in the effort and write an Alloy component that forwards logs to wherever you want.

It’s not realistic to expect Alloy to support everything you want it to support. In fact, it’s not realistic to expect anything to support everything you want it to support. Pick what works for you.

1 Like