Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Windows Containers: How About Application Monitoring?

DZone's Guide to

Windows Containers: How About Application Monitoring?

With container development gaining traction, make sure you're prepared to monitor your applications by learning about Windows container monitoring.

· Performance Zone ·
Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

Previously we've talked about new developments in the container space with the introduction of Windows containers and the possibility of Hybrid (Windows/Linux) container environments. In our third and final edition of the Windows container blog posts, we want to spend some time talking about application monitoring in Windows container environments.

Microsoft has been making great strides pushing the Windows container space with releases of IIS, SQL Service, and the much-loved DotNET Core ecosystem. DotNET Core is used by a whopping 27% of developers. Pretty cool for only being two years old! The 2.1 release is bringing some juicy new features and performance improvements, so expect this to only increase. Bringing these new (and sometimes old) applications to containers is the logical step in the Windows ecosystem.

But wait, before you start copying all your applications to Windows containers you need to know a few things. Windows containers are not Linux containers. There are some key differences that you need to keep in mind when moving. The biggest one is the difference between HyperV Containers and Windows Containers, as explained in our previous article. There are also network differences and a general stricter environment compared to Linux. Luckily we still get the familiar Docker CLI and the extra bonus of advanced Powershell integration.

What About Monitoring?

The logical question to ask once you've prepared your application for deployment in Windows containers is: how to monitor it? The isolated principle of containers means that you are working with a lot more restrictions than normal. Most tools solve this by installing an Agent or Service within your container itself, but following the Docker principle that each container should have only one concern, this isn't really a best practice. And there are implications on the overhead added to each container. Ideally what you want is to install one monitoring container on each of your hosts that collects both application metrics and general resource and Docker metrics.

Will It Scale?

An element of the container-native monitoring story that we haven't talked about yet is the scalability. The monitoring system you choose should scale automatically with the number of containers that are running. It really shouldn't matter if you run your application once or a hundred times.

In addition, we believe a monitoring system should always make the trade-off between resource usage and visibility. Intrusive techniques such as bytecode instrumentation can be powerful, but also have a performance penalty on your environment. Every % of resources you lose to monitoring is a direct increase in server costs in addition to the price of the monitoring itself.

So, in conclusion, a container monitoring tool should:

  • Deploy as a container whenever possible
  • Not require you to add additional binaries to your images
  • Scale together with your environment
  • Have as minimal an impact as possible

Windows Container Monitoring Done Right

At CoScale, we do just that, we install a single privileged Docker container on each Linux host, or in the case of Windows, we install our Agent as a Windows Service.

The reason we don't use a Docker container on the Windows platform is that privileged containers are (currently) not supported, and named pipes, for Docker API access, is not available in the current release but will be added in Windows Server 2019.

The CoScale Agent itself is then responsible for monitoring the containers, applications, and OS of your machine. If you want to check out how to install and configure the CoScale agent I advise to look at our previous blogpost on monitor a Hybrid environment.

CoScale application monitoring is built from the ground up to be container-native. This means that you don't need to expose or mount part of your running container for the monitoring to be able to operate. CoScale does this by launching its plugins inside the container, so it can access the local container network, disk and see whatever your applications sees. This works for both Windows Containers as Hyper V containers.

How to Set It Up

Let's take an example from our Docker adapted repository. Below, you can see a Dockerfile with Microsoft SQL Server Developer Edition, specifically configured for CoScale monitoring.

FROM microsoft/mssql-server-windows-developer
LABEL com.coscale.monitoring='[{"PluginType":"MSSQL","Configuration":{"QUERY STATS":["true"],"INTEGRATED SECURITY":["LOGIN"],"USERNAME":["sa"],"PASSWORD":["$sa_password"],"HOSTNAME":["localhost"],"PORT":["1433"]}}]'

There are a couple of things that I would like to point out:

  1. HOSTNAME "localhost": The CoScale MSSQL plugin will launch from inside the container, this means localhost is the container itself, and not the host operating system.
  2. PORT "1433: Because we are running inside the container, this port is always available and does not need to be exposed. This means no outside access is required.
  3. PASSWORD "$sa_password": Here our plugin will take the environment variable 'sa_password' from inside the container and use it to authenticate with the MSSQL. So whatever the password is set to, CoScale will have the right credentials to authenticate with your server at runtime. CoScale also supports Docker and Kubernetes secrets for this reason.

Once set up, the agent will automatically run the MSSQL plugin with the matching configuration in every container image that contains MSSQL. These metrics can then be visualized in MSSQL dashboards that are automatically generated in the CoScale application.

Another way to setup CoScale for application monitoring is through "Image detection". Instead of adding a Label to your Dockerfile, you define the specific images you want to monitor. CoScale will then continuously scan your system for these images to start the monitoring when needed. Image monitoring supports the same mechanisms as the label system, so you can again use environment variables and secrets.

If you're interested in seeing other examples, make sure to check out our Docker Adapted repository. It contains an IIS example (see dashboard below) and also a lot of Linux ones.

Window(s) Shopping

The Windows container space is very nascent but we’ve already seen customers doing exciting things with it. Microsoft just released Windows Server version 1803 and will soon release Windows Server 2019, both with improved container support. They’re also bringing Kubernetes to Windows and will even allow Linux containers to run on Windows. So, lots of things to look forward to! We hope you’ve learned a bit more about Windows containers and container monitoring in general.

Discovering, responding to, and resolving incidents is a complex endeavor. Read this narrative to learn how you can do it quickly and effectively by connecting AppDynamics, Moogsoft and xMatters to create a monitoring toolchain.

Topics:
performance ,monitoring ,apm ,containers ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}