Celery Worker OpenTelemetry Setup
This document contains instructions on how to set up OpenTelemetry instrumentation in your Celery worker applications.
Background
Celery uses prefork worker model by default. In this model, it is important to ensure that the libraries which are not fork-safe create their own instances in the parent process and each child process. To achieve this, we use worker_process_init
hook and instantiate the OpenTelemetry SDK in each worker process. Add the following code to the app file of your Celery application.
from celery.signals import worker_process_init
from opentelemetry.instrumentation.celery import CeleryInstrumentor
from opentelemetry import metrics, trace
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import (
OTLPMetricExporter,
)
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import (
OTLPSpanExporter,
)
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
@worker_process_init.connect(weak=False)
def init_celery_tracing(*args, **kwargs):
CeleryInstrumentor().instrument()
resource = Resource.create({})
trace.set_tracer_provider(TracerProvider(resource=resource))
span_processor = BatchSpanProcessor(OTLPSpanExporter())
trace.get_tracer_provider().add_span_processor(span_processor)
reader = PeriodicExportingMetricReader(
OTLPMetricExporter()
)
metrics.set_meter_provider(
MeterProvider(
resource=resource,
metric_readers=[reader],
)
)
A brief explanation of the code above:
- Import the
worker_process_init
to connect to the Celery signal so that each worker process can initialize its own OpenTelemetry SDK. - Import the
CeleryInstrumentor
to instrument Celery. - Import the necessary components from the OpenTelemetry library to set up the tracer and meter providers.
- Set up the tracer and meter providers with processors and exporters.
This adjustment is required only for the worker processes, not for the producer.
Frequently Asked Questions
How to find what to use in
IP of SigNoz
if I have installed SigNoz in Kubernetes cluster?Based on where you have installed your application and where you have installed SigNoz, you need to find the right value for this. Please use this grid to find the value you should use for
IP of SigNoz
I am sending data from my application to SigNoz, but I don't see any events or graphs in the SigNoz dashboard. What should I do?
This could be because of one of the following reasons:
Your application is generating telemetry data, but not able to connect with SigNoz installation
Please use this troubleshooting guide to find if your application is able to access SigNoz installation and send data to it.
Your application is not actually generating telemetry data
Please check if the application is generating telemetry data first. You can use
Console Exporter
to just print your telemetry data in console first. Join our Slack Community if you need help on how to export your telemetry data in consoleYour SigNoz installation is not running or behind a firewall
Please double check if the pods in SigNoz installation are running fine.
docker ps
orkubectl get pods -n platform
are your friends for this.
What Cloud Endpoint Should I Use?
The primary method for sending data to SigNoz Cloud is through OTLP exporters. You can either send the data directly from your application using the exporters available in SDKs/language agents or send the data to a collector agent, which batches/enriches telemetry and sends it to the Cloud.
My Collector Sends Data to SigNoz Cloud
Using gRPC Exporter
The endpoint should be ingest.{region}.signoz.cloud:443
, where {region}
should be replaced with in
, us
, or eu
. Note that the exporter endpoint doesn't require a scheme for the gRPC exporter in the collector.
# Sample config with `us` region
exporters:
otlp:
endpoint: "ingest.us.signoz.cloud:443"
tls:
insecure: false
headers:
"signoz-access-token": "<SIGNOZ_INGESTION_KEY>"
Using HTTP Exporter
The endpoint should be https://ingest.{region}.signoz.cloud:443
, where {region}
should be replaced with in
, us
, or eu
. Note that the endpoint includes the scheme https
for the HTTP exporter in the collector.
# Sample config with `us` region
exporters:
otlphttp:
endpoint: "https://ingest.us.signoz.cloud:443"
tls:
insecure: false
headers:
"signoz-access-token": "<SIGNOZ_INGESTION_KEY>"
My Application Sends Data to SigNoz Cloud
The endpoint should be configured either with environment variables or in the SDK setup code.
Using Environment Variables
Using gRPC Exporter
Examples with us
region
OTEL_EXPORTER_OTLP_PROTOCOL=grpc OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.us.signoz.cloud:443 OTEL_EXPORTER_OTLP_HEADERS=signoz-access-token=<SIGNOZ_INGESTION_KEY>
Using HTTP Exporter
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.us.signoz.cloud:443 OTEL_EXPORTER_OTLP_HEADERS=signoz-access-token=<SIGNOZ_INGESTION_KEY>
Configuring Endpoint in Code
Please refer to the agent documentation.
Sending Data from a Third-Party Service
The endpoint configuration here depends on the export protocol supported by the third-party service. They may support either gRPC, HTTP, or both. Generally, you will need to adjust the host and port. The host address should be ingest.{region}.signoz.cloud:443
, where {region}
should be replaced with in
, us
, or eu
, and port 443
should be used.