Add database_observability.mysql component

[cristiangreco]

PR Description

Add new component database_observability.mysql.

Which issue(s) this PR fixes

Relates to #1827

Notes to the Reviewer

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[matthewnolf]

LGTM on the SQL collector part!

[wildum]

Nice work, looking forward to see the cool features that this component can enable!

[wildum]

I don't think that this component should expose targets to be scrapped. If you want this component to expose its own metrics you can use the Registerer that's part of the component options that you get in the New() function

[cristiangreco]

My understanding is that opts.Registerer is for metrics regarding the component itself. If I switch to using opts.Registerer then the connection_info metric is available at http://localhost:12345/metrics.

Our intention is to expose metrics that can be piped into a remote write, e.g.

grafanacloud.database_observability.mysql "orders_db" {
  data_source_name = "mysql:3306"
  forward_to = [loki.write.logs_service.receiver] // not used in this example
}

prometheus.scrape "orders_db" {
  targets = grafanacloud.database_observability.mysql.orders_db.targets
  honor_labels = true
  forward_to = [prometheus.remote_write.metrics_service.receiver]
}

prometheus.remote_write "metrics_service" {
  endpoint {
    url = sys.env("GCLOUD_HOSTED_METRICS_URL")
    basic_auth {
      username = sys.env("GCLOUD_HOSTED_METRICS_ID")
      password = sys.env("GCLOUD_RW_API_KEY")
    }
  }
}

Is there a different way of doing this?

[wildum]

that's correct, but given that you are planning to use the existing exporter for the metrics + that you only have the "connection_info" as a metric here, I thought that it would fit as a metric regarding the component itself. If you want to expose more metrics from this component in the future and you think that it doesn't fit as metrics about the component itself then you can expose them the way you did

[cristiangreco]

We want the metrics to come out of database_observability.mysql (or whatever final name). If we create them as metrics attached to the component itself then one would need to scrape the Alloy /metrics endpoint to ingest those metrics, right? It's not what we want in this case: don't think the discriminator should be the fact we currently have only 1 metric, as it pushes us toward a totally different usage model.

[wildum]

yes that's correct. I get your point and that's ok if you want to go this way. I do think that the amount of metrics you have matters a bit in the solution because if it stays with one metric that's actually a constant then it seems overkill to have the scrape complexity in the component + require the need to scrape this component just for this one info. But if you think that you might add more metrics to it later and that it would be worth it for users to scrape it then that's totally fine.

Also it may not work with clustering if the target is not exactly the same across all instances (not sure if that's the case or not for you. If it is then it should be warned in the doc because this is a common pitfall that confuses users)

[cristiangreco]

Not planning to make this work for clustering. I do see your point about the number of metrics, I think we want to keep the door open for now and have this component produce its own metrics. Things will be more clear once we approach moving out of "experimental".

[cristiangreco]

@wildum I think all major points are addressed and what's left is probably not a blocker for merging this PR? Could you please take another look?

[wildum]

Thanks for working on the feedback, I just have a few little comments left and then we can merge it