chore!: Refactor OTel exporters to be signal-specific#125
Conversation
10f32fa to
cd03357
Compare
2bc1fc7 to
54b8ab6
Compare
54b8ab6 to
3a803bb
Compare
cd03357 to
a9c66b9
Compare
| ) | ||
|
|
||
| if trace_exporter is None: | ||
| return None | ||
|
|
||
| if service_name is None: | ||
| app_env = os.environ.get("TANGLE_ENV", "unknown") | ||
| service_name = f"tangle-{app_env}" | ||
|
|
||
| if service_version is None: | ||
| service_version = os.environ.get("TANGLE_SERVICE_VERSION", "unknown") |
There was a problem hiding this comment.
Do we have this env set today? what the versioning strategy do we use?
There was a problem hiding this comment.
Technically, it's up to the OSS user of Tangle (someone who clones and deploys Tangle themselves).
They can use their commit shas, semantic versioning, whatever they feel is right. For our case, we use a revision (commit sha) provided by our CD platform.
As for recommendations, we could add some to our documentation of this variable which is upstack. Suitable values would be build ids, URLs, or commit shas.
There was a problem hiding this comment.
PS: I'm not fully happy with the docs yet even after this full stack as it is now. I'd love to collaborate and hear ideas on how in-depth we want to go on docs and where our source of truth should be for metric information.
| ) | ||
|
|
||
| if trace_exporter is None: | ||
| return None | ||
|
|
||
| if service_name is None: | ||
| app_env = os.environ.get("TANGLE_ENV", "unknown") |
There was a problem hiding this comment.
What are possible values for TANGLE_ENV? Where it is being set?
There was a problem hiding this comment.
We improve the documentation for this upstack but happy to answer here:
This is used as part of the service name for your OTel exports. This is literally your env, so development, staging, etc.
Alexey and I landed on this name for it in an earlier merged PR.
a9c66b9 to
4c46bd2
Compare
b638a9b to
7290c18
Compare
4c46bd2 to
6921879
Compare
Merge activity
|
This allows users to set different exporters for traces vs metrics Made-with: Cursor
6921879 to
9ae210f
Compare

Refactor OpenTelemetry configuration to support signal-specific exporters
This refactors the OpenTelemetry configuration system to support separate exporter configurations for different telemetry signals (traces, metrics, logs).
Changes
OtelConfiginto separateExporterConfigandOtelConfigclassesendpoint,protocol) toExporterConfigtrace_exporterfield toOtelConfigfor trace-specific configurationTANGLE_OTEL_EXPORTER_*to signal-specificTANGLE_OTEL_TRACE_EXPORTER_*_resolve_exporter()helper function for reusable exporter configuration logicproviders.setup()to only configure tracing when trace exporter is presentThis allows users to configure different exporters for traces vs metrics by setting signal-specific environment variables.