feat: enhance OTLP support for metrics, and traces

[erenaslandev]

Summary by CodeRabbit

• New Features
  • Added new test cases for OTLP metrics and traces forwarding (correctness and performance scenarios)
  • Extended generator capabilities to support metrics and traces signals alongside logs
  • Improved transport flexibility with gRPC and HTTP options for different signal types

[coderabbitai]

Walkthrough

This PR adds metrics and traces test case configurations (correctness and performance variants) alongside a major refactoring of the OTLP generator to support all three signal types (logs, metrics, traces) over multiple transports (gRPC and HTTP). The generator now uses a reusable batch interface and signal-specific implementations.

Changes

Test Case Configurations

Layer / File(s)	Summary
Metrics correctness test case cases/otlp_metrics_to_otlp_correctness/case.yaml, cases/otlp_metrics_to_otlp_correctness/configs/*	Adds 500-record metrics receive→forward test with deduplication enforcement and required METRIC- tokens in all received lines.
Metrics performance test case cases/otlp_metrics_to_otlp_performance/case.yaml, cases/otlp_metrics_to_otlp_performance/configs/*	Configures unlimited-rate metrics generation and throughput comparison of vmetric vs otel-collector subjects.
Traces correctness test case cases/otlp_traces_to_otlp_correctness/case.yaml, cases/otlp_traces_to_otlp_correctness/configs/*	Adds 500-span traces receive→forward test with deduplication validation and required TRACE- tokens in received lines.
Traces performance test case cases/otlp_traces_to_otlp_performance/case.yaml, cases/otlp_traces_to_otlp_performance/configs/*	Configures unlimited-rate traces generation and throughput comparison across subjects.

OTLP Generator Implementation

Layer / File(s)	Summary
Entry point and signal constants containers/generator/main.go, containers/generator/otel.go (package docs and constants)	Main.go dispatcher now calls runOTLP() instead of runOTLPLogs(). Package-level constants define signal types (logs, metrics, traces) and transport modes.
Signal dispatch and validation containers/generator/otel.go (dispatcher functions)	runOTLP and runOTLPSignal validate signal-transport pairs, rejecting gRPC for metrics/traces, and route to per-signal implementations.
Batch interface and logs conformance containers/generator/otel.go (interface definition, drive loop, logs implementation)	New signalBatch interface abstracts record generation. Generic otlpDriveLoop enforces per-record rate limiting and delegates batch population. Logs batch (otlpBatch) now implements interface with protoMsg(), in-place prepare(), and record field mutation in fillRecord().
Metrics and traces batches containers/generator/otel.go (metric and trace implementations)	otlpMetricBatch preallocates gauges with unique METRIC-<seq> names; otlpTraceBatch preallocates spans with non-zero derived IDs and unique TRACE-<seq> names. Both conform to signalBatch.
Generic HTTP sender containers/generator/otel.go (HTTP transport refactoring)	Unified runOTLPHTTP accepts signal path and reusable batch, appends /v1/<signal> to target URLs, and marshals per-worker messages with gzip and protojson/protobuf encoding.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

A rabbit hops through signals bright,
Now logs and metrics take their flight,
Traces follow close behind,
Multi-signal, so refined!
Test cases bloom on every side,
With interfaces as your guide. 🐰✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately reflects the main enhancement: extending OTLP generator and test infrastructure to support metrics and traces signals alongside the existing logs support.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/otel-metrics-traces

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

cases/otlp_metrics_to_otlp_correctness/configs/otel-collector.yaml (1)

14-15: 💤 Low value

gRPC receiver enabled in HTTP-only tests (both metrics and traces). Both correctness cases target only subject:4318 (HTTP), and both vmetric configs explicitly disable gRPC to "isolate the HTTP ingress path." However, both otel-collector configs enable gRPC (4317) and HTTP (4318) receivers. While the gRPC listeners won't receive traffic, this creates an asymmetry between subjects. Consider disabling gRPC in both otel-collector configs to match the test intent and ensure both subjects use the same HTTP-only ingress path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@cases/otlp_metrics_to_otlp_correctness/configs/otel-collector.yaml` around
lines 14 - 15, The otel-collector YAML currently enables a gRPC receiver (grpc:
endpoint: 0.0.0.0:4317) alongside the HTTP receiver, which conflicts with the
tests' intent to be HTTP-only; remove or comment out the grpc receiver block
(the grpc: endpoint: 0.0.0.0:4317 section) from the otel-collector configs used
by cases/otlp_metrics_to_otlp_correctness so the collector only declares the
HTTP receiver (endpoint: 0.0.0.0:4318), ensuring symmetry with the vmetric
configs that disable gRPC.

containers/generator/otel.go (1)

23-52: 💤 Low value

Stale package documentation from logs-only version.

Lines 3-22 describe the new multi-signal behavior, but this block (lines 23-52) still references only logs ("LogRecord", "ResourceLogs → ScopeLogs → LogRecords", "body 'OTEL-'"). Consider consolidating or removing this legacy documentation to avoid confusion.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@containers/generator/otel.go` around lines 23 - 52, The top comment block
contains stale logs-only wording (mentions "LogRecord", "ResourceLogs →
ScopeLogs → LogRecords", and "body 'OTEL-<seq>'") that conflicts with the new
multi-signal behavior; either remove or update those lines to describe
multi-signal support (traces/metrics/logs), remove the hard-coded "OTEL-<seq>"
reference, and consolidate the transport/behavior notes into a single coherent
paragraph — edit the comment in otel.go to replace the legacy LogRecord-specific
sentences with multi-signal descriptions and keep the existing transport details
(HTTP/gRPC/protobuf/json, gzip, batching) intact.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@cases/otlp_metrics_to_otlp_correctness/configs/otel-collector.yaml`:
- Around line 14-15: The otel-collector YAML currently enables a gRPC receiver
(grpc: endpoint: 0.0.0.0:4317) alongside the HTTP receiver, which conflicts with
the tests' intent to be HTTP-only; remove or comment out the grpc receiver block
(the grpc: endpoint: 0.0.0.0:4317 section) from the otel-collector configs used
by cases/otlp_metrics_to_otlp_correctness so the collector only declares the
HTTP receiver (endpoint: 0.0.0.0:4318), ensuring symmetry with the vmetric
configs that disable gRPC.

In `@containers/generator/otel.go`:
- Around line 23-52: The top comment block contains stale logs-only wording
(mentions "LogRecord", "ResourceLogs → ScopeLogs → LogRecords", and "body
'OTEL-<seq>'") that conflicts with the new multi-signal behavior; either remove
or update those lines to describe multi-signal support (traces/metrics/logs),
remove the hard-coded "OTEL-<seq>" reference, and consolidate the
transport/behavior notes into a single coherent paragraph — edit the comment in
otel.go to replace the legacy LogRecord-specific sentences with multi-signal
descriptions and keep the existing transport details (HTTP/gRPC/protobuf/json,
gzip, batching) intact.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d06517f6-5817-4c08-9bef-22c9593473d8

📥 Commits

Reviewing files that changed from the base of the PR and between 4cdfcf9 and 8fc1d95.

📒 Files selected for processing (14)

• cases/otlp_metrics_to_otlp_correctness/case.yaml
• cases/otlp_metrics_to_otlp_correctness/configs/otel-collector.yaml
• cases/otlp_metrics_to_otlp_correctness/configs/vmetric.yml
• cases/otlp_metrics_to_otlp_performance/case.yaml
• cases/otlp_metrics_to_otlp_performance/configs/otel-collector.yaml
• cases/otlp_metrics_to_otlp_performance/configs/vmetric.yml
• cases/otlp_traces_to_otlp_correctness/case.yaml
• cases/otlp_traces_to_otlp_correctness/configs/otel-collector.yaml
• cases/otlp_traces_to_otlp_correctness/configs/vmetric.yml
• cases/otlp_traces_to_otlp_performance/case.yaml
• cases/otlp_traces_to_otlp_performance/configs/otel-collector.yaml
• cases/otlp_traces_to_otlp_performance/configs/vmetric.yml
• containers/generator/main.go
• containers/generator/otel.go