Watching the agent watch you: Telemetry for OpenClaw with NXLog

A traditional service is reasonably predictable. The same input mostly produces the same output, the same code paths fire, and a healthy run looks like every other healthy run. You can alert on what you do not expect.

An agent is the opposite. Two identical user prompts can take two completely different paths. The model decides which tools to call, in what order, and what arguments to pass. A small change in context can flip the plan. That makes "did anything go wrong?" a much harder question to answer from the outside.

The signals that matter are also different:

Four reasons to capture all of this:

OpenClaw exports OpenTelemetry out of the box. Common guidance is to point it at the OpenTelemetry Collector, then send each signal type to a dedicated backend: Loki for logs, Tempo for traces, Mimir for metrics, Grafana on top to visualize. That is five containers to deploy, five sets of config to maintain, five places something can go wrong.

It works. It is also more moving parts than most teams need on day one. Updates to any one component can cascade. Debugging where a record was dropped means tracing through the whole chain. And every extra hop is more latency between an agent doing something interesting and you finding out about it.

You can keep the OpenTelemetry standard and drop the orchestration. OpenClaw emits OTLP. NXLog Agent receives OTLP. From there, it routes to whatever you already have.

The standard recipe asks you to run a collector plus dedicated backends for each signal type (Loki, Tempo, Mimir) before Grafana ever sees the data. NXLog Agent collapses the middle of that pipeline. One process receives the OTLP stream from OpenClaw and forwards it on, with the same standards underneath. Note that Grafana is not a storage layer in its own right; it needs a data source behind it. In this walkthrough that is Elasticsearch, but any store with a Grafana data source (OpenSearch, ClickHouse, or Loki for logs alone) works the same way. From the same NXLog Agent process you can also fan out to a SIEM that ingests directly, or to cold storage like S3, in parallel and from the same config.

The rest of this post is the working setup.

Three containers in docker-compose: OpenClaw, NXLog Agent, and an Elasticsearch instance for Grafana to query.

OpenClaw’s diagnostics-otel plugin handles the export. Add this to ~/.openclaw/openclaw.json (or whatever path your container mounts):

Two things to call out. First, OpenClaw’s exporter only speaks http/protobuf; gRPC and JSON are not options today, so the NXLog Agent input has to accept protobuf over HTTP. Second, sampleRate: 0.2 keeps the trace volume manageable; you can raise it for staging or lower it for noisy production agents.

The im_otel input listens for OTLP on port 4318, and om_elasticsearch bulk-loads records into an index. No collector in between, no intermediate file. NXLog Agent converts the OTLP records to JSON and ships them with one HTTP request per batch:

Three details worth knowing. Index uses strftime() to roll a daily index (openclaw-20260430, openclaw-20260501, and so on), which keeps retention and lifecycle policies easy to express on the Elasticsearch side. The rename_field() call copies EventTime into @timestamp, the field name Elasticsearch and Grafana expect for time-series queries. And BatchSize 100 means NXLog Agent accumulates a hundred records before each bulk request, which is important for throughput once the agents are busy.

Start the three containers, send the agent a message, and within a minute or two (flushIntervalMs in the OpenClaw config controls this) records start landing in the index.

Three record types arrive, distinguished by RecordType. Here is one of each from a real run, the same JSON that goes into Elasticsearch.

A metric, queue wait time, as a histogram per lane:

A trace span, a single model call, with token accounting attached:

That single span tells you which model handled the turn, how long it took (about 11.8 seconds), and that it cost roughly 19,600 tokens. Multiply by a few thousand sessions a day and you understand why teams care.

A log, and this is where the angle of this whole post lands. Here is an ERROR record the agent generated during testing:

A few things are happening at once in this single log line:

Without the export, that exchange exists for a few seconds in process memory and then is gone. With it, you can answer questions like: which agents are fetching what URLs?, are any of those URLs untrusted?, did the guard markers actually surround the untrusted content? Those are not theoretical questions. They are the kind of question a security team is going to ask the first time an agent does something it should not have.

With records flowing into Elasticsearch under openclaw-, the data source side of Grafana is one configuration form: point Grafana at http://elasticsearch:9200, set the time field to @timestamp, and the index pattern to openclaw-. From there the panels are queries against fields you already have: openclaw.tokens.total summed by openclaw.model, openclaw.queue.wait_ms as a percentile, ERROR records filtered by openclaw.logger. A useful first dashboard might look like this:

The line chart on the left is the operational picture: token throughput per minute, broken out by model, with the tool-error rate overlaid. The spike on the red line is exactly the kind of thing you want to alert on, and because the underlying records are indexed log events, the panel underneath shows what was happening at that moment, including the prompt-injection-guarded 404 fetches the agent ran into.

None of these queries require special tooling. They are Elasticsearch aggregations on fields OpenClaw already emits. The same data shape works against OpenSearch, ClickHouse with the Grafana ClickHouse plugin, or any other store with a Grafana data source.

Indexing every event is a starting point, not a destination. Once the data is flowing through NXLog Agent, a few common next steps:

All of this happens in one config file, on one process, in one container. When you need to change a destination, you change one block.

Agents are useful precisely because they decide what to do on their own. That same property is why you cannot treat them like ordinary services. You need to see what they decided, what it cost, what they touched, and what came back, every time.

OpenClaw already produces that data. NXLog Agent turns it into something you can search, alert on, and keep. No five-container stack, no orchestration overhead, no custom collector to maintain. One agent, one config, the destinations you already have.

If you want to try this against your own stack, the im_otel and om_elasticsearch module docs cover the directives in full, and we are happy to help if you run into anything in your setup. Reach out to us through the links below.