["Black No Other"]
["Black No Other"]
Black no other
["Black No Other"]
We're here at DockerCon 2017 in Austin, Texas, and we're at the Cystic booth.
Can you tell us a little bit about the company and what you're showing here at DockerCon?
Yeah, absolutely.
So, Cystic is the container intelligence company.
You have all these folks here at DockerCon who are thinking about moving their apps
into containers from dev all the way to prod, and Docker is great for dev portability, but
what about production visibility?
That's what Cystic provides for you.
We give you deep visibility into your entire stack in a way that's container native, instrumented
the way containers should be instrumented.
We bring that all together with your data from your orchestrator, Docker Swarm, Kubernetes,
Mesosphere, and give you a beautiful way to look at that information and ensure that your
production apps are performing properly.
Can we get a demo of the product?
Yeah, absolutely.
Let's go take a look.
So, what are you going to show us?
All right.
I'm going to show you Cystic Monitor.
Cystic Monitor is our monitoring technology, not surprisingly.
You can run this as a cloud service where we manage the backend for you, or you can
use it as on-premise software.
We see a lot of larger companies, financial companies, governments want to use the on-premise
software versus cloud, whereas most of our technology customers, small SaaS companies
and so on, want to use our cloud service.
Now, if you look over here at the demo, you'll see that we're running a small demo environment.
This is actually running in AWS.
You have multiple hosts that are talking to each other.
This is a dynamically created topology map, so you don't have to do any work to get it.
Here's what's cool.
We call this Google Maps for your infrastructure.
I can zoom in on this topology map and show you the individual containers running on this
host.
Now, here's the dirty little secret.
This map is actually useless for troubleshooting a Kubernetes-based environment.
The reason is Kubernetes is deciding which container should run where, and is moving
them dynamically.
So, instead, let's take a look at a Kubernetes-oriented map, so I'm going to switch this to a service-oriented
map.
Now, instead of hosts, you're looking at Kubernetes namespaces.
You're looking at, for example, the prod namespace.
When I zoom in here, you're no longer looking at these individual random containers.
You're actually looking at the Kubernetes services, what we've defined.
You can see we've got two clients talking to two main front-end applications, each talking
to a range of backends.
In this particular view, we're looking at the response time of each of these services.
So, out of view, we know, what are my services, where are they running, and how are they performing?
Now, this is really nice for an overview of your system.
Let's dig in with our Explorer-based view.
Explorer is like Htop for your entire distributed environment.
Here you see a range of hosts with a bunch of what I would consider pretty standard networking
data, kind of file, a network, memory, so on and so forth.
You can see here we're organized by host and then container ID, and that means if I drill
down here, I'll see all my containers, and if I click on any one of these containers,
I can get a deep dive into what's going on in this container.
I'm going to show you more in this drill-down view in a moment, but first what I'd like
to do is kill this and show you something really interesting, which is let's reorganize
all of my infrastructure based on my Kubernetes metadata.
So here I'm going to reorganize based on Kubernetes namespace, deployment, pod, and
then container.
When I click apply, you're going to see here, now we've got our prod namespace, and if I
drill down here, these are my individual microservices running, and I could drill down into any one
of these microservices to get a deeper view.
For any one of these services or any layer in here, I can click on this row and get a
drill-down view.
This drill-down view works against the aggregate of all the containers that are related to
that particular view.
So now I'm looking at an overview of this host, but instead what I'd like to do is go
to a service-oriented view and get a service overview.
This is honestly, I think, the most important metric that we track in Sysdig, which is the
response time of your service compared to resource utilization.
So very quickly you can get an assessment of how's my service performing and how many
resources is it using to get there, but let's drill in deeper.
In order to drill in deeper, I'm going to choose a different service here.
I'm going to go with our HTTP service.
That's WordPress in this example.
Now it wouldn't matter whether this is one container or a thousand containers, we're
going to get an aggregate view here, and because this is HTTP, I'm going to choose our HTTP
pre-built overview.
And here you're going to start to see really powerful information like error count, average
and max request time, and this is where things get really interesting, top URLs by number
of requests and slowest URLs.
So this means at a glance, without any special code instrumentation, you're going to see
what are the most popular endpoints for your service, and what are the slowest performing
endpoints for your service.
My quick math is I do a comparison, and if I have an endpoint on both of those charts,
I've got a problem that I need to go troubleshoot.
The next thing that people really want to do in our system is they want to understand
how their databases are performing.
So let's switch over to a MySQL database, and again we're going to get an aggregate
service level view, you could of course go down to a container, but it's more interesting
to look at your service as a whole.
We could look at any of these metrics, but instead I would like to look at our pre-built
dashboard.
And the thing I want to show you here is of course we'll give you the powerful metrics
you need like requests, errors, average and max request time, but we'll also give you
top queries by number of requests, top tables, slowest queries and slowest tables.
This is all without any specialized instrumentation of your app, and without requiring you to
run MySQL slope query logging in production, which is incredibly resource intensive.
Now we can kind of take a full stack, look at your environment.
Any metric that you've seen here, you can set an alert off of, and you can do that alert
on a container, or you could do it on an entire service, and those alerts will be adaptive.
So as your service grows and shrinks based on what Docker Swarm or Kubernetes needs to
do, our alerts will adapt as well.
Let's get into one really powerful feature that no one else has.
As I mentioned in the beginning, the way we instrument systems is special, and we do it
by collecting system calls.
So when you trigger an alert, we can actually trigger a capture of every single system call
that's firing on your machine at the time there was a problem.
This means you have a deep record of what happened when there was a problem.
So if Kubernetes or Swarm comes along, kills off a container or moves it, you can still
troubleshoot that environment.
We in fact can help you troubleshoot your containers after they're long gone.
So in one quick demo, we got from this high level dynamic topology view, which is automatically
created for you, down to slicing and dicing your infrastructure to alerts that capture
data at the system call level, and this is what Sysdig enables you to do.
In a container native way, we can help you monitor, visualize, and troubleshoot your
infrastructure, solve problems faster, and ensure your containerized infrastructure
is running properly in production.
Awesome.
Well, thanks for taking the time to speak with VMBlog and give us a great demo.
It looks like you have swarms of people at your booth.
Yeah, right on.
And thanks everybody for at least watching this video.
If you weren't able to join here in person, we actually just do free trials on our website.
So if people want to just come to the website, sysdig.com, there's a big purple button.
You can't miss it.
Just click it, and you're off and running to the races with a trial, probably in five
to ten minutes.
Well, enjoy the rest of your show.
Thank you very much.
