Documentationbreadcrumb arrow breadcrumb arrow Grafana Alloybreadcrumb arrow Referencebreadcrumb arrow Release informationbreadcrumb arrow Maintenance

Grafana Alloy maintenance scope

This page defines maintenance scope for Alloy, including both the Default Engine and the OTel Engine. Alloy includes code maintained by the Alloy maintainers and upstream dependencies maintained by open-source communities.

For full context, read this page together with Alloy backward compatibility and the Grafana release life cycle.

Maintenance levels

  • Maintained: The feature is maintained by Alloy maintainers or within Grafana open-source projects integrated with Alloy.
  • Maintained with upstream dependency: The feature depends on upstream projects outside the Grafana open-source ecosystem. Final resolution may depend on the upstream community’s review and release processes.
  • Not maintained by Alloy maintainers: The feature is outside the standard maintenance scope of Alloy maintainers.

Maintained

Example features include:

  • Core Default Engine runtime and operational experience, including installation, running, and configuration flow. For engine terminology and differences, refer to OpenTelemetry in Alloy.
  • Alloy platform capabilities such as Alloy configuration syntax, clustering, Fleet Management, and the built-in debugging UI.
  • Alloy installation scripts, Helm chart deployment, and bundled Grafana dashboards.
  • Alloy-owned integration points around the OTel Engine, such as the alloyengine extension.
  • Features based on Grafana open-source projects integrated with Alloy, such as Mimir, Loki, Beyla, Tempo, Faro, Pyroscope, and Database Observability.

Maintained with upstream dependency

Example features include:

  • Features built on bundled upstream OpenTelemetry Collector components or Prometheus-related projects.
  • Compatibility behavior tied to upstream protocols, formats, and ecosystem standards (for example OTLP and Prometheus Remote Write protocols).
  • OTel Engine configuration and features that depend on the upstream OpenTelemetry Collector core engine.

The Alloy maintainers can investigate and collaborate upstream, but resolution timing may depend on upstream acceptance and release timing. In some cases, maintainers may carry a temporary patch or fork, but this is case-by-case and not guaranteed.

Not maintained by Alloy maintainers

Example features include:

  • Community components.
  • Custom or non-standard components added to custom Alloy builds via OCB or otherwise.

Extending Alloy with OCB and custom builds

With OTel Engine, you can use the OpenTelemetry Collector Builder (OCB) to build a customized Alloy binary, including adding components or removing components from the standard release. The Alloy OCB manifest is the starting point for custom builds.

Response to issues usually follows the standard scope when the issue is unrelated to customizations or reproducible with the standard, maintained Alloy release. Response to issues may be limited when behavior can’t be isolated from customizations and can’t be reproduced with the standard, maintained Alloy release.

Further reading