canonical / canonical/pyroscope-operators
Collector cannot forward profiles: otelcol 0.130 rejects the OTLP profiles schema Pyroscope v2 needs
- Dominant language
- Python
- Stars
- 1
- Forks
- 3
- Avg merge
- 3h 30m
- Merged PRs (30d)
- 2
Description
Profiles pushed through the OpenTelemetry Collector never reach Pyroscope. The collector rejects the payload outright:
```
StatusCode.INTERNAL
details = "grpc: error unmarshalling request: proto: wrong wireType = 2 for field LocationsLength"
```
`LocationsLength` is a field from the older OTLP profiles schema. Pyroscope v2 parses the newer stack-table shape, where a sample carries a `stack_index` into a `ProfilesDictionary.stack_table` rather than `locations_start_index`/`locations_length`. So a generator that satisfies Pyroscope v2 cannot satisfy otelcol 0.130, and the reverse holds too. The two are mutually exclusive.
Reproduced by running `scripts/profilegen.py` directly against a deployed collector's OTLP port. Pointing the same generator at the coordinator works, so it's the collector that can't read it.
The collector charm ships 0.130 on every channel we can use: `0.130/stable` is rev 211, and even `dev/edge` (rev 236) still pins `ubuntu/opentelemetry-collector:0.130-26.04`. A 0.155 image exists on Docker Hub but only for 24.04, and no charm channel uses it.
So this needs an opentelemetry-collector-k8s image on a version that understands the newer schema. Related: canonical/opentelemetry-collector-k8s-operator#334, and #335 which attempted the bump and was closed.
Until then, four tests are skipped in #435: `test_emit_profile_to_collector` and `test_ingest_profile_from_collector` in both `test_profiling_with_collector` and `test_profiling_with_collector_tls`. Everything else in those modules passes, so the collector deploys and integrates fine, it just cannot carry profiles.
Contributor guide
Research direction
Start by checking how the collector charm pins `ubuntu/opentelemetry-collector:0.130-26.04` and review related operator issues #334 and #335. Reproduce with `scripts/profilegen.py`, then run the four skipped profile-forwarding and ingestion tests in `test_profiling_with_collector` and `test_profiling_with_collector_tls`; done means the deployed collector accepts the newer profiles schema and those tests pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, kubernetes, python
- Domain
- infrastructure, observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100