Skip to main content
Use this guide to quickly diagnose and resolve issues with your Traversal Processor.

​
Where to look first

  • The Processors tab in the Traversal web app shows each Processor’s status, activity, and metrics.
  • Ingested data. When the logs you send don’t show up in Traversal, or investigations lack detail while the Processor still looks healthy, the problem is usually in your config rather than the Processor itself.
The status and activity labels often point to the problem:
  • Online — healthy and sending data to Traversal.
  • Offline — Traversal hasn’t heard from the Processor recently, or its certificate is missing or expired.
  • Receiving data — logs are coming in and getting processed.
  • Not receiving data — the Processor is up, but no logs are arriving.
  • Processing failed — logs are arriving, but the Processor can’t read them.
  • Backpressure — more data is coming in than the Processor can keep up with.
  • Volume (4h) — how much data came in over the last four hours.
  • % accepted and % deferred — how much data the Processor kept up with, and how much it had to shed.

​
Common issues

Traversal isn’t getting health reports, though the Processor itself may still be running.
  • The certificate is missing or expired. Re-issue it, then redeploy. The Certificate row shows the expiry date.
  • Outbound traffic is blocked. Allow outbound access to your Traversal domain.
  • The domain, org ID, or deployment ID is wrong or unset. Set them to the values Traversal gave you.
  • You’re using old config variable names, which silently fall back to defaults. Use the current names.
A Processor running on a static config sends no health reports, so it shows Offline even while it works.
The Processor is up, but nothing is arriving.
  • Nothing is wired to it yet. Point your log source at the Processor.
  • Your exporter uses the wrong address or port. Check the endpoint for the format you send (native JSON over HTTP, OTLP gRPC, or OTLP HTTP).
Logs arrive, but the Processor can’t read them.
  • The payload format doesn’t match the port you send to. Match the format to the endpoint.
  • Your exporter sends a shape the Processor doesn’t expect. Check your exporter’s output.
More data is coming in than the Processor can keep up with, so it starts shedding load. You have two ways to fix it.
  • Expand the Processor deployment. Scale the size up from normal to large, and add replicas for more headroom.
  • Send less data. Filter or sample at the source so you forward only the logs you need.
See sizing and throughput for what each size handles.
Some data never lands, and no metric flags it — usually because the batches are too big.
  • Your OTLP batches are over the size limit and get rejected. Raise the batch size limit, or send smaller batches.
The chart is public, but cached registry credentials block the pull.
  • Run helm registry logout and docker logout, then try the pull again.

​
Still stuck?

If your issue isn’t listed here, or a fix didn’t work, email support@traversal.com or contact your Traversal representative. Include your Processor’s name, what the status shows, and — if you have them — the image digest and chart version. Two cases are usually on our side, so reach out right away:
  • You see intermittent 401 errors even though your certificate is valid. Retry the failed batches, then contact us.
  • You ingest through a CloudWatch subscription and see no data.