grafana / alloy

OpenTelemetry Collector distribution with programmable pipelines
https://grafana.com/oss/alloy
Apache License 2.0
1.35k stars 189 forks source link

Component for Grafana Cloud DB O11y #1827

Open matthewnolf opened 1 week ago

matthewnolf commented 1 week ago

Background

At Grafana Labs, we are in the beginning stages of developing a new feature set for Grafana Cloud - Database Observability. This feature set provides end users with an experience for monitoring their database setups, to perform tasks such as instance monitoring, query analysis, and performance insight and optimization.

Such functionality obviously relies on having data available from the source, in order to interpret, and visualize. This data is available both directly and indirectly (i.e. requires additional transformation) from the database instance being monitored. We therefore must ask end users to run an application that is capable of this data collection, and a means to ship it to Grafana Cloud - something they are already using Alloy to do for a variety of similar use cases. This feature set will initially be compatible with the MySQL database, with plans to extend it to other SQL and NoSQL alternatives in the future. The contents of this proposal however are centered around MySQL support.

Proposal

To add a new component to alloy that captures and outputs all of the required telemetry for the Grafana Cloud - Database Observability feature set - which will include both metrics, and logs. The objective of this component will be to complement the Grafana Cloud feature. Maintaining compatibility with other similar features/products is not a primary objective.

The proposal is to implement the collection functionality in an external, separate (to the alloy repository) package. This package will then be imported and run as a component within Alloy, behaving in a similar way to other prometheus exporter components. This will enable us to maintain and iterate on the package outside of alloy. While we have begun work on this already, we are submitting this proposal early so that any adjustments or considerations can be incorporated to the approach we take. There exists today a prometheus exporter for MySQL, which is available as an alloy component. This proposal plans to make use of that component, however will encompass it with additional transformations along with outputting other telemetry signals - namely logs.

For illustrative purposes, the component signature may look like the following. We would appreciate any naming recommendations.

db-o11y.collector "collector-name" {
  data_source_name = DATA_SOURCE_NAME
  metrics_remote_write = [prometheus.remote_write.grafana_cloud.receiver]
  logs_remote_write = [loki.write.grafana_cloud.receiver]

  # additional configuration to be added later
}
ptodev commented 1 week ago

Hello! Thank you for the proposal. Do you think you'd be able to reuse the existing components, and wrap them in a module? Then you could host the modules in the alloy-modules repo.

matthewnolf commented 1 week ago

Hi @ptodev. We are writing new functionality that does not currently exist in any of the alloy components today - this includes collecting database information that does not fit within a metric format (schema information, query samples, execution plans).

For this reason we are proposing to add a new component that provides such functionality. The implementation we are working on is still early but the hope is that once it is mature, we could embed it into a new component. Appreciate that we are proposing this fairly early given we don't yet have the code we want to embed - but we are hoping for validation of the approach.

wildum commented 1 week ago

Additional context to the proposal: https://raintank-corp.slack.com/archives/CSN5HV0CQ/p1726823820918259

ptodev commented 1 day ago

I moved this proposal to "likely accept". I'm happy with it, given that the functionality in the proposed component will be new functionality which is not in other components. If you do need something from other components, it'd be best to create a module. The new component should be labeled as experimental.

Over time, we may break it up into smaller, more generic components. For example, we might have a loki.source.mysql for gathering logs from MySQL.