-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Enhancing observability customisations #1462
Comments
Hey @apodgorbunschih, perhaps we could support custom resources attributes via the OTEL_RESOURCE_ATTRIBUTES environment variable. Would this address your concern? It may also be a good opportunity to update all telemetry-related environment variables to comply with OpenTemetry standards. Here's a related issue for that. |
@beeme1mr Michael, thanks again for such a quick replay ❤ Could you please help me to understand, by supporting this attribute in |
Hey @apodgorbunschih, looking a bit deeper into this, I'm wondering if this may work without requiring a code change 🤔. It appears that the OTel Go SDK will merge the default resources with those defined in the |
Hey @beeme1mr 👋 , yeap yeap that would be good. I tried to pass the I am using official documentation for the local configuration : https://flagd.dev/reference/monitoring/?h=moni#docker-composeyaml |
We may have to explicitly pass additional dimensions to the metrics. Is this something you'd be interested in working on? |
I may try @beeme1mr . Do you have some specific requirements ? From my side what I would expect or want to have something like that :
But not sure if that fits in the current vision of the project and the direction |
Hey @apodgorbunschih, I talked to one of the mainters of OpenTelemetry and they think The easiest way to do this is to enable receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
exporters:
prometheus:
endpoint: "0.0.0.0:8889"
// This is the new setting
resource_to_telemetry_conversion:
enabled: true
otlp/jaeger:
endpoint: jaeger-all-in-one:4317
tls:
insecure: true
processors:
batch:
service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/jaeger ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ prometheus ] However, this may not be a good idea if there are a large number of resources. The recommended approach is to apply a processor that extracts specific resource attributes as Prometheus labels. processor:
transform:
metric_statements:
- context: datapoint
statements:
- set(attributes["namespace"], resource.attributes["k8s.namespace.name"])
- set(attributes["container"], resource.attributes["k8s.container.name"])
- set(attributes["pod"], resource.attributes["k8s.pod.name"]) You can read more about it here. Hope this helps! |
Requirements
Overview
Consider implementing options to include extra tags and metadata for the "traces/metrics/logs." This enhancement could provide valuable insights in the production environment.
Current situation
Metrics
Documentation
The metrics that are exposed, are lacking information for "production" environment.
Ex:
http.server.duration
metric, measures the duration of inbound HTTP requests.core/pkg/telemetry/metrics.go:169 Creation of the meter
file: core/pkg/telemetry/metrics.go:80 Usage of the meter
The attributes that are registered, are hardcoded and can be enriched just on
collector
level(This is not something that we want to do, because this collector is collecting information from multiple sources).Example of a metric in Prometheus
ex: This is how it looks in an environment in DataDog.
Requirements
Be able to configure the "log/metrics/traces" with additional metadata/tags to enrich the observability. We would like to add tags like "application/region/zone" etc so we can have a better understanding of our system.
The text was updated successfully, but these errors were encountered: