Collector self-logs: service_name / service_version vs the new GIM agent entity #27436

Follow-up from #27258, needs a decision with the owners of Illuminate #4048.

CollectorLogRecordProcessor.extractResourceAttributes maps the collector's own resource attributes to GIM ServiceFields:

case "service.name"    -> result.put(ServiceFields.SERVICE_NAME, ...);
case "service.version" -> result.put(ServiceFields.SERVICE_VERSION, ...);

The values come from superv/ownlogs/resource.go BuildResource — service.name is "supervisor" (or the embedded collector), service.version is the collector build version (e.g. 2.0.0-SNAPSHOT+54f4e66).

Illuminate #4048 adds a GIM agent entity whose scope is "the identity of the collecting/shipping agent only," including:

• agent_version — "Version of the agent software."
• agent_name — "Custom, human-readable name assigned to the agent instance."
• agent_type — "Type of the agent, constant per product regardless of instance."

and its infomodel lists ["agent_id", "agent_type", "agent_version"] as optional fields.

The conflict

On a collector self-log, the service described by service.* is the agent. So service_version and agent_version are the same value under two names.

service.name is less clear-cut. "supervisor" looks more like agent_type ("constant per product") than agent_name ("assigned to the instance"), but the supervisor and the embedded collector are two processes of the same product, which neither field models cleanly.

Also in scope

The processor deliberately skips the service.instance.id resource attribute as redundant with the codec-written agent_id. ECS splits this by lifetime — stable across restarts is agent_id, changing per restart is agent_ephemeral_id — and #4048 defines both. Worth confirming which the collector's instance UID actually is.

Decision needed

Whether collector self-logs should populate agent_version (and possibly agent_type) instead of, or in addition to, service_name/service_version.