Comments (3)
I don't know what parent_based_always_on
and parent_based_always_off
mean, but I would assume they mean "use the sampling decision extracted from the parent, or otherwise default to (on|off)."
If my assumption is correct, then that means that the (Java, in your example) tracer would always honor a sampling decision extracted from the traceparent
request header.
The behavior in the nginx module, though, is that it will not extract the sampling decision from traceparent
by default. I was asking why that is the default.
from opentelemetry-cpp-contrib.
Yeah I think they should make these consistent across instrumentation. So in my case I think both parent_based_always_on
(which is my default) and parent_based_always_off
is equivalent to sampler.parent_based=true
and the line before that
OtelSamplerType type = OtelSamplerAlwaysOn;
will be equivalent to always_on
So the equivalent default for your instrumentation with the Java instrumentation is always_on
.
Like I said earlier hopefully they streamline the defaults so those switching from one language to the another won't get dinged by assuming the default.
from opentelemetry-cpp-contrib.
In my case I found it the other way by default with Java instrumentation which is parent_based_always_on
which I actually set to parent_based_always_off
in my service.
The advantage of parent_based_always_off
is it allows me to drop the whole span if the parent trace is filtered using a filter
in OpenTelemetry Collector like this
filter/grafana_noise:
error_mode: ignore
traces:
span:
- (resource.attributes["service.name"] == "grafana") and (attributes["http.url"] == "/grafana/metrics") and (attributes["http.method"] == "GET")
- (resource.attributes["service.name"] == "grafana") and (name == "open session") and (attributes["transaction"] == false)
filter/drop_actuator:
traces:
span:
- (attributes["http.method"] != nil) and (attributes["http.method"] == "GET") and (attributes["http.route"] == "/actuator/prometheus")
- (attributes["http.method"] != nil) and (attributes["http.method"] == "GET") and (attributes["http.route"] == "/actuator/health")
- (attributes["http.url"] == "/grafana/metrics") and (attributes["http.method"] == "GET")
- (attributes["http.url"] == "/metrics") and (attributes["http.method"] == "GET")
When the traefik span that starts the whole process gets dropped the whole trace itself gets dropped. Primarily I want to remove the /metrics polling and /health checks
So IMHO I think parent_based_always_off
is a more reasonable default and hope that is the case in Java instrumentation.
However... I would rather the default be consistent across all tooling so what you've flagged here is an inconsistency between instrumentation libraries.
from opentelemetry-cpp-contrib.
Related Issues (20)
- [CI] Upgrade Prometheus CI to opentelemetry-cpp 1.15.0
- [CI] Upgrade otel-webserver-module CI to opentelemetry-cpp 1.15.0 HOT 1
- Upgrade otel-webserver module for nginx stable version 1.26 and mainline 1.25.5 HOT 1
- Release webserver/v1.1.0 is broken HOT 1
- [BUILD] boost_log compilation error (possibly dangling reference) HOT 2
- Support for legacy Cloud Trace propagation header HOT 1
- Nginx instrumentation generate multi propogation header when request header count >= 20 HOT 1
- Use correct type for severity_logger
- NginxModuleTraceAsError` directive not working as expected in ngx_http_opentelemetry_module HOT 3
- NginxModuleRequestHeaders and NginxModuleResponseHeaders are case sensitives
- nginx span shorter than upstream server span
- Centos7 build failing due to centos7 EOL HOT 1
- Update otel-webserver-module for almalinux 9, since centos7 is EOL HOT 2
- opentelemetry-cpp v1.16.0 deprecates API methods currently in use
- Support nginx 1.27.0
- Support NGINX 1.26.1 (stable) and 1.27.0 (Main)
- `b3` propagator not working when internal redirect
- Nginx instrumented with CPP otel contrib rejects requests without User-Agent field.
- Add aryanishan1001 to approvers in README.md HOT 1
- Can't use find_package to locate opentelemetry_fluentd HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opentelemetry-cpp-contrib.