We at Sysdig were happy to see IBM’s launch of their new container service. A very stable and well managed cluster environment for your apps and containers powered by IBM is a big step forward for both Kubernetes and the Cloud. And, in our humble opinion, pairing Bluemix up with a cornerstone container intelligence tool like Sysdig is a match made in Devops heaven. This blog was easy to write as it took 3 steps to get up and running with Bluemix’s excellent deployment and management cli tools along with the Sysdig Monitor daemonset deployment.
- Deploy your Cluster. Great tutorial here.
- Deploy Sysdig: Sign up for a free trial on our website, then deploy our daemonset.
- Prosper!
Containers radically change monitoring

- Simple – typically an individual process
- Small – 1/10th of the size of a VM means they’re portable
- Isolated – They have few dependencies
- Dynamic – Rapid startup times means they can be scaled, killed, and moved quickly
Prerequisites
To gain access to your cluster, download and install a few CLI tools and the IBM Bluemix Container Service plug-in. Bluemix CLI Kubernetes CLI- Deploy your IBM Bluemix Container Service via the excellent UI Bluemix provides

- We install the Bluemix cli plugin. In this example i am using the windows CLI. Install instructions here.

- We access our cluster, here are directions on how to connect:


Sysdig Installation with DaemonSet (Look Ma no hands!)
Before deploying Sysdig, it’s worth a moment to describe our instrumentation approach because it’s so different from other container monitoring approaches out there. We have developed a transparent, per-host instrumentation model that doesn’t require developers to modify code, doesn’t involve adding a container per pod, and certainly doesn’t involve adding a process to every single container! This transparent instrumentation – we call it ContainerVision – captures all application, container, statsd, and host metrics with a single instrumentation point, leveraging the tracepoints facility in the kernel, and sends it to a container per host for processing & transfer. This eliminates the need to turn everything into a statsd metric, which is something we’ve seen many people resort to. Unlike per-pod sidecar models, per-host agents drastically reduce resource consumption of monitoring agents, and require no modification to application code. It does, however, require a privileged container and a kernel module.
Sysdig -> Settings -> User Profile -> Access Key.
):

kubectl create -f ‘sysdig.yaml’
Now time to Sysdig!
Before we hop into the metrics – just a note – everything you see below is out of the box. No special configurations, no modification to your application code, no configuring plug-ins. While Sysdig can give you even more than what’s below, you’ll see you start with quite a lot! We now have an overview of my agent host(s) running my Bluemix Cluster. In less than 20 minutes I have full visibility of my cluster!


Here’s a Kubernetes overview of my cluster
Notice Sysdig is grabbing the metatag data directly from Kubernetes API without any type of direct configuration. I’m seeing our request count per service, Top Services, Top namespaces and host capacity. This helps me grow the environment naturally and improved capacity planning based on REAL metrics.

What about application metrics? How do I get to those?
Here’s the same redis example from the guestbook, we have a service level view, not just single hosts, and many many more. Similarly, Sysdig can visualize statsd, JMX, and prometheus custom metrics… without even changing the collection endpoint you already have in place. (Yes, that sounds crazy. Read how it works here.)
All of that in 3 steps!
IBM Container Service is a great place for developers hosting applications and running production applications. Sysdig makes it even better with true visibility and intelligence. We even have a 4 part tutorial on monitoring kubernetes with Sysdig here.