Observability
Logs, metrics, and status for your services
Observability
Parslinks collects logs and metrics from your running replicas and exposes them in the dashboard. High-volume telemetry (log events, metric samples) is stored in ClickHouse; service status lives alongside platform state so the dashboard can render it fast.
Logs
Every replica streams its stdout/stderr into the log pipeline, tagged with the full identity chain — workspace → project → environment → instance → workload → replicaId.
In the dashboard you can:
- Follow live logs for a service or drill into a single replica
- Filter by environment to separate production noise from previews
- Jump to the exact build logs for any historical deployment (build logs are retained with the deployment)
replicaId in a log line is the same identifier used by metrics and the
console — one identity across all observability surfaces.
Metrics
Metrics are collected per replica on a short interval and aggregated in the dashboard:
| Area | Examples |
|---|---|
| Compute | CPU %, memory usage vs limit |
| Network | Public HTTP bytes served, per-replica rx/tx |
| Volume | Used vs declared capacity |
| Replica readiness | Ready count over time |
Aggregations sum across replicas by default; group by replicaId to see
per-member detail (useful for spotting an unhealthy replica behind a healthy
average).
What's collected from your app
Nothing is injected into your code. All compute metrics come from the container runtime, network metrics from the platform endpoint, and health from external probes. No agent, sidecar, or library is required.
Status
Service status (running / paused / degraded) is derived from observed replica readiness — not from what the platform intends to run. If placement says 3 replicas but only 2 pass probes, status reflects reality, and public traffic only ever reaches the ready ones.