fix(otlp-grpc): send generator resource and real severity on logs, metrics and traces

[adnanrahic]

Proposed Change

The OTLP gRPC output dropped data every generator already provides, and the hostmetrics generator ignored its configured OS. Collectors couldn't route on the source of a record, and most severities arrived as INFO.

1. Resource was never sent (logs, metrics, traces)

Generators attach a resource (host.name, telemetry.source, apache.format, ...) in Metadata.Resource, but the OTLP gRPC output ignored it:

• logs: every batch got a hard-coded service.name=blitz resource; the record carried only the body plus empty environment/location attributes. Per-record Metadata.Attributes were dropped too.
• metrics: buildMetricRequest(metrics, nil), so host metrics arrived without host.name.
• traces: hard-coded service.name=blitz resource.

Found while running Blitz into a Bindplane gateway that routes on resource.attributes["telemetry.source"]: no condition ever matched, so every log fell through to the catch-all route.

Each queued log record, metric and span now carries its generator's resource (generic entry[T] in resource.go). At send time the batch is split into one ResourceLogs / ResourceMetrics / ResourceSpans per distinct resource, in order of first appearance. service.name=blitz is still added unless the generator sets its own. Log records now also carry Metadata.Attributes.

2. Severity matching was uppercase-only

mapSeverityNumber only matched exact DEBUG/INFO/WARN/ERROR/FATAL, so these all became INFO:

Generator	Levels
kubernetes	warn, error (lowercase)
apache error	crit, error, warn, notice
wel	Warning, Error, Critical, Verbose
postgres	WARNING, PANIC, LOG, NOTICE

Matching is now case-insensitive and covers those names. Unknown levels still map to INFO. Severity text is unchanged.

3. generator.hostmetrics.os was ignored

Since generators draw their host from the simulated environment (PIPE-1036), hostmetrics used whatever system SystemForKey("hostmetrics") selected, including that system's OS. With the default randomized fleet that is often Windows, so BLITZ_GENERATOR_HOSTMETRICS_OS=linux (also the default) still produced Windows metrics.

New Environment.SystemForKeyWithOS does the same key-hashed selection restricted to systems running a given OS. Hostmetrics uses it with the configured OS (empty means linux), and falls back to its synthetic host when no system runs that OS.

Verification

• New tests: TestEnvironmentSystemForKeyWithOS and TestHostMetricsIdentityHonorsConfiguredOS (OS-restricted host selection), resource_test.go (resource reaches the OTLP resource for logs, metrics and traces; grouping by resource; no duplicate service.name) and severity_test.go (table of every level name above).
• go test ./..., go vet, gofmt and revive -config .revive.toml are clean.
• End to end: ran the hostmetrics, traces and nginx generators against an OTel Collector with the debug exporter. All three arrived with host.name and telemetry.source on the resource. Against a Bindplane gateway, the routing connector stopped sending everything to its catch-all route, and Kubernetes warn/error lines now match severity_number >= SEVERITY_NUMBER_WARN. The hostmetrics generator, previously started as os.type: windows despite BLITZ_GENERATOR_HOSTMETRICS_OS=linux, now starts as linux.

Checklist

• Changes are tested
• CI has passed

🤖 Generated with Claude Code

[Dylan-M]

Suggest closing. These fixes are already in progress.