Database Container Metrics Need Engine Metrics Beside Them

High database container CPU or memory can be an important symptom, but it cannot identify whether the engine is busy with useful work, blocked transactions or internal maintenance. What made the issue measurable was container CPU/memory/restarts plus engine-specific metrics. Runtime metrics explain resource consumption while engine metrics explain database behavior; treating one as a substitute for the other leaves a large diagnostic gap.

I classify this as cross-layer database observability. The useful debugging sequence is to confirm the signal, compare it with the neighboring subsystem, then look at logs or detailed metrics only after the failure domain is smaller.

The production rule that came out of it is: Put database containers and deep engine panels within one workflow so operators can move from resource symptom to transaction or connection evidence quickly. This is deliberately more specific than adding another broad alert with no response procedure.

Commit b65d5d4 is the repository evidence behind the note. It provides the concrete configuration or fix that turned the observation into a repeatable monitoring control.