Sysdig is a universal system visibility tool with support for containers. What makes Sysdig special, is that it hooks itself into the machine’s kernel and segregates the information on a per-container basis.
For the scope of this tutorial, we will focus on the open-source version of Sysdig.
In the next sections, you will:
- Install Sysdig
- Spin up a WordPress installation using
docker-compose - Use Sysdig to collect events and analyze them at a later time
- Use Sysdig to analyze data in real-time
Prerequisites
- Docker is installed on your system. For details about installing Docker, refer to the Install Docker page.
- Docker Compose is installed on your system. Refer to the Install Docker Compose page for instructions about how to install Docker Compose.
- The kernel headers are installed on the host system.
Install Sysdig
Follow these steps to install Sysdig inside a Docker container:
- In a terminal window, execute the following command to pull the Sysdig Docker image:
docker pull sysdig/sysdig
Using default tag: latest latest: Pulling from sysdig/sysdig 2967486b0658: Pull complete 78101b780c72: Pull complete 7e78b657334d: Pull complete 650327159ca8: Pull complete 47ebf73ab754: Pull complete bf51ac76a6d9: Pull complete 0cd11104dbf6: Pull complete e6dcf17d00d8: Pull complete 230d60083576: Pull complete fd5ea9faf384: Pull complete 6de86c8ed6e9: Pull complete 8d1825f8be4b: Pull complete Digest: sha256:bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0 Status: Downloaded newer image for sysdig/sysdig:latest
- Run Sysdig in a container by entering:
docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro sysdig/sysdig
* Setting up /usr/src links from host * Unloading sysdig-probe, if present * Running dkms install for sysdig Error! echo Your kernel headers for kernel 3.10.0-957.12.2.el7.x86_64 cannot be found at /lib/modules/3.10.0-957.12.2.el7.x86_64/build or /lib/modules/3.10.0-957.12.2.el7.x86_64/source. * Running dkms build failed, couldn't find /var/lib/dkms/sysdig/0.26.4/build/make.log * Trying to load a system sysdig-probe, if present * Trying to find precompiled sysdig-probe for 3.10.0-957.12.2.el7.x86_64 Found kernel config at /host/boot/config-3.10.0-957.12.2.el7.x86_64 * Trying to download precompiled module from https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/sysdig-probe-0.26.4-x86_64-3.10.0-957.12.2.el7.x86_64-82e2ae1fb159132636f7b50a762f20ef.ko Download succeeded, loading module root@7b14a23f22eb:/#
A few things to note about the above command:
- The
-iflag keeps STDIN open. - The
--privilegedparameter provides access to all devices on the host. Also it sets SELinux to allow the processes running inside of the container the same access to the host as a process running on the host. - The
-vflag specifies the list of files (on the host) that Sysdig can access.
Spin Up a WordPress Installation
In this section, you will install WordPress using the docker-compose command.
- In a new terminal window, move into your projects directory and type the following commands:
mkdir wordpress-sysdig && cd wordpress-sysdig
- Create a file called
docker-composewith the following content:
version: '3.3'
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
db_data: {}
- Run the
docker-compose upcommand in detached mode with:
docker-compose up -d
Creating network "wordpress-sysdig_default" with the default driver Creating volume "wordpress-sysdig_db_data" with default driver Pulling wordpress (wordpress:latest)... latest: Pulling from library/wordpress 8ec398bc0356: Pull complete 85cf4fc86478: Pull complete 970dadf4ccb6: Pull complete 8c04561117a4: Pull complete d6b7434b63a2: Pull complete 83d8859e9744: Pull complete 9c3d824d0ad5: Pull complete 9e316fd5b3b3: Pull complete 578b40496c37: Pull complete 814ae7711d3c: Pull complete 4896fed78b6b: Pull complete e74d71e9611d: Pull complete 46017765526c: Pull complete 280386098458: Pull complete f32eb0d8c540: Pull complete 5c47b9ea747a: Pull complete ecda5b7aad12: Pull complete 84256a6b6b44: Pull complete 35d4f385efb7: Pull complete bf697c2ae701: Pull complete d054b015f084: Pull complete Digest: sha256:73e8d8adf491c7a358ff94c74c8ebe35cb5f8857e249eb8ce6062b8576a01465 Status: Downloaded newer image for wordpress:latest Creating wordpress-sysdig_db_1 ... done Creating wordpress-sysdig_wordpress_1 ... done
- You can verify the status of your containers with:
docker ps
If all is going well, you should see something similar to the following output:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f390eec29f52 wordpress:latest "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 a844840626d8 mysql:5.7 "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp, 33060/tcp wordpress-sysdig_db_1 7b14a23f22eb sysdig/sysdig "/docker-entrypoint.…" 13 minutes ago Up 13 minutes sysdig
- Now WordPress is up and running. Point your browser to
http://localhost:8000
to start the installation wizard:
- Once the installation wizard is finished, let us go ahead and create a sample post:
Collecting Data to a File
In this section, we’ll show how you can use Sysdig to collect events and analyze them at a later time.
- To dump all captured events to a file, move to the Sysdig container, and enter the following command:
sysdig -w monitoring-wordpress.scap
- In a new terminal window, use
abto make 10000 requests with a maximum of 100 requests running concurrently:
ab -n 1000 -c 100 http://localhost:8000/?p=7
This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests
Note that the above output was truncated for brevity.
- Move back to tour Sysdig container and stop capturing data by entering “CTRL+C”.
Analyzing data
Now, if you look at the size of the monitoring-wordpress.scap file, you’ll notice that Sysdig captured no less than 80M of data:
ls -lh monitoring-wordpress.scap
-rw-r--r--. 1 root root 80M Jan 7 16:28 monitoring-wordpress.scap
To find your way through this mountain of data, you’ll use something called a chisel.
A chisel is basically a Lua script that analyzes the event stream and performs useful actions.
You can run the following command to display the list of chisels:
sysdig -cl
Category: Application
---------------------
httplog HTTP requests log
httptop Top HTTP requests
memcachelog memcached requests log
Category: CPU Usage
-------------------
spectrogram Visualize OS latency in real time.
subsecoffset Visualize subsecond offset execution time.
topcontainers_cpu
Top containers by CPU usage
topprocs_cpu Top processes by CPU usage
Category: Errors
----------------
topcontainers_error
Top containers by number of errors
topfiles_errors Top files by number of errors
topprocs_errors top processes by number of errors
Note that the above output was truncated for brevity.
To retrieve detailed information about a chisel, run the sysdig command followed by the -i flag and the name of the chisel, as in the following example:
sysdig -i httptop
Category: Application
---------------------
httptop Top HTTP requests
Show top HTTP requests by: ncalls, time or bytes
Args:
[string] by - Show top HTTP transactions by: ncalls, time or by
tes, default is ncalls
Continuing our example, here’s how you can use the httptop chisel to display the top HTTP requests:
sysdig -r monitoring-wordpress.scap -c httptop
ncalls method url -------------------------------------------------------------------------------- 2001 GET localhost:8000/?p=7 14 OPTIONS * 2 GET localhost:8000/favicon.ico 1 GET /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2 1 GET localhost/v1.24/containers/6bd8418eb03f/json 1 GET localhost/v1.24/containers/06def7875617/json 1 GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 GET /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901 1 GET localhost:8000/
You can see the same information in a container-friendly format with the -pcontainer flag:
sysdig -r monitoring-wordpress.scap -c httptop -pcontainer
ncalls container method url -------------------------------------------------------------------------------- 1000 wordpress-sysdig_wo GET localhost:8000/?p=7 1000 host GET localhost:8000/?p=7 43 wordpress-sysdig_wo OPTIONS * 1 sysdig GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 sysdig GET localhost/v1.24/containers/06def7875617/json 1 sysdig GET localhost/v1.24/containers/cd06093b141b/json 1 sysdig GET /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d 1 sysdig GET /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901
Digging Deeper
Sysdig captures content-rich information that lets you get detailed insights into the inner-workings of your containers. Let’s suppose you’re running a few containers and want to know which process consumes the most CPU.
- List the containers that were active during the period in which you captured events:
sysdig -r monitoring-wordpress.scap -c lscontainers
- You can identify the container that consumed the most CPU with:
sysdig -r monitoring-wordpress.scap -c topcontainers_cpu
CPU% container.name -------------------------------------------------------------------------------- 5.37% wordpress-sysdig_wordpress_1 1.35% wordpress-sysdig_db_1 0.84% host 0.51% sysdig
- You can dig even deeper and identify the most CPU intensive process with the
topprocs_cpuchisel:
sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name contains wordpress_1
CPU% Process PID -------------------------------------------------------------------------------- 0.12% apache2 8383 0.11% apache2 9413 0.11% apache2 9300 0.11% apache2 9242 0.11% apache2 8897 0.11% apache2 8422 0.10% apache2 9372 0.10% apache2 9241 0.10% apache2 8424 0.09% apache2 9429
If you want to see more details, the ps chisel provides a more verbose alternative:
sysdig -r monitoring-wordpress.scap -c ps container.name=wordpress-sysdig_wordpress_1
TID PID USER VIRT RES FDLIMIT CMD 5896 5896 root 232.82M 22.32M 429496729 apache2 8383 8383 www-data 307.44M 25.46M 429496729 apache2 8422 8422 www-data 235.44M 22.90M 429496729 apache2 8424 8424 www-data 307.44M 25.46M 429496729 apache2 8897 8897 www-data 235.44M 22.89M 429496729 apache2 9154 9154 www-data 235.44M 22.91M 429496729 apache2 9241 9241 www-data 307.44M 25.66M 429496729 apache2 9242 9242 www-data 307.44M 25.67M 429496729 apache2 9300 9300 www-data 235.44M 22.89M 429496729 apache2 9372 9372 www-data 235.44M 22.89M 429496729 apache2 9413 9413 www-data 233.44M 20.77M 429496729 apache2
Useful Tips
If you run Sysdig to capture events as in the above example (sysdig -w monitoring-wordpress.scap), the event file will grow continuously until it consumes all the available space. There are a few methods that can help prevent this from happening:
- Specify the number of events Sysdig should capture by passing it the
-nflag. Once Sysdig captures the specified number of events, it’ll automatically exit:
sysdig -n 5000 -w monitoring-wordpress.scap
- Use the
-Cflag to configure Sysdig so that it breaks the capture into smaller files of a specified size. The following example continuously saves events to files < 10MB:
sysdig -C 10 -w monitoring-wordpress.scap
This will create a bunch of files no larger than 10 MB:
ls -lh monitoring-wordpress*
-rw-r--r--. 1 root root 9.6M Jan 7 17:13 monitoring-wordpress.scap0 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap1 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap2 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap3 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap4 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap5 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap6 -rw-r--r--. 1 root root 9.6M Jan 7 17:14 monitoring-wordpress.scap7 -rw-r--r--. 1 root root 6.4M Jan 7 17:14 monitoring-wordpress.scap8
- Specify the maximum number of files Sysdig should keep with the
-Wflag. For example, you can combine the-Cand-Wflags like so:
sysdig -C 10 -W 4 -w monitoring-wordpress.scap
The above command will only keep the last four capture files:
ls -lh monitoring-wordpress*
-rw-r--r--. 1 root root 7.2M Jan 7 17:21 monitoring-wordpress.scap0 -rw-r--r--. 1 root root 9.6M Jan 7 17:21 monitoring-wordpress.scap1 -rw-r--r--. 1 root root 9.6M Jan 7 17:21 monitoring-wordpress.scap2 -rw-r--r--. 1 root root 9.6M Jan 7 17:21 monitoring-wordpress.scap3 root@cd06093b141b:/# sysdig -C 10 -W 4 -w monitoring-wordpress.scap
Real-Time Monitoring
With Sysdig, you can also analyze data real-time. At first glance, this can seem like a daunting task because, by default, all events are continuously printed out to the console. Fortunately, chisels are here to help.
Let’s take an example.
Analyze Processes on a Per Container Basis
- Run the following command to list your containers:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5b253e74e8e7 sysdig/sysdig "/docker-entrypoint.…" 9 minutes ago Up 9 minutes sysdig 06def7875617 wordpress:latest "docker-entrypoint.s…" 3 hours ago Up 3 hours 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 6bd8418eb03f mysql:5.7 "docker-entrypoint.s…" 3 hours ago Up 3 hours 3306/tcp, 33060/tcp wordpress-sysdig_db_1
- You can analyze the processes running in the WordPress container with:
sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_wordpress_1
- Similarly, you can analyze the processes running in the MySQL container:
sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_db_1
Note that, not much different from this example, Sysdig can monitor network traffic, disk usage, and so on.
In this tutorial, you have gone over the fundamentals of using Sysdig to get a clear understanding of the activity generated by your containers. The examples in this blog post helped you get started and, in future tutorials, we’ll show you how to use Csysdig and Sysdig Inspect.
