Web traffic logging: requests, routes, and real context
Build useful access logs while keeping observation points, latency boundaries, and visitor metrics distinct.
REQUEST VISIBILITY
Web traffic log APIEvery request has a point of view.
Understand routes, response outcomes, and latency while keeping edge, proxy, and application observations distinct.
{
"schema_version": "1.0",
"timestamp": "2026-09-21T09:41:02.184Z",
"severity": "INFO",
"event_id": "evt_demo_004",
"event_name": "http.request.completed",
"service": "edge-gateway",
"attributes": {
"method": "GET",
"route": "/docs/",
"status_code": 200,
"duration_ms": 18
}
}Synthetic fixture · nothing is sentDownload JSON ↗
DESIGN WITH INTENT
Keep the important distinctions.
Start with the route
Use stable route templates instead of customer-specific URLs.
Keep source context
A gateway response and an origin response answer different questions.
Measure carefully
Separate request counts from visitor or session measurements.
THE EVENT CONTRACT
Fields with a reason to exist.
Record where an event was observed before combining traffic from different layers. A request answered at the edge may never appear in an origin log. Decide which intermediary-provided values can be trusted and test the mapping when the proxy topology changes.
These fields illustrate a design pattern. Map them deliberately to your own schema, source, and destination.
| Field | What it means |
|---|---|
method | The observed HTTP method. |
route | A normalized path without private query values. |
status_code | The response code observed at this layer. |
duration_ms | Elapsed time at the documented observation point. |
Access logs describe observed requests. They do not automatically identify unique people or prove that an error response came from malicious traffic.
Technical reference: NGINX HTTP log module . Verify the version and settings used by your own implementation.
FIELD NOTES
Keep following the signal.
Firewall log analysis: from rule match to investigation
Preserve rule decisions, review false positives, and connect edge events to application evidence.
LLM observability: connect logs, traces, and outcomes
Trace retrieval, generation, validation, and retries without confusing model completion with application success.
ONE EVENT IS A GOOD START
Make your next log more useful.
Start with a clear schema. Keep the context that matters.