Infrastructure Observability
Not a second observability course — the depth lives in the Observability & Performance domain. What is specific here: instance and pod health, autoscaling behaviour, load balancer target health, control-plane events, cloud service errors, audit trails and the question "who changed this infrastructure, and from where?".
Not a second observability course. The signals that belong to the platform rather than the application — resource envelope, instance and pod health, autoscaling behaviour, load-balancer target health, provider service errors and the bill — and which of them stays reassuringly green through an outage.
Q · Which signals tell me the platform underneath the application is healthy, and which one lies?
Five log streams your application never writes — audit, access, load balancer, control-plane and deployment — and the specific question each one is the only source for. Plus the reason they are a top-five line item on the bill.
Q · When the application log says nothing useful, which infrastructure log stream holds the answer?
Who changed this infrastructure, what did they change, when, and from where? The four questions an audit log exists to answer — plus the two honest caveats: the log is worthless if nobody reads it, and the identity in it is meaningless if six services share one key.
Q · Who changed this infrastructure, what did they change, when, and from where?