ObserveKit Help
Back to app

Troubleshooting: I see no data

Work top-down. First figure out which path you're on — agent (Kubernetes/Docker source) or OpenTelemetry (service source) — then jump to that section.

First checks (both paths)

  • Scope. The source switcher at the top of every page scopes what you see. Set it to All sources (or the right one) — you may be looking at the wrong scope.
  • Time range. Widen it. If you just started sending data, the default window may predate it.
  • Source status. On the Sources page, is the source CONNECTED / OTLP RECEIVING (green), or DISCONNECTED / no data yet?

Agent path (Kubernetes / Docker)

Source stuck on DISCONNECTED / "no data yet"

The agent isn't reaching the server. On the node(s):

# Kubernetes
kubectl -n observekit get pods -l app=observekit-agent
kubectl -n observekit logs -l app=observekit-agent --tail=100
# Docker
docker logs --tail=100 observekit-agent

Look for:

  • RBAC denials (forbidden, cannot list pods) → the ClusterRole/Binding didn't apply. Re-run the install command; confirm you had permission to create cluster-scoped RBAC.
  • Connection refused / timeout / TLS errors → the cluster can't reach the server. Confirm outbound HTTPS egress and DNS to observekit-api.expeed.com from the node.
  • No agent pods at all → kubectl -n observekit rollout status daemonset/observekit-agent; check node taints/tolerations if pods aren't scheduling.

Connected, but a specific namespace/pod's logs are missing

The agent filters at collection time. Check the ConfigMap:

kubectl -n observekit get configmap observekit-agent -o yaml

kube-system and pods labelled observekit/ignore: "true" are excluded by default. Confirm your namespace/label/container isn't caught by a filter, and watch for drops:

kubectl -n observekit logs -l app=observekit-agent --tail=50 | grep -i filter

> A YAML parse error in the ConfigMap makes the agent fall back to "no filters" and ship everything — so a filter that "isn't working" is usually an indentation typo. See Agent configuration.

OpenTelemetry path (service source)

Read your app's logs for OTLP exporter errors first — the SDK reports the exact HTTP status. Then match it below.

401 Unauthorized

The API key isn't reaching the server.

  • Confirm the header: X-API-Key: <key> or Authorization: Bearer <key>.
  • Watch the header form — a common mistake is X-API-Key=Bearer <key> (the word Bearer ends up inside the key value). Use one scheme, not both.
  • Confirm the key matches a source on this server (keys are per-source and environment-specific).

400 Bad Request / "unable to parse"

The body couldn't be decoded.

  • Endpoint path. Point the SDK at the base URL (https://observekit-api.expeed.com) and let it append /v1/traces etc. Don't hard-code the wrong path or protocol.
  • Protocol vs. port. Use http/protobuf for the HTTPS URL (port 4318). Port 4317 is gRPC — only use it with protocol=grpc.
  • Compression. gzip and zstd are supported. (If you're on an older ObserveKit server that rejected gzip, upgrade the server — current versions decompress it.)
  • Body too large. The per-request cap is 10 MiB. If you send huge batches, lower the SDK's max export batch size.

Source stuck on "no data yet" / "OTLP idle" though the app started

  • The SDK batches — most flush every ~5s. Generate traffic and wait one interval.
  • Confirm the app can actually reach observekit-api.expeed.com:443 (egress/DNS/proxy).
  • Check the app logs for exporter errors (connection refused, DNS failure).

Data arrives but the service shows as unknown_service

Set OTEL_SERVICE_NAME (or the service.name resource attribute). Many SDKs default to unknown_service when neither is set — so your data is there, just under the wrong name. Filter the Traces/Logs views by service.name.

Still stuck?

  • Send a manual OTLP smoke test to isolate app-vs-server: a single POST /v1/logs with your key and a tiny OTLP JSON body should return 200 {}. If the smoke test works but your app doesn't, the problem is in the app's OTel config, not ObserveKit. See Sending data with OpenTelemetry.
  • Verify the key maps to the source you're viewing (an OTel app can only land data in the source its key belongs to).
PreviousCore conceptsNextInvestigating a problem