flow: separate parent component and controller IDs into new labels

[tpaschalis]

PR Description

This PR amends the registerers and loggers we propagate into the graph to separate the so that the parent component/controller IDs are stored into a separate label.

This makes these metrics easier to read and manage and unlocks other solutions for large names in the case of nested modules in the future.

NOTE: Please review this PR commit-by-commit and look at the extended commit messages. Each contains a snippet of how this change affects the Agent's logs and metrics

The metrics and logs examples are validated using the following example that uses nested modules.

--- entrypoint.river ---
logging {
	format = "json"
}

import.file "a_namespace" {
	filename = "a.river"
}

local.file "default" {
	filename = "entrypoint.river"
}

a_namespace.a "default" {
	a_argument = 47
}

--- a.river ---
declare "a" {
	import.file "b_namespace" {
		filename = "b.river"
	}

	local.file "default" {
		filename = "entrypoint.river"
	}

	argument "a_argument" {
		comment = "Where to send collected metrics."
	}

	prometheus.exporter.self "default" { }

	b_namespace.b "default" {
		b_argument = 147
	}

	export "a_export" {
		value = argument.a_argument.value + b_namespace.b.default.b_export + 1
	}
}

--- b.river ---
declare "b" {
	import.file "c_namespace" {
		filename = "c.river"
	}

	local.file "default" {
		filename = "entrypoint.river"
	}

	argument "b_argument" {
		optional = false
	}

	prometheus.exporter.self "default" { }

	c_namespace.c "default" {
		c_argument = 101
	}

	export "b_export" {
		value = argument.b_argument.value + c_namespace.c.default.c_export + 1
	}
}

--- c.river ---
declare "c" {
	argument "c_argument" {
		optional = false
	}

	local.file "default" {
		filename = "entrypoint.river"
	}

	prometheus.exporter.self "default" { }

	export "c_export" {
		value = argument.c_argument.value + 1
	}
}

Which issue(s) this PR fixes

Closes #6260

Notes to the Reviewer

The tracer implementation still takes the full globals.ControllerID since all it needs is to call path.Ext and get the final component name as the dot-style extension.

One thing to agree upon is whether path.Split makes sense for separating the parent and final IDs, or if we should add a custom helper. Currently, global IDs are currently constructed like a_namespace.a.default/b_namespace.b.default/c_namespace.c.default/local.file.default, i.e. without a leading slash. So for the root controller, we're left with an empty label instead of "/" which was discussed at some point.

TODO:

• Update mixin

PR Checklist

• CHANGELOG.md updated (N/A)
• Documentation added (N/A)
• Tests updated (N/A)
• Config converters updated (N/A)

[rfratto]

Note that from the internal discussion about this, there was a mention to make component_path rooted to make it clearly indicate a global path:

Global IDs start with a path separator, similarly to absolute file paths, to clearly indicate rooting.

Additionally, if there is no parent, component_path should be /:

component_path: the global ID of the containing subgraph for a component. If there is no containing subgraph, component_path is the rooted path /.

In context:

For the global ID /custom_component.default/prometheus.remote_write, the component_path label is /custom_component.default and the component_id label is prometheus.remote_write.

(This rooting logic applies to the other metrics as well wherever the labels are being split)

[thampiotr]

I do like the leading / too.

[rfratto]

I think the mixin will need to be updated alongside this, since component_id is used in some dashboards (which is why we were doing this prior to 1.0 since it would be a breaking change to split out the labels after-the-fact).

[tpaschalis]

I've pushed a commit to include references to component_path eg when summing up component-level metrics for the Controller and Prometheus dashboards.

Here's how it looks like in practice. I'll check the dashboards in more environments with nested modules and more data.

Finally, the OpenTelemetry dashboard doesn't drill down to the component level so it's left as-is for now.

[rfratto]

LGTM, though as a nit I think component_path should before component in the list of variables.

[thampiotr]

LGTM!

[thampiotr]

I do like the leading / too.

[thampiotr]

Accidental commit?

[tpaschalis]

Whoops 🤦

[rfratto]

Thanks!

[rfratto]

nit: I think the order of these should be swapped; the order here is most broad to most specific, so based on that path goes before component ID.