Container Monitoring Solution:
We describe a Log Analytics workspace that helps with monitoring containers hosted on an orchestration framework. This article is intended to be generic so that the salient features of a container monitoring solution are called out rather than the specifics of a container. This article therefore avoids discussion of other overlapping production level considerations such as specific security context capabilities where certain specific actions such as binding to all network interfaces are permitted without giving full root access. The purpose of this article is to focus exclusively on a container monitoring solution without any restrictions.
Public clouds have made system operations monitoring a breeze with their proprietary and even altruistic solutions that work across containers from one another.  They begin with a Log Analytics agent and integrate with their externally offered cloud services. The techniques for gathering the logs by these agents are also dependent on the operating system flavor where the orchestrator engine is hosted. These hosts are even given specific global identifiers to enable their lookup in the corresponding global inventory.
As with all agents and services on a container, a secret or an account is required to control the accesses to resources for their activities. This role based access control, namespace and global naming conventions is a prerequisite for any agent.
The agent has to run continuously forwarding data with little or no disruption. Some orchestrators facilitate this with the help of concepts similar to a Daemonset that run endlessly. The deployment is verified to be working correctly when a standard command produces an output same as a pre-defined output. Verification of monitoring capabilities becomes part of the installation feature.
The log analytics agent needs to have a controller or gateway to send the report. It can work autonomously with little or no context provided from the controller but the data needs to make its way to a store or service. This is facilitated by binding the agent to its destination.
Almost all activities of any resource in the orchestrator framework can be logged. These include the core system resources which may spew the data via switches in the auditing framework. The option to log and consolidate logs from applications framework and user modules are often tied to the location and publications of logs from them.
Specific queries govern the monitoring for the log analytics. These are well-prepared and part of a standard portfolio of monitoring charts that help with the analysis of the health of the containers.
Specific logging implementation is discussed in an earlier article as outlined here