OpenTelemetry Integration¶
Anosys is a full-featured OpenTelemetry-native backend. Any system that speaks OTLP — AI agents, Kubernetes clusters, microservices, infrastructure, IoT — can ship traces, metrics, and logs directly to Anosys and get production-grade observability in minutes.
No proprietary agents. No vendor lock-in. Just standard OpenTelemetry.
Why Anosys for OpenTelemetry¶
| Capability | What It Means for You |
|---|---|
| Full OTLP support | Traces, metrics, and logs over OTLP/HTTP — one endpoint for all three signals |
| Instant time-to-value | Automated metric generation and pre-built dashboards get you started in minutes |
| Full customization | Build your own dashboards, pipelines, detection rules, and KPIs once the defaults outgrow your needs |
| Trace view | Visualize distributed traces end to end — span waterfalls, latency breakdowns, and dependency graphs |
| Error detection | Automatic error classification and structured error tracking across every signal |
| Root cause analysis | Causal paths across agents, models, and infrastructure to pinpoint failures fast |
| Alerts | Context-aware alerting via Slack, email, PagerDuty, and webhooks |
| Labeling | Tag and label your data for segmentation, drill-down, and further analysis |
| Custom pipelines | Enrich, route, and transform signals without glue code |
| Anomaly detection | ML-powered baselines that surface real anomalies, not just threshold breaches |
| Vendor-agnostic | Works with any language, framework, or cloud provider that supports OpenTelemetry |
Integration Methods¶
There are two ways to get OpenTelemetry data into Anosys:
| Method | Protocol | Best For |
|---|---|---|
| Direct HTTP | OTLP/HTTP | Apps and services that export OTLP directly |
| OpenTelemetry Collector | OTLP/HTTP or OTLP/gRPC | Centralized aggregation, fan-out, protocol translation |
gRPC support
Direct OTLP/gRPC ingestion is coming soon. Today, gRPC is fully supported when you route through an OpenTelemetry Collector — the Collector accepts gRPC from your apps and forwards to Anosys over HTTP.
Option 1 — Direct OTLP/HTTP¶
Point your application's OTLP exporter directly at your Anosys endpoint. No intermediate infrastructure required.
Set the standard OTEL environment variables:
Replace YOUR_UNIQUE_PATH with the OTLP path from your Anosys Console pixel.
Python example — traces, metrics, and logs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 | |
Install the required packages
Option 2 — OpenTelemetry Collector¶
Deploy an OpenTelemetry Collector as a central aggregation point. This is ideal when you want to:
- Accept gRPC from your apps (full direct gRPC support is coming soon to Anosys)
- Fan out to multiple backends
- Enrich, filter, or batch data before it reaches Anosys
- Centralize collection from Kubernetes, infrastructure agents, or legacy systems
Collector configuration (otel-collector-config.yaml):
Replace YOUR_UNIQUE_PATH with the OTLP path from your Anosys Console pixel.
Run the Collector:
Then point your applications at the Collector (localhost:4317 for gRPC or localhost:4318 for HTTP) and the Collector forwards everything to Anosys.
Use Case Examples¶
AI Applications¶
OpenTelemetry is rapidly becoming the standard for AI observability. Anosys supports OTEL telemetry from:
- Claude Code — enable OTEL export in
~/.claude/settings.jsonand traces flow automatically. See the Claude Code guide. - OpenAI Agents — use our native SDK or standard OTEL instrumentation. See the OpenAI Agents guide.
- LangChain, LlamaIndex, CrewAI, AutoGen — these frameworks emit OTEL traces natively. Point their exporter at Anosys. See Custom LLM Integrations.
- Any LLM provider — Google Gemini, Meta Llama, Mistral, Cohere, AWS Bedrock, Azure OpenAI, and more.
Anosys automatically surfaces token usage, latency, model comparison, and cost metrics from OTEL trace attributes.
Kubernetes Monitoring¶
Deploy the OpenTelemetry Collector as a DaemonSet or sidecar in your Kubernetes cluster to collect:
- Cluster metrics — node CPU, memory, disk, and network utilization via the
kubeletstatsreceiver - Pod and container metrics — restart counts, resource limits, OOM kills
- Application traces — distributed traces from your microservices, correlated with infrastructure metrics
- Cluster events and logs — Kubernetes events, pod logs, and audit logs via the
k8s_eventsandfilelogreceivers
Example Kubernetes DaemonSet snippet:
Infrastructure Monitoring¶
Anosys accepts OTEL signals from any infrastructure component:
- Servers and VMs — CPU, memory, disk, and network via the OTEL Collector's
hostmetricsreceiver - Network devices — routers, switches, and firewalls via SNMP-to-OTEL bridges or the Collector's
snmpreceiver - Databases — query latency, connection pools, and replication lag via auto-instrumentation libraries
- Message queues — Kafka, RabbitMQ, and Redis metrics via OTEL Collector receivers
For a comprehensive infrastructure monitoring guide, see Network & Infrastructure Observability.
Custom Applications¶
Any application instrumented with OpenTelemetry can send data to Anosys. This includes:
- Microservices — distributed tracing across service boundaries with automatic context propagation
- Batch jobs and cron tasks — trace execution time, error rates, and throughput
- CI/CD pipelines — capture build times, test results, and deployment metrics
- Mobile and web apps — Real User Monitoring (RUM) via the OTEL JavaScript and mobile SDKs
What Anosys Provides¶
Once your OpenTelemetry data is flowing, the Anosys Platform automatically delivers:
- Trace view — End-to-end distributed trace visualization with span waterfalls, latency breakdowns, and service dependency maps.
- Automated metric generation — Anosys automatically generates key metrics from your traces and logs so you get dashboards in minutes, not days.
- Custom dashboards — Build your own views with time-series charts, histograms, tables, gauges, and heat maps — or start from the auto-generated defaults.
- Error detection — Automatic error classification across traces and logs with structured error tracking.
- Root cause analysis — Causal graphs connecting anomalies to upstream triggers across agents, models, and infrastructure.
- Alerts — Context-aware alerting via Slack, email, PagerDuty, and webhooks with intelligent noise reduction.
- Labeling — Tag and annotate your data with custom labels for segmentation, team ownership, and drill-down analysis.
- Custom pipelines — Enrich, route, and transform signals with automated remediation workflows.
- Anomaly detection — ML-powered baselines that learn normal behavior and surface real anomalies.
- Natural language interface — Ask questions about your data in plain English and get answers backed by your telemetry.
Configuration Reference¶
Standard OpenTelemetry environment variables used to configure exporters:
| Variable | Description |
|---|---|
OTEL_SERVICE_NAME |
Logical name for your service (used in traces and dashboards) |
OTEL_TRACES_EXPORTER |
Exporter type for traces (use otlp) |
OTEL_METRICS_EXPORTER |
Exporter type for metrics (use otlp) |
OTEL_LOGS_EXPORTER |
Exporter type for logs (use otlp) |
OTEL_EXPORTER_OTLP_PROTOCOL |
Transport protocol — use http/protobuf for direct, or grpc via Collector |
OTEL_EXPORTER_OTLP_ENDPOINT |
Your Anosys OTLP ingestion endpoint URL |
OTEL_RESOURCE_ATTRIBUTES |
Additional resource attributes (e.g. deployment.environment=prod) |
Troubleshooting¶
I don't see any data in the Anosys Console
- Verify that your
OTEL_EXPORTER_OTLP_ENDPOINTmatches the URL shown in your Anosys pixel configuration. - Confirm that your application is generating traces, metrics, or logs (check local OTEL debug output by setting
OTEL_LOG_LEVEL=debug). - Ensure outbound HTTPS traffic to
api.anosys.aiis not blocked by a firewall or proxy. - If using a Collector, verify that the Collector is running and its exporter endpoint is correct.
Can I use gRPC directly?
gRPC is fully supported when routing through an OpenTelemetry Collector. Direct gRPC ingestion to the Anosys endpoint is coming soon. In the meantime, deploy a Collector that accepts gRPC from your apps and exports to Anosys over HTTP.
Can I send data from multiple services to the same endpoint?
Yes. Use different OTEL_SERVICE_NAME values for each service. Anosys automatically groups and separates data by service name, making it easy to filter and compare.
Does Anosys support all OTLP signal types?
Yes. Anosys fully supports traces, metrics, and logs via OTLP/HTTP. All three signal types are correlated automatically in the platform.
Can I use Anosys alongside other OTLP backends?
Yes. Deploy an OpenTelemetry Collector and configure multiple exporters to fan out the same data to Anosys and any other OTLP-compatible backend simultaneously.
How do I get started quickly?
The fastest path is to set the environment variables shown above and restart your application. Anosys automatically generates dashboards and metrics from incoming data — you'll have visibility within minutes.
Next Steps¶
- Data Ingestion Options — all supported integration methods including REST API, JavaScript, and image pixels
- OpenAI Agents — native Python SDK integration for OpenAI
- Claude Code & Anthropic Agents — zero-code OTEL setup for Claude Code
- Custom LLM Integrations — connect any LLM provider via OTEL or REST API
- Network & Infrastructure — infrastructure monitoring guide
- FAQ — frequently asked questions about the Anosys Platform