OpenTelemetry Integration
TigerOps is a native OpenTelemetry backend. Send traces, metrics, and logs over OTLP without changing a single line of instrumentation code. Zero vendor lock-in. Full AI-powered analysis.
How It Works
Instrument Your Service
Use any OpenTelemetry SDK — Java, Python, Go, Node.js, .NET, Ruby, and more. TigerOps accepts all OTel-conformant signals without any proprietary SDK.
Configure the OTLP Exporter
Set the OTLP endpoint to your TigerOps collector URL and add your API key as a header. Works with OTLP over gRPC (4317) or HTTP (4318).
Traces, Metrics & Logs Arrive
All three signal types flow into TigerOps over a single OTLP connection. Spans are indexed for trace search, metrics feed anomaly detection, and logs are full-text indexed.
AI Correlates All Signals
The AI SRE automatically links traces to metrics and logs using trace IDs, service names, and timestamps — enabling root cause analysis that spans every signal type.
What You Get Out of the Box
Native OTLP gRPC & HTTP
Accept traces, metrics, and logs via OTLP/gRPC on port 4317 and OTLP/HTTP on port 4318. Standard authentication via Authorization header.
Zero Proprietary SDK
TigerOps never requires a proprietary SDK. Any service instrumented with the OpenTelemetry API sends data to TigerOps unchanged.
OTel Collector Compatible
Use the OpenTelemetry Collector as a gateway. Configure the otlpexporter or otlphttpexporter to forward to TigerOps alongside any other backend.
Full Trace Context Propagation
W3C TraceContext and B3 propagation formats supported. Distributed traces spanning microservices, databases, and queues are stitched together automatically.
OTLP Metrics with Exemplars
Ingest OTLP metrics including histograms with exemplars — linking metric data points directly to the traces that generated them.
Semantic Convention Support
TigerOps understands OTel semantic conventions for HTTP, database, messaging, and RPC — auto-populating service maps and dependency graphs.
OTel Collector Config
Configure the OpenTelemetry Collector to forward all signals to TigerOps via OTLP/gRPC.
# OpenTelemetry Collector → TigerOps
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 1s
send_batch_size: 1024
memory_limiter:
limit_mib: 512
exporters:
# Forward to TigerOps (primary backend)
otlp/tigerops:
endpoint: "otel.us1.tigerops.io:4317"
headers:
authorization: "Bearer ${TIGEROPS_API_KEY}"
compression: gzip
# Optional: also forward to an existing backend
# otlp/existing:
# endpoint: "your-existing-backend:4317"
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/tigerops]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/tigerops]
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/tigerops]Common Questions
Do I need to change my instrumentation to use TigerOps?
No. If you are already using the OpenTelemetry SDK, you just change the OTLP exporter endpoint and add your TigerOps API key as a header. No code changes are required — only configuration changes.
Can I send data to TigerOps and another backend simultaneously?
Yes. The OpenTelemetry Collector's pipeline model lets you fan out data to multiple backends. Configure TigerOps as one exporter and your existing backend (e.g., Jaeger, Zipkin, another vendor) as another — both receive identical data.
Which OTLP signal types does TigerOps support?
TigerOps accepts all three OTLP signal types: traces (spans), metrics (gauge, sum, histogram, exponential histogram), and logs. All are accepted over the same OTLP connection using the appropriate service path.
What propagation formats does TigerOps support?
TigerOps supports W3C TraceContext (traceparent/tracestate), B3 single-header and multi-header, and Jaeger propagation formats. The format is auto-detected per request.
Can I use the OpenTelemetry Collector with TigerOps?
Yes — and it is the recommended approach for production. Deploy the OTel Collector as a sidecar or gateway, and configure the otlpexporter to forward to TigerOps. This gives you batching, retry logic, and the ability to fan out to multiple backends.
Point Your OTel Exporter at TigerOps
No SDK changes. No lock-in. Full AI-powered observability in minutes.