IDG Contributor Network: 5 principles of monitoring microservices


I started programming when I was seven (on paper and without a computer, but that’s another story). One thing I learned early is that software development—like life—is full of trade-offs: Organizations and developers used to have to pick between performance or simplicity, innovation or manageability. But as microservices emerged as part of the container/Docker trend, application development was transformed into a set of small services, each running in its own process and communicating with mechanisms like an API. Microservices’ advantages are obvious: tremendous speed gains in software development and deployment, which saves money and, in the right circumstances, conveys a competitive edge to the organization.

I’ve talked with many devops folks over the last few years and learned a lot about their challenges. Those conversations have made it clear to me that as they embrace microservices, organizations need to rethink their software management practices as part of good performance and security hygiene. Use of microservices means changing the approach to software management, specifically how an organization handles monitoring of infrastructure, applications, and data. Left unchanged, organizations will be challenged to understand microservices performance, not to mention troubleshoot problems. Here are five ways to make your monitoring of microservices smarter and more responsive, not to mention, more efficient.

1. Monitor containers and what runs inside them

As the building blocks of microservices, containers are black boxes that span the developer laptop to the cloud. But without real visibility into containers, it’s hard to perform basic functions like monitoring or troubleshooting a service. You need to know what’s running in the container, how the application and code are performing, and if they’re generating important custom metrics.

And as your organization scales up, possibly running thousands of hosts with tens of thousands of containers, deployments can get expensive and become an orchestration nightmare. To get container monitoring right, you have a few choices: Ask developers to instrument their code directly, run sidecar containers, or leverage universal kernel-level instrumentation to see all application and container activity. Each approach has advantages and drawbacks, so you will need to review which one fulfills your most important objectives. The main point is that the old methods that worked with static workloads on VMs is just not going to cut it anymore.