Difficulty: Beginner
Estimated Time: 10 minutes

Sysdig is an open source tool for deep system visibility that comes with container native support.

Think of all the system health and performance monitoring tools you used for troubleshooting but working together and container-aware:

  • strace
  • tcpdump
  • htop
  • iftop
  • lsof

and way more.

This means that you can gain visibility inside the containers, and filter or aggregate metrics using container names/ids or your orchestration tool resources (Kubernetes pods, deployments, etc or Mesos tasks and Marathon apps and groups).

In this scenario, we will introduce the concept of sysdig's command line interface, how to create a system capture with sysdig, how to interpret the output of a sysdig capture, and basic sysdig filter syntax.

We will use sysdig to answer the following questions about an nginx process:

  • What system calls does nginx use to serve a request?
  • What files does nginx open to server a request?

Happy digging!

Congratulations! You now know how to create a capture with Sysdig, and filter through the capture using the Sysdig filter language.

Remember sysdig -l will show you all filter fields, and sysdig -L will show you events and their arguments captured.

Here's a list of the more popular fields we covered in this scenario:

  • container.id: the container id.
  • container.name: the container name.
  • container.image: the container image name (e.g. sysdig/sysdig:latest)
  • fd.type: type of FD. Can be 'file', 'directory', 'ipv4', 'ipv6', 'unix', 'pipe', 'event', 'signalfd', 'eventpoll', 'inotify' or 'signalfd'.
  • fd.name: FD full name. If the fd is a file, this field contains the full path. If the FD is a socket, this field contain the connection tuple.
  • fd.directory: If the fd is a file, the directory that contains it.
  • fd.filename: If the fd is a file, the filename without the path.
  • fd.ip: Matches the ip address (client or server) of the fd.
  • fd.port: (FILTER ONLY) matches the port (either client or server) of the fd.

You can download Sysdig or contribute to the project over on our GitHub repo.

We hope you continue on in our series of scenarios and appreciate any feedback via Twitter (@sysdig).

Don’t stop now! The next scenario will only take about 10 minutes to complete.

Example 0 - Exploring an HTTP Request

Step 1 of 5

Step 1 - Creating a Capture of Nginx

In this preconfigured environment we have a nginx server running inside a Docker container. You can run docker ps to verify the nginx server is up and listening.

Starting a capture with sysdig is easy. Simply run the sysdig command and specify the -w <filename.scap> option to write the to the specified file.

sysdig -w captures/nginx.scap &

Now that we have a capture running, we can create traffic to our nginx server to better understand how nginx serves a HTTP request.

curl localhost:8080

Curl will print the nginx "welcome" page and exit. We can now kill our capture. Since we put sysdig in background by using the trailing &, we can kill our capture like so.

kill %1

We can now begin to dig into our capture to understand it's contents.