GDI spec changes + update upstream #15
Conversation
ghost
commented
Oct 19, 2021
•
ghost
commented
- Update to newest upstream
- Docs update (this is only dev, but FYI @theletterf )
- Default values and validation according to the serverless spec, notable changes:
- SPLUNK_REALM support for traces (and splunk metrics, if emitted by wrappers)
- SPLUNK_METRICS_ENDPOINT for splunk metrics, if emitted by wrappers
- default exporter - OTLP/GRPC
ghost
requested review from
|
@kubawach Reviewed. When these changes are going live, we should update the official docs. |
Co-authored-by: jason plumb <75337021+breedx-splk@users.noreply.github.com>
| # otlp traces exporter | ||
| export OTEL_TRACES_EXPORTER="${OTEL_TRACES_EXPORTER:-otlp}" | ||
| # otlp-grpc protocol | ||
| export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="${OTEL_EXPORTER_OTLP_TRACES_PROTOCOL:-grpc}" |
There was a problem hiding this comment.
BTW this does not apply to Python. Python supports otlp_proto_grpc and otlp_proto_http values for OTEL_TRACES_EXPORTER with otlp being an alias for otlp_proto_grpc. If python decides to change the default to OTLP HTTP, this wrapper will automatically switch to OTLP http for python so may be in case of Python, we want to explicitly set OTEL_TRACES_EXPORTER to otlp_proto_grpc.
Not requesting the change in this PR. Just FYI.
| if [ -n "$SPLUNK_ACCESS_TOKEN" ] && [ "$OTEL_TRACES_EXPORTER" = "otlp" ] | ||
| then | ||
| HEADER="X-SF-TOKEN=$SPLUNK_ACCESS_TOKEN," | ||
| export OTEL_EXPORTER_OTLP_HEADERS="$HEADER""${OTEL_EXPORTER_OTLP_HEADERS}" |
There was a problem hiding this comment.
If the wrappers uses Splunk distros, why do we need to do this? Wouldn't they pick up SPLUNK_ACCESS_TOKEN automatically?
|
|
||
| if [ "$OTEL_TRACES_EXPORTER" = "otlp" ] && [ -z "$OTEL_EXPORTER_OTLP_ENDPOINT" ] | ||
| then | ||
| export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.${SPLUNK_REALM}.signalfx.com/v2/trace/otlp" |
There was a problem hiding this comment.
ENDPOINT - I don't know the grpc endpoint (not published yet), so I used the http (known) one.
dont we need to set the protocol env var then as well? If I understand correctly, we are defaulting to grpc above?
|
@owais regarding
|
Didn't know about that. I think support in Python was added before this got added to the spec. I'll open an issue and add support for protocol env vars. |
|
@owais thanks for handling Python variables :) I'l add support for python-specific names in the meantime. |
