Feature/json file http exporter #4556
Conversation
Add new packages for JSON-based OTLP exporters as alternatives to the existing Protobuf-based exporters: - opentelemetry-exporter-otlp-json-common: Common JSON encoding functionality - opentelemetry-exporter-otlp-json-http: HTTP transport implementation These exporters enable compatibility with services requiring JSON format instead of Protobuf. Implementation includes full support for traces, metrics, and logs with comprehensive test coverage following project guidelines. Closes open-telemetry#1003
Replace 'too-many-positional-arguments' with the correct pylint message ID 'too-many-arguments' and fix type ignore comments placement for imports without stubs.
Replace string representation of integers with actual integer values in the OTLP JSON exporters
to comply with the OTLP specification. This ensures integer attributes are properly encoded as
{intValue: 123} instead of {intValue: 123} for better compatibility with OTLP receivers.
NN---
force-pushed
the
feature/json-file-http-exporter
branch
from
2a4eab4 to
50f119d
Compare
NN---
force-pushed
the
feature/json-file-http-exporter
branch
from
50f119d to
278afd4
Compare
| return [ | ||
| _encode_value(v, allow_null=allow_null) if v is not None else None | ||
| for v in array | ||
| ] |
There was a problem hiding this comment.
Caveat: the spec mandates that arrays are homogeneous.
I don't have a strong opinion on what the expectation of the client-side library is: to actually raise on that, or skip the top-level key, or pass through.
Here's how I've done this:
| if isinstance(value, int): | ||
| return {"value": {"intValue": value}} |
There was a problem hiding this comment.
Sadly that's incorrect.
Recall that JavaScript coerces large integers to floating point.
I believe this is spelled out in the OTLP spec.
|
@dimaqq Please pay attention to the original PR so the author can address the comments. |
|
You may consider using https://pypi.org/project/otlp-test-data/ , a small project I made to generate all conceivable "weird" input. That includes the JSON flavour of OTLP serialisation, to the best of my understanding. I could be wrong on some details, PRs are welcome :) |
|
@dimaqq Do you know whether trace and spans ids in http/json are base64 encoded? |
Do read https://opentelemetry.io/docs/specs/otlp/#json-protobuf-encoding I mean I can answer your question off the top of my head, but then you'd miss the other half a dozen gotchas. |
|
I want to take a fresh stab at this PR. |
|
@zeitlinger go for it! Feel free to compare against https://github.com/dimaqq/otlp-json/blob/main/otlp_json/__init__.py (apache licensed) and to use the in-memory test data generator https://github.com/dimaqq/otlp-test-data Admittedly both are about a year out of date, but that should still cover the basics. |
|
Recent open telemetry SDK made some changes to _log module. |
Per OTLP specification, 64-bit integers in JSON-encoded payloads must be encoded as decimal strings to prevent precision loss in JavaScript/JSON parsers. This addresses review feedback from PR open-telemetry#4556. Changes: - trace_encoder: intValue now uses str(value) instead of value - log_encoder: intValue now uses str(value) instead of value - metrics_encoder: intValue now uses str(value) instead of value Note: Body integer values were already correctly encoded as strings. This fix applies to attribute integer values. Related: https://opentelemetry.io/docs/specs/otlp/#json-protobuf-encoding Fixes review comment from @dimaqq on PR open-telemetry#4556
|
Superceded by #4886 |
4 participants
Addition to #4470 to write the id as hex so they can be exported to files.