Aside from the aforementioned two components, we also need to check the statuses of dependent components, such as the utilization of external storage, or the consumption rate of a queue. For instance, let's say we have an application that subscribes to a queue as an input and executes tasks from that queue. In this case, we'd also need to consider metrics such as the queue length and the consumption rate. If the consumption rate is low and the queue length keeps growing, our application may have trouble.

These principles also apply to containers on Kubernetes, as running a container on a host is almost identical to running a process. However, because of the subtle distinction between the way in which containers on Kubernetes and on traditional hosts utilize resources, we still need to adjust our monitoring strategy accordingly. For instance, containers of an application on Kubernetes would be spread across multiple hosts and would not always be on the same hosts. It would be difficult to produce a consistent recording of one application if we are still adopting a host-centric monitoring approach. Therefore, rather than observing resource usage at the host only, we should add a container layer to our monitoring stack. Moreover, since Kubernetes is the infrastructure for our applications, it is important to take this into account as well.