OpenTelemetry-native APM

Connect in two minutes

OpenTelemetry SDKs and Collectors are configured with environment variables. Point the traces endpoint at your jentry project and pass your project key as a header — that is the whole integration:

export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://jentry.app/api/<projectId>/otlp/v1/traces"
export OTEL_EXPORTER_OTLP_HEADERS="x-jentry-key=<your project key>"
# protobuf (the SDK default) and http/json are both accepted — no protocol switch needed

Both OTLP/HTTP encodings are supported out of the box: http/protobuf (what SDKs send by default) and http/json. Gzip-compressed bodies are handled, responses follow the OTLP spec (including partialSuccess), and rate limiting uses standard 429 + Retry-After.

Node.js

// npm i @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-proto');

new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'https://jentry.app/api/<projectId>/otlp/v1/traces',
    headers: { 'x-jentry-key': '<your project key>' },
  }),
  instrumentations: [getNodeAutoInstrumentations()],
}).start();

Python

# pip install opentelemetry-distro opentelemetry-exporter-otlp-proto-http
# then run your app with auto-instrumentation:
OTEL_TRACES_EXPORTER=otlp \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://jentry.app/api/<projectId>/otlp/v1/traces \
OTEL_EXPORTER_OTLP_HEADERS=x-jentry-key=<your project key> \
opentelemetry-instrument python app.py

Or through an OpenTelemetry Collector

exporters:
  otlphttp/jentry:
    traces_endpoint: https://jentry.app/api/<projectId>/otlp/v1/traces
    headers:
      x-jentry-key: <your project key>

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/jentry]

What you get

• Trace waterfalls with the real span tree — children nested under parents via parent_span_id, errored spans flagged red.
• Automatic performance issues from your OTel spans: N+1 queries, N+1 API calls and slow DB queries, each with span evidence and estimated time saved.
• Per-route transaction stats: p50/p95/p99, throughput, failure rate and Apdex.
• Insights modules (DB, HTTP, cache, queues) grouped from OpenTelemetry semantic conventions.
• Cross-service traces stitched by trace id — instrument two services, see one waterfall.
• The same quota, rate-limiting and alerting pipeline as every other jentry event.

How the mapping works

Within each resource batch (one service), every local-root span — a span whose parent is not in the batch — becomes a transaction; its descendants become that transaction's span tree. Semantic-convention attributes drive everything else:

• db.system → db spans (redis/memcached become cache); db.statement is kept as the span description for grouping and N+1 evidence.
• http.request.method + url.full → http.client or http.server spans, with 4xx/5xx mapped onto span status even when OTel leaves it UNSET.
• messaging.system → queue.publish / queue.process; rpc.system → rpc spans.
• service.name → a service tag; service.version → the release; deployment.environment → the environment.