In this era of autoscaling and auto services discovery, services are coming, scaling up, and scaling down, as per the need. It all happens very dynamically. Your monitoring platform should be able to show the current number of machines running on a particular service and also show all predefined metrics for those machines, such as CPU load, memory load, traffic load, and so on. It should be dynamically added and removed. Some sort of history metrics should also be stored to know the peak traffic time, how many machines were up and servicing at what capacity. This helps the developer to tune code or autoscale parameters. The challenge this type of system will bring is, at high scale, this could result in running hundreds of agent services and eating up resources. Instrumenting the code inside a service itself will save a lot of headache for the operations teams.

Complexity, operation overhead, and monitoring work increase when we take microservice into the container's world. Containers have lots of promising features to make them a good choice for microservices. At scale, an orchestration service continuously spins up new containers as needed, which make challenges more interesting for DevOps teams to manually define which service should be accommodated in which container. So, to operate in dynamic and container-native environments, your monitoring system should be capable of spanning different locations, such as your AWS CloudWatch and your private data centers.