Monitoring Windows on Docker and Kubernetes
Monitoring performance in cloud native way on Docker and Kubernetes is not new and used widely by industry today, but not for Windows. There are many choices, including Prometheus or other time series databases.
TL;DR You can start monitoring Windows containers on Docker and Kubernetes on any cloud free: more details about using Sonar monitoring agent with Prometheus are shown in this video. Case study from using Sonar is available here.
In addition, there are many metric collection agents, including FluentD, StatsD, Telegraf and many others. Which raises the question, why create another metric collector, especially for Windows platform? There are some compelling reasons:
- Flexibility to choose where to store telemetry - in time series database or monitoring system of your choice.
- Building Windows containers to expose metrics regardless of an orchestrator.
- Focus on key metrics that matter to your business without worrying of anyone’s cloud business.
- Cloud native. This simply means you can deploy and monitor Windows container to any cloud, not necessary Azure.
- No monitoring system fits all — for example, while Prometheus is great for metrics, it cannot be used for tracing events. Thus, if you need log monitoring and aggregation, you have to look for other options.
Writing metric collector (codename Sonar) in .NET Core was reasonable option because it can be portable across platforms. In addition, most metric collectors like Fluentd only have “experimental” version for running on Windows and have no support for Nano Server containers. Below are few learnings from that experience:
- Modernizing Windows applications by moving them to containers does not give you operational visibility unless you are able to gather key metrics to monitor internal resources they consume. Most of these metrics are not exposed by container orchestrators.
- Monitoring Windows application anywhere ( Nano Server, VM or host) requires access to WMI, performance counters and relational database to gather runtime metrics. The latter applies for SQLServer and MySQL. Sonar supports all of these inputs.
- Deploying monitoring agent comes with two scenarios: daemon and sidecar. Thus agent is either isolated process within given or separate container responsible to expose metrics you configured to target system of your choice.
- For Prometheus support, it is important to deploy quickly using Helm chart to Kubernetes.
- Metric collection agents may or may not not support multiple monitoring back-ends. For example, Sonar event log monitoring can be configured for sending data to InfluxDb while metrics can be exposed to Prometheus. In addition to Prometheus and InfluxDB , Sonar can send metrics to Akumuli time series database.
- Customer scenarios are mostly about the inputs: some ask for getting data from 3PAR storage, MySQL, SQLServer etc. The input adapter for Sonar for gathering data from MySQL less than 50 lines of simple code. The complexity for gathering data from SQL Server is about the same.
- Gathering every metric has cost associated with it. Unlike Sonar, most collectors do not report their own internal metrics.
- Performance efficiency is the key. Each collector should consume minimal resources for gathering metrics. The illustration above shows Sonar metrics collected from Windows container (Nano Server in-process isolation): perf counters, disks space and event logs.
- Cross-platform is supported by the .NET Core. The Helm chart mentioned above uses Sonar container for Unix.
In other words, companies like Docker who advocate modernizing traditional Windows applications do not provide complete end-to-end story. This is confusing for customers who have to figure out on their own what to monitor and how after packaging Windows application as container.
Fortunately, you may not have to now. Sonar monitoring agent is licensed under BSD. Feel free to get binaries and WebAPI sample available in this repository on GitHub or watch video on YouTube.com
