self_metrics : Write enabled_receivers and feature_tracking metrics to OTLP json.

[franciscovalentecastro]

Description

Write enabled_receivers and feature_tracking metrics to OTLP json. This PR doesn't remove the current metric collection from the diagnostics service.

Related issue

b/333412970

How has this been tested?

Checklist:

• Unit tests
  • Unit tests do not apply.
  • Unit tests have been added/modified and passed for this PR.
• Integration tests
  • Integration tests do not apply.
  • Integration tests have been added/modified and passed for this PR.
• Documentation
  • This PR introduces no user visible changes.
  • This PR introduces user visible changes and the corresponding documentation change has been made.
• Minor version bump
  • This PR introduces no new features.
  • This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
  • This PR bumps the version.

[ridwanmsharif]

Why does does run in this case? Or does it not matter (i.e. we only want this run once). Adding a comment here would help clarify

[franciscovalentecastro]

IMO, the new generated otlp metric files (feature_tracking_otlp.json, enabled_receivers_otlp.json) are somehow part of the Otel Collector configuration, a pre-condition for the Ops Agent otel collector to work as expected and collect self metrics about it's configuration. Considering this i made the decision to place the files in the same /run folder as the otel.yaml config :

"/run/google-cloud-ops-agent-opentelemetry-collector/otel.yaml"
"/run/google-cloud-ops-agent-opentelemetry-collector/feature_tracking_otlp.json"
"/run/google-cloud-ops-agent-opentelemetry-collector/enabled_receivers_otlp.json"

Why does does run in this case? Or does it not matter (i.e. we only want this run once). Adding a comment here would help clarify ?

It matters it only being in otel service (with the previous considerations) because :

1. The main service (service == "") does not write Config Files (it only does config validation and runs health checks). The "fluentbit" and "otel" services write the Config Files.
2. This way only "otel" service writes otel collector related config files.
3. [General Design] The systemd (and windows) services run independently. We do set preconditions for order of execution, but (as i've explored in the past) setting expectations from one service doing something before something else happens in another always potentially could create unexpected race conditions.

[franciscovalentecastro]

P.D. I tried putting everything in uc.GenerateFilesFromConfig to make everything simpler, but we need both the userConfig and the mergedConfig.

[ridwanmsharif]

Same as before, why is this a otel specific check?

[franciscovalentecastro]

Responded in the other comment.