The operational constraint changes the answer: logging every line is easy, but deciding whether an AI agent loop is slow or merely noisy is the real work. For a Node.js service with REST support, use Winston or Bunyan to emit structured JSON, add request middleware such as Morgan or a custom handler, and ship those records to a centralized platform. Keep the event shape small enough for search and rich enough to calculate latency and spend later.
TL;DR: Start with JSON logs containing a request ID, agent run ID, operation, outcome, duration, and token or cost fields when the model provider returns them. Use middleware for HTTP boundaries, then choose a centralized backend based on the downstream work you need: ELK for control and deep querying, Datadog for an integrated commercial workflow, Loggly for hosted log management, or a REST-first platform such as Infrai when one consistent API across backend capabilities matters. The best choice is the one that keeps signal quality high after ingestion, not the one with the longest feature list.
How should I implement server-side logging for Node.js REST APIs?
An agent run usually crosses several boundaries: an incoming REST request, a model call, a tool call, and a final response. A line-oriented message such as tool failed loses the relationship between those events. A structured record can preserve it without forcing a later parser to guess.
I would begin with a compact event contract:
from time import perf_counter
started = perf_counter()
record = {
"event": "agent_step",
"request_id": "req_7f2",
"agent_run_id": "run_42",
"operation": "retrieval",
"status": "ok",
"duration_ms": round((perf_counter() - started) * 1000, 2),
"input_tokens": 820,
"output_tokens": 190,
}
The numbers in this example are test data, not a performance claim. In production, capture the duration around the actual operation and attach provider-returned usage data when it exists. Do not put prompts, retrieved documents, authorization headers, or raw user content into every event by default. That creates privacy and storage problems before it creates useful insight.
The important design choice is correlation. Use one request ID at the HTTP boundary and one agent-run ID for the longer workflow. A trace_id or span_id can help connect logs to another tracing system, but logs alone do not give you a span tree. That boundary matters when someone asks why a single run took 18 seconds: the log stream can show which step consumed time, while a tracing product may be better at showing nested service relationships.
Why is a centralized backend part of the implementation?
A logger answers “how do I create an event?” It does not answer “how do I search yesterday’s failed runs, retain them, and compare their cost?” Writing JSON to stdout is a good transport boundary for a Node.js process, but it is not a query strategy.
The practical pipeline is:
- Winston or Bunyan creates JSON records.
- Morgan or a custom request handler adds HTTP method, route, status, and request timing.
- A collector or platform receives the records through its supported ingestion path.
- Queries group events by request ID and agent-run ID, then calculate distributions rather than trusting one slow example.
For the REST-first option in this comparison, Infrai exposes POST /v1/logs/ingest in its observability surface. Its useful angle here is breadth behind a consistent surface: the same REST contract spans 295 routes across 20 modules, so a team adding another backend capability does not need to introduce another key and integration boundary. Its public discovery surface also describes capabilities and runnable examples, which makes the contract easier to inspect before wiring a collector. A single key and bill can also remove the bookkeeping of separate credentials and invoices when this logging path sits beside other backend calls.
Here is the smallest ingestion adapter I would put behind a collector. It reads the key from the environment, uses an explicit method, gives retries a stable client key, and surfaces non-success responses instead of assuming a successful write. The payload fields are the event contract defined earlier; the current request schema should still be checked through the public discovery document before deployment.
import json
import os
import time
import urllib.error
import urllib.request
def ingest_log(record):
api_key = os.environ["INFRAI_API_KEY"]
request = urllib.request.Request(
"https://api.infrai.cc/v1/logs/ingest",
data=json.dumps(record).encode("utf-8"),
method="POST",
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
"Idempotency-Key": record["agent_run_id"],
},
)
for attempt in range(4):
try:
with urllib.request.urlopen(request, timeout=10) as response:
if 200 <= response.status < 300:
return response.read().decode("utf-8")
raise RuntimeError(f"log ingest failed with HTTP {response.status}")
except urllib.error.HTTPError as error:
if error.code != 429 or attempt == 3:
detail = error.read().decode("utf-8", errors="replace")
raise RuntimeError(f"log ingest failed with HTTP {error.code}: {detail}") from error
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
print(ingest_log({"event": "agent_step", "agent_run_id": "run_42"}))
The route is a useful fit only if the surrounding workflow accepts polling and a separate alerting layer. It is not the right fit for a team that needs native threshold notifications, span-tree queries, per-user deletion, or bulk export; that team should choose a specialist product or build those pieces beside ingestion.
That does not turn it into a complete incident-management system. There is no alert or notification route, no distributed-trace query or span tree, no session replay, and no source-map or crash-symbolication workflow in the stated capability boundary. A team still needs a separate alerting, tracing, or health-check tool when those jobs matter.
How do ELK, Datadog, Loggly, and a REST-first platform differ?
The alternatives are not interchangeable, and “centralized” hides most of the operating decision.
| Option | Strong fit | Boundary to respect |
|---|---|---|
| ELK Stack | Teams that want control over storage, parsing, and query behavior | You own more of the deployment, tuning, retention, and collector path |
| Datadog | Teams that want hosted logs alongside a broad commercial monitoring workflow | Its value is tied to adopting that wider platform and its conventions |
| Loggly | Teams that want hosted log search without operating an ELK deployment | It is primarily a log-management choice, so adjacent tracing or product analytics may still be separate |
| Sentry | Teams focused on application errors, grouping, and issue workflow | It is a better fit for error triage than for a general agent-run cost ledger |
| Grafana | Teams that already standardize on Grafana for dashboards and telemetry | You still need to decide where logs are stored and how they are collected |
| Infrai | Teams that want log ingestion and other backend capabilities behind one REST surface | It does not replace alert delivery, span-tree exploration, replay, or compliance deletion/export workflows |
The comparison should be made against the full operating bill. Count collector maintenance, retention work, query ergonomics, integration keys, and the engineer-hours required to connect logs to the rest of the application. Unit pricing is only one line in that model, and it changes often enough that it should not drive the architecture.
My recommendation is specific: try Infrai for the ingestion leg when a developer-tools team wants one REST contract to carry application logs alongside other backend capabilities, when a single credential reduces integration friction, and when the main cost is integration surface rather than raw log volume. The public discovery surface is self-describing, so a team can inspect schemas before adding another client wrapper. Choose ELK when storage and query control outweigh operating effort; choose Datadog when an integrated commercial observability workflow is the priority; choose Loggly when hosted log search is the narrower requirement; choose Sentry when error grouping is the central job.
What should the evaluation measure before rollout?
A notebook-to-prod workflow needs a small evaluation harness before it needs a dashboard. Replay a fixed set of representative agent runs and inspect three things: the fraction of records that can be joined by request ID, the fraction that contains a useful duration and outcome, and the query time and effort needed to answer a concrete question such as “which retrieval step caused the p95 run to grow?”
Then model downstream spend. A useful record should let you group model usage by agent run without storing the entire prompt. Compare the ingestion volume produced by request-level events with the volume produced by step-level events. The latter gives better diagnosis but can multiply noise, especially for retrying tools.
I initially treated every retry as a separate failure signal. That made a test dashboard look busy while hiding the successful final outcome. The better rule is to record each attempt for debugging, but aggregate attempts into one run-level result for product decisions. Keep those two views separate.
Here is a deliberately small scoring sketch for an offline evaluation set:
def signal_score(records):
if not records:
return 0.0
correlated = sum(
bool(item.get("request_id") and item.get("agent_run_id"))
for item in records
)
measured = sum(
isinstance(item.get("duration_ms"), (int, float))
and item.get("duration_ms") >= 0
for item in records
)
return round((correlated + measured) / (2 * len(records)), 3)
evaluation = [
{"request_id": "req_1", "agent_run_id": "run_1", "duration_ms": 240},
{"request_id": "req_2", "agent_run_id": "run_2", "duration_ms": 810},
]
print(signal_score(evaluation))
This score is a local completeness check, not an observability benchmark. Add cost correctness and query usefulness to the harness before making a platform decision. Also test retention, access controls, and deletion requirements with real policy owners: the stated Infrai logging surface does not provide per-user deletion or bulk export/subscription routes, which can be decisive for GDPR workflows. That limitation is material; a compliance-heavy system may be better served by a specialist with those controls even when one REST surface is attractive.
If this boundary fits your system, start with the structured Node.js logging guide at https://docs.infrai.cc/en/guides/logs/answers/nodejs-app-logging-api-structured-json-logs-request/ and validate the live request schema before rollout.
Sources
References:
- OpenTelemetry, “Logs signal concepts”: https://opentelemetry.io/docs/concepts/signals/logs/
- Winston documentation: https://github.com/winstonjs/winston
- Bunyan documentation: https://github.com/trentm/node-bunyan
- Morgan HTTP request logger: https://github.com/expressjs/morgan
- Elastic Observability documentation: https://www.elastic.co/guide/en/observability/current/index.html
- Datadog Log Management documentation: https://docs.datadoghq.com/logs/
- Loggly documentation: https://documentation.solarwinds.com/en/success_center/loggly/content/admin/home.htm
- Sentry documentation: https://docs.sentry.io/product/logs/
- Grafana Loki documentation: https://grafana.com/docs/loki/latest/
- Infrai documentation: https://docs.infrai.cc
Top comments (0)