Skip to content
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

To achieve different sampling rates for different applications and integrate them with the OTel collectors #31562

Open
zendesk-shweta opened this issue Mar 5, 2024 · 7 comments
Labels
enhancement New feature or request help wanted Extra attention is needed never stale Issues marked with this label will be never staled and automatically removed processor/probabilisticsampler Probabilistic Sampler processor

Comments

@zendesk-shweta
Copy link

Component(s)

No response

Describe the issue you're reporting

How can we set up the different sampling rates for different applications and integrate them with the OTel collectors to have a centralized control over sampling rate on otel config side.? What are the different approaches to achieve this on otel side?

@zendesk-shweta zendesk-shweta added the needs triage New item requiring triage label Mar 5, 2024
@crobert-1
Copy link
Member

Usually sampling rates for applications are determined by settings in the configured receivers. To choose different sampling rates for different applications, you'd want to check the configuration options for each receiver you're interested in using, and go from there.

Is that generally what you're wondering, or did I misunderstand?

@crobert-1 crobert-1 added question Further information is requested and removed needs triage New item requiring triage labels Mar 5, 2024
@zendesk-shweta
Copy link
Author

Lets say i have 2 services running on the same cluster as otel collector and each service is sending the traces to otel collector, now our requirement is to set the different sampling rates for each service on otel.config file , can i define the sampling rates like this ?
extensions:
pprof:
endpoint: :1888
zpages:
endpoint: :55679

receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318

processors:
batch:
probabilistic_sampler/tracing:
sampling_percentage: 5
rules:
- service_name: "RUN-APP-OTEL-SERVICE"
sampling_percentage: 10
- service_name: "service2"
sampling_percentage: 20
memory_limiter:
# 75% of maximum memory up to 2G
limit_mib: 256
# 25% of limit up to 2G
spike_limit_mib: 200
check_interval: 5s

exporters:
logging:
loglevel: debug
debug:
verbosity: detailed
datadog:
api:
site: "datadoghq.com"
key: ${env:DD_API_KEY}
tls:
insecure_skip_verify: true
sending_queue:
enabled: true
queue_size: 200
num_consumers: 100
timeout: 1s
retry_on_failure:
enabled: false
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 5m

service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, probabilistic_sampler/tracing]
exporters: [debug, datadog, debug] # Change to datadog
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [logging, datadog, debug] # Change to datadog

extensions: [pprof, zpages]

Or is there a better way to achieve this? As we may have large number of service sending the traces to otel collector and i am wondering how will we add the all the services under processors?

@crobert-1
Copy link
Member

crobert-1 commented Mar 6, 2024

My apologies @zendesk-shweta, for some reason I misinterpreted your question thinking you were asking about how often to scrape endpoints in a receiver, not the sampling rate in the probabilistic sampler 👍

I don't think it's possible in a single processor definition for this processor. You'd likely have to define entirely different receivers and processors, and then have a pipeline in the collector for each service. I suggest this solution as I don't think this processor filters based on attributes, so all data that it gets would be sampled at the same rate. To be able to sample two sets of data at a different rate, you'd need the data sets to be separately received and processed, to my understanding. The code owners would have a definitive answer though, I'm not very familiar with this component and I may be missing something here.

I'll mark this as an enhancement request.

@crobert-1 crobert-1 added processor/probabilisticsampler Probabilistic Sampler processor enhancement New feature or request and removed question Further information is requested labels Mar 6, 2024
Copy link
Contributor

github-actions bot commented Mar 6, 2024

Pinging code owners for processor/probabilisticsampler: @jpkrohling. See Adding Labels via Comments if you do not have permissions to add labels yourself.

@crobert-1 crobert-1 added the needs triage New item requiring triage label Mar 6, 2024
@zendesk-shweta
Copy link
Author

/label processor/sampler help-wanted

@github-actions github-actions bot added the help wanted Extra attention is needed label Mar 7, 2024
@crobert-1 crobert-1 removed the needs triage New item requiring triage label Mar 13, 2024
@jmacd
Copy link
Contributor

jmacd commented Mar 21, 2024

This is a reasonable request. See open-telemetry/oteps#250.
I expect this functionality will eventually emerge in the probabilisticsamplerprocessor, and that the OpAmp protocol will be used to distributed sampling configurations via an OTel sampling configuration, but there is a lot of work to do.

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label May 21, 2024
@crobert-1 crobert-1 added never stale Issues marked with this label will be never staled and automatically removed and removed Stale labels May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed never stale Issues marked with this label will be never staled and automatically removed processor/probabilisticsampler Probabilistic Sampler processor
Projects
None yet
Development

No branches or pull requests

3 participants