architagr / architagr/LogNugget
V4-BENCH: zerolog vs LogNugget — real Loki sink latency benchmark harness
- Dominant language
- Go
- Stars
- 2
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
## Goal
Measure the **API handler latency impact** of zerolog vs LogNugget V3/V4 under realistic conditions: logs emitted to a real Loki instance over HTTP.
## Why this matters
All current benchmarks use a mock in-memory writer. With a real Loki sink (HTTP POST, network round-trip), async loggers like LogNugget decouple caller latency from IO latency — sync loggers block the goroutine during the write. This benchmark will show whether LogNugget's async pipeline provides measurable API latency reduction vs zerolog under real IO.
## Structure
```
examples/loki-bench/
├── cmd/
│ ├── zerolog-server/main.go # HTTP server using zerolog → Loki
│ └── lognugget-server/main.go # HTTP server using LogNugget → Loki
├── loki/
│ └── docker-compose.yml # Loki + Grafana stack
├── load/
│ └── k6.js # k6 load test script (constant 1000 rps)
└── README.md
```
## HTTP server shape
- Single endpoint: `GET /api/v1/work`
- Simulates 1 ms of CPU work (tight loop)
- Logs 1 structured event per request: `level=info msg="request" method=GET path=/api/v1/work status=200 latency_us= trace_id=`
- 4 log fields: method, path, status, latency
## Load test
- Tool: k6
- Rate: 1000 req/s sustained for 60 s
- Goroutines: GOMAXPROCS=8
- Metrics captured: p50, p95, p99, p999 handler latency (from k6), allocations/op (from pprof)
## Loki sink config
- zerolog: `zerolog.New(lokiWriter)` where `lokiWriter` is a buffered HTTP writer
- LogNugget: `config.SetContextFieldsAppender(...)` + ring → Loki pre-processor hook
## Expected outcome
Under 1 ms CPU work + Loki IO (typically 2–10 ms round trip):
- zerolog: handler p99 ≈ CPU_work + IO_wait ≈ 3–11 ms (blocked on Loki write)
- LogNugget: handler p99 ≈ CPU_work + ring_push ≈ 1.2–1.5 ms (Loki write is async)
## Acceptance criteria
- Both servers run against the same Loki instance via docker-compose
- k6 report shows p50/p95/p99/p999 for each server
- pprof alloc profile captured at 500 rps steady state
- Results documented in `examples/loki-bench/README.md`
Contributor guide
Research direction
Start with the proposed entry points in examples/loki-bench/cmd/zerolog-server/main.go and lognugget-server/main.go, then inspect loki/docker-compose.yml and load/k6.js. Run both servers against the shared Loki stack and execute the 1000-rps k6 test. Done means the requested latency percentiles and pprof allocation profiles are captured, with results documented in examples/loki-bench/README.md.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker-compose, go
- Domain
- backend, observability, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100