Sysdig: O que é e como usá-lo

O Sysdig é uma ferramenta universal de visibilidade do sistema com suporte para contêineres. O que torna o Sysdig especial é que ele se conecta ao kernel da máquina e separa as informações por contêiner. Para o escopo deste tutorial, focaremos na versão de código aberto do Sysdig.

Nas próximas seções, você irá:

  • Instale o Sysdig
  • Gire uma instalação do Wordpress usando o docker-compose
  • Use o Sysdig para coletar eventos e analisá-los posteriormente
  • Use o Sysdig para analisar dados em tempo real

Pré-requisitos

  • O Docker está instalado no seu sistema. Para detalhes sobre a instalação do Docker, consulte a página Instalar o Docker.
  • O Docker Compose está instalado no seu sistema. Consulte a página Instalar o Docker Compose para obter instruções sobre como instalar o Docker Compose.
  • Os cabeçalhos do kernel estão instalados no sistema host.

Instale o Sysdig

Siga estas etapas para instalar o Sysdig dentro de um contêiner do Docker:

  1. Em uma janela do terminal, execute o seguinte comando para obter a imagem do Sysdig Docker:
docker pull sysdig / sysdig
Utilizando a tag padrão: mais recente: Puxando de sysdig / sysdig 2967486b0658: Puxar completo 78101b780c72: Puxar completo 7e78b657334d: Puxar completo 650327159ca8: Puxar completo 47ebf73ab754: Puxar completo bf51ac76a6d9: Puxar completo 0cd11104ddff6: Pull complete 6de86c8ed6e9: Pull complete 8d1825f8be4b: Pull complete Digest: sha256: bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0 Status: imagem mais recente baixada para sysdig / sysdig:

2. Execute o Sysdig em um contêiner digitando:

docker execute -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
* Configurando links / usr / src do host * Descarregando sysdig-probe, se presente * Executando dkms install for sysdig Erro! echo Seus cabeçalhos de kernel para o kernel 3.10.0-957.12.2.el7.x86_64 não podem ser encontrados em /lib/modules/3.10.0-957.12.2.el7.x86_64/build ou /lib/modules/3.10.0-957.12 .2.el7.x86_64 / source. * A execução do dkms falhou, não foi possível encontrar /var/lib/dkms/sysdig/0.26.4/build/make.log * Tentativa de carregar um sysdig-probe do sistema, se presente * Tentativa de encontrar o sysdig-probe pré-compilado para 3.10 .0-957.12.2.el7.x86_64 Encontrada configuração do kernel em /host/boot/config-3.10.0-957.12.2.el7.x86_64 * Tentando baixar o módulo pré-compilado em 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 realizado com êxito, carregando a raiz do módulo @ 7b14a23f22eb: / #

Algumas coisas a serem observadas sobre o comando acima:

  • A bandeira -i mantém STDIN aberto.
  • O parâmetro --privileged fornece acesso a todos os dispositivos no host. Também define o SELinux para permitir que os processos em execução no contêiner tenham o mesmo acesso ao host que um processo em execução no host.
  • O sinalizador -v especifica a lista de arquivos (no host) que o Sysdig pode acessar.

Gire uma instalação do Wordpress

Nesta seção, você instalará o Wordpress usando o comando docker-compose.

  1. Em uma nova janela do terminal, vá para o diretório de projetos e digite os seguintes comandos:
mkdir wordpress-sysdig && cd wordpress-sysdig

2. Crie um arquivo chamado docker-compose com o seguinte conteúdo:

versão: '3.3' serviços: db: imagem: mysql: 5.7 volumes: - db_data: / var / lib / mysql restart: sempre ambiente: MYSQL_ROOT_PASSWORD: someordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depende_on: - imagem db wordpress: últimas portas: - "8000: 80" reiniciar: sempre ambiente: WORDPRESS_DB_HOST: db: 3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: volumes do wordpress: db_data: {}

3. Execute o comando docker-compose up no modo desanexado com:

docker-compor up -d
Criando rede "wordpress-sysdig_default" com o driver padrão Criando volume "wordpress-sysdig_db_data" com driver padrão Puxando wordpress (wordpress: mais recente) ... mais recente: Puxando da biblioteca / wordpress 8ec398bc0356: Puxar completo 85cf4fc86478: Puxar completo 970dadf4ccb6: Puxar concluído 8c04561117a4: Puxar completo d6b7434b63a2: Puxar completo 83d8859e9744: Puxar completo 9c3d824d0ad5: Puxar completo 9e316fd5b3b3: Puxar completo 578b40496c37: Puxar completo 814ae7711d3c: Puxar completo 4896fed78b604: 54 Puxar completo e Puxar completo ecda5b7aad12: Puxar completo 84256a6b6b44: Puxar completo 35d4f385efb7: Puxar completo bf697c2ae701: Puxar completo d054b015f084: Puxar completo Digest: sha256: 73e8d8adf491c7a358ff94c74c8ebe35cb5f88: pressione_1 ... pronto

4. Você pode verificar o status de seus contêineres com:

docker ps

Se tudo estiver indo bem, você deverá ver algo semelhante à seguinte saída:

ID DO RECIPIENTE COMANDO DE IMAGEM NOMES DE PORTAS DE STATUS CRIADOS f390eec29f52 wordpress: latest "docker-entrypoint.s…" Cerca de um minuto atrás Para cima Cerca de um minuto 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 a844840626d8 mysql: 5.7 "docker-entrypoint. s… "Cerca de um minuto atrás Acima Cerca de um minuto 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1 7b14a23f22eb sysdig / sysdig" /docker-entrypoint.… "13 minutos atrás Acima 13 minutos sysdig

5. Agora o Wordpress está instalado e funcionando. Aponte seu navegador para http: // localhost: 8000 para iniciar o assistente de instalação:

6. Quando o assistente de instalação terminar, vamos em frente e crie um exemplo de postagem:

Coletando dados em um arquivo

Nesta seção, mostraremos como você pode usar o Sysdig para coletar eventos e analisá-los posteriormente.

  1. Para despejar todos os eventos capturados em um arquivo, vá para o contêiner Sysdig e digite o seguinte comando:
sysdig -w monitoramento-wordpress.scap

2. Em uma nova janela do terminal, use ab para fazer 10000 solicitações, com um máximo de 100 solicitações sendo executadas simultaneamente:

ab -n 1000 -c 100 http: // localhost: 8000 /? p = 7
Este é o ApacheBench, versão 2.3 <$ Revisão: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licenciado para a Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (seja paciente) Concluiu 100 pedidos Concluiu 200 pedidos Concluiu 300 pedidos Concluiu 400 pedidos Concluiu 500 pedidos Concluiu 600 pedidos Concluiu 700 pedidos Concluiu 700 pedidos Concluiu 800 pedidos Concluiu 800 pedidos Concluiu 1000 pedidos Concluiu 1000 pedidos Concluiu 1000 pedidos

Observe que a saída acima foi truncada por questões de brevidade.

3. Volte ao tour do contêiner Sysdig e pare de capturar dados digitando “CTRL + C”.

Analisando dados

Agora, se você observar o tamanho do arquivo Monitoring-wordpress.scap, perceberá que o Sysdig capturou nada menos que 80 milhões de dados:

ls -lh monitoramento-wordpress.scap
-rw-r - r--. 1 root 80M 7 de janeiro 16:28 Monitoring-wordpress.scap

Para encontrar o caminho dessa montanha de dados, você usará algo chamado cinzel.

Um cinzel é basicamente um script Lua que analisa o fluxo de eventos e executa ações úteis.

Você pode executar o seguinte comando para exibir a lista de cinzéis:

sysdig -cl
Categoria: Aplicativo --------------------- Log de solicitações de HTTP de ativação e ativação de HTTP activationptop Principais solicitações de HTTP de registro de solicitações de memcachelog memcached Categoria: Uso da CPU ---------- --------- spectrogram Visualize a latência do SO em tempo real. subsecoffset Visualize o tempo de execução do deslocamento de subsegundo. topcontainers_cpu Principais contêineres por uso de CPU topprocs_cpu Principais processos por uso de CPU Categoria: Erros ---------------- topcontainers_error Contêineres principais por número de erros topfiles_errors Arquivos principais por número de erros topprocs_errors processos principais por número de erros

Observe que a saída acima foi truncada por questões de brevidade.

Para recuperar informações detalhadas sobre um cinzel, execute o comando sysdig seguido pelo sinalizador -i e o nome do cinzel, como no exemplo a seguir:

sysdig -i httptop
Categoria: Aplicativo --------------------- activationptop Principais solicitações de HTTP Mostrar principais solicitações de HTTP por: ncalls, time ou bytes Arggs: [string] by - Mostrar as principais transações HTTP por: ncalls, time ou por tes, o padrão é ncalls

Continuando o nosso exemplo, veja como você pode usar o cinzel deiptptop para exibir as principais solicitações HTTP:

sysdig -r monitoração-wordpress.scap -c activationptop
URL do método ncalls ----------------------------------------------- --------------------------------- 2001 GET localhost: 8000 /? P = 7 14 OPÇÕES * 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/db39680b63ac47a1d989da7b742f7b382145ET7

Você pode ver as mesmas informações em um formato compatível com contêineres com o sinalizador -pcontainer:

sysdig -r monitoração-wordpress.scap -c activationptop -pcontainer
URL do método ncalls container ---------------------------------------------- ---------------------------------- 1000 wordpress-sysdig_wo GET localhost: 8000 /? P = 7 1000 host GET localhost: 8000 /? p = 7 43 wordpress-sysdig_wo OPÇÕES * 1 sysdig GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 sysdig GET localhost / v1.24 / containers17 / 06df75 / containers1 cd06093b141b / json 1 sysdig GET /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d 1 sysdig GET /v1.24/images/db396902b7

Indo Mais Fundo

O Sysdig captura informações ricas em conteúdo que permitem obter informações detalhadas sobre o funcionamento interno de seus contêineres. Suponhamos que você esteja executando alguns contêineres e queira saber qual processo consome mais CPU.

  1. Liste os contêineres que estavam ativos durante o período em que você capturou eventos:
sysdig -r monitoração-wordpress.scap -c lscontainers

2. Você pode identificar o contêiner que consumiu mais CPU com:

sysdig -r monitoração-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

3. Você pode se aprofundar ainda mais e identificar o processo mais intensivo de CPU com o cinzel topprocs_cpu:

sysdig -r monitoramento-wordpress.scap -c topprocs_cpu container.name contém wordpress_1
% De 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

Se você quiser ver mais detalhes, o ps chisel fornece uma alternativa mais detalhada:

sysdig -r monitoramento-wordpress.scap -c ps container.name = wordpress-sysdig_wordpress_1
TID PID USER VIRT RES FDLIMIT CMD 5896 5896 raiz 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.449 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 22.89M 429496729 apache2 9372 9372 www-data 235,44M 22,89M 429496729 apache2 9413 9413 www-data 233,44M 20,77M 429496729 apache2

Dicas úteis

Se você executar o Sysdig para capturar eventos como no exemplo acima (sysdig -w Monitoring-wordpress.scap), o arquivo de eventos aumentará continuamente até consumir todo o espaço disponível. Existem alguns métodos que podem ajudar a impedir que isso aconteça:

  • Especifique o número de eventos que o Sysdig deve capturar passando o sinalizador -n. Quando o Sysdig capturar o número especificado de eventos, ele sairá automaticamente:
sysdig -n 5000 -w monitoramento-wordpress.scap
  • Use o sinalizador -C para configurar o Sysdig para que ele divida a captura em arquivos menores de um tamanho especificado. O exemplo a seguir salva continuamente eventos em arquivos <10 MB:
sysdig -C 10 -w monitoramento-wordpress.scap

Isso criará um monte de arquivos com tamanho não superior a 10 MB:

ls -lh monitoramento-wordpress *
-rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:13 Monitoring-wordpress.scap0 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap1 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap2 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap3 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap4 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap5 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap6 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:14 Monitoring-wordpress.scap7 -rw-r - r--. 1 root root 6.4M 7 de janeiro 17:14 Monitoring-wordpress.scap8
  • Especifique o número máximo de arquivos que o Sysdig deve manter com o sinalizador -W. Por exemplo, você pode combinar os sinalizadores -C e -W da seguinte forma:
sysdig -C 10 -W 4 -w monitoramento-wordpress.scap

O comando acima manterá apenas os quatro últimos arquivos de captura:

ls -lh monitoramento-wordpress *
-rw-r - r--. 1 raiz raiz 7.2M 7 de janeiro 17:21 Monitoring-wordpress.scap0 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:21 Monitoring-wordpress.scap1 -rw-r - r--. 1 raiz 9,6M 7 de janeiro 17:21 Monitoring-wordpress.scap2 -rw-r - r--. 1 raiz raiz 9.6M 7 de janeiro 17:21 Monitoring-wordpress.scap3 raiz @ cd06093b141b: / # sysdig -C 10 -W 4 -w Monitoring-wordpress.scap

Monitoramento em tempo real

Com o Sysdig, você também pode analisar dados em tempo real. À primeira vista, isso pode parecer uma tarefa assustadora, porque, por padrão, todos os eventos são impressos continuamente no console. Felizmente, os formões estão aqui para ajudar.

Vamos dar um exemplo.

Analise seus processos em uma base por contêiner

  1. Execute o seguinte comando para listar seus contêineres:
docker ps
ID DE RECIPIENTE COMANDO DE IMAGEM COMANDOS DE PORTOS DE STATUS CRIADOS 5b253e74e8e7 sysdig / sysdig "/docker-entrypoint.…" há 9 minutos Acima de 9 minutos sysdig 06def7875617 wordpress: mais recente "docker-entrypoint.s…" 3 horas atrás Até 3 horas 0.0.0.0:8000 -> 80 / tcp wordpress-sysdig_wordpress_1 6bd8418eb03f mysql: 5,7 "docker-entrypoint.s…" 3 horas atrás Até 3 horas 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1

2. Você pode analisar os processos em execução no contêiner do WordPress com:

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_wordpress_1

3. Da mesma forma, você pode analisar os processos em execução no contêiner MySQL:

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_db_1

Observe que, não muito diferente deste exemplo, o Sysdig pode monitorar o tráfego de rede, o uso do disco e assim por diante.

Neste tutorial, você examinou os fundamentos do uso do Sysdig para obter uma compreensão clara da atividade gerada pelos seus contêineres. Os exemplos nesta postagem do blog ajudaram você a começar e, em futuros tutoriais, mostraremos como usar o Csysdig e o Sysdig Inspect.