Monitoring

Operational monitoring of a Smart Corridor stack has three layers: container health (is everything running), pipeline health (are events flowing), and biometric health (are identifications good). Watch all three — a stack can be green on containers while a disconnected camera silently produces zero identifications.

Container and service health

The stack is a Docker Compose deployment, so standard container monitoring applies: container state and restarts, host CPU/GPU, memory, and disk (PostgreSQL and S3 growth when storage is enabled). docker compose ps and docker compose logs <service> — run in the package root for the corridor services and in face-matcher/ for Face Matcher — are the first diagnostic stop; CIGS exposes a health endpoint at http://localhost:8096/actuator/health. Face Matcher's own metrics, traces and log locations are covered in Monitoring and Logs; feed both into whatever fleet monitoring you already run.

Pipeline health: events as a heartbeat

The most honest health signal is the event stream itself. A camera that streams but detects nothing, or an adapter that stopped translating, shows up as silence on the Hub's /graphql subscriptions. A lightweight watchdog that subscribes to the aggregate corridorEvents stream and alerts when a unit produces no events during expected traffic hours catches whole classes of failure that container checks miss. Station's live monitoring view tells you quickly whether the silence starts in Face Matcher or in the corridor.

Biometric health

Track the per-unit ratios of identification.match, no_match, and condition_violation over time. Drift in these ratios — with no configuration change — usually means the physical environment changed: seasonal light, a moved queue barrier, a dirty lens. The Officer Monitoring App gives the live view; for trends, consume the stream into your own metrics system via Consuming Events, and use Tuning Identification when the drift is real.