Skip to content

Observability

Operators should separate liveness from readiness, and track request-rate / error / latency SLIs from Prometheus metrics scraped on the peer.

Health endpoints

PathMeaningTypical use
GET /health/liveProcess is upKubernetes / VM liveness — always 200 with { "status": "alive" } when the process responds
GET /health/readyCredentials + Fabric gateway healthyReadiness / load balancer — 200 healthy or 503 unhealthy
GET /healthLightweight credentials checkCoarse health JSON (credentials on disk)
GET /health/startupStartup probeCredentials present before accepting traffic

Prefer /health/ready before sending sync or token traffic. Prefer /health/live only to detect a dead process — it does not prove Fabric is reachable.

SLIs

Track these for Peer REST (from /metrics histograms and counters):

SLIDefinition
RPSRequest rate by route group (assets, tokens, health, …)
Error %Share of responses with status ≥ 500 (and optionally 4xx for client-error budgets)
p95 latency95th percentile request duration for token and asset routes

Alert on sustained error% or p95 regressions after deploys / chaincode upgrades — not on single-request noise.

Metrics scrape

GET /metrics exposes Prometheus text. It is intended for localhost / VPC scrapers (e.g. Alloy on the VM), not public internet access.

Was this page clear?