Sysdig: cos'è e come si usa

Sysdig è uno strumento di visibilità del sistema universale con supporto per contenitori. Ciò che rende speciale Sysdig è che si aggancia al kernel della macchina e segrega le informazioni in base al contenitore. Per lo scopo di questo tutorial, ci concentreremo sulla versione open source di Sysdig.

Nelle prossime sezioni dovrai:

  • Installa Sysdig
  • Fai girare un'installazione di Wordpress usando docker-compose
  • Usa Sysdig per raccogliere eventi e analizzarli in un secondo momento
  • Usa Sysdig per analizzare i dati in tempo reale

Prerequisiti

  • Docker è installato sul tuo sistema. Per dettagli sull'installazione di Docker, consultare la pagina Installa Docker.
  • Docker Compose è installato sul tuo sistema. Consultare la pagina Installa Docker Compose per istruzioni su come installare Docker Compose.
  • Le intestazioni del kernel sono installate sul sistema host.

Installa Sysdig

Seguire questi passaggi per installare Sysdig all'interno di un contenitore Docker:

  1. In una finestra del terminale, eseguire il comando seguente per estrarre l'immagine Docker Sysdig:
docker pull sysdig / sysdig
Utilizzo del tag predefinito: ultimo più recente: estrazione da sysdig / sysdig 2967486b0658: estrazione completa 78101b780c72: estrazione completa 7e78b657334d: estrazione completa 650327159ca8: estrazione completa 47ebf73ab754: estrazione completa bf51ac76a6d9d6d6d6d6d6d6d6d6d6d6d6d6d6dc Pull complete 6de86c8ed6e9: Pull complete 8d1825f8be4b: Pull complete Digest: sha256: bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0 Stato: immagine più recente scaricata per sysdig / sysdig

2. Esegui Sysdig in un contenitore inserendo:

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
* Impostazione dei collegamenti / usr / src dall'host * Scaricamento di sysdig-probe, se presente * Esecuzione di dkms install per sysdig Errore! echo Le intestazioni del kernel per il kernel 3.10.0-957.12.2.el7.x86_64 non sono disponibili in /lib/modules/3.10.0-957.12.2.el7.x86_64/build o /lib/modules/3.10.0-957.12 .2.el7.x86_64 / fonte. * Esecuzione della compilazione di dkms non riuscita, impossibile trovare /var/lib/dkms/sysdig/0.26.4/build/make.log * Tentativo di caricare un sysdig-probe di sistema, se presente * Tentativo di trovare sysdig-probe precompilato per 3.10 .0-957.12.2.el7.x86_64 Trovata la configurazione del kernel in /host/boot/config-3.10.0-957.12.2.el7.x86_64 * Tentativo di scaricare il modulo precompilato da 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 riuscito, caricamento modulo root @ 7b14a23f22eb: / #

Alcune cose da notare sul comando sopra:

  • Il flag -i mantiene STDIN aperto.
  • Il parametro --privileged fornisce l'accesso a tutti i dispositivi sull'host. Inoltre imposta SELinux per consentire ai processi in esecuzione all'interno del contenitore lo stesso accesso all'host di un processo in esecuzione sull'host.
  • Il flag -v specifica l'elenco dei file (sull'host) a cui Sysdig può accedere.

Spin Up un'installazione di Wordpress

In questa sezione, installerai Wordpress usando il comando docker-compose.

  1. In una nuova finestra del terminale, spostati nella directory dei tuoi progetti e digita i seguenti comandi:
mkdir wordpress-sysdig && cd wordpress-sysdig

2. Creare un file chiamato docker-compose con il seguente contenuto:

versione: '3.3' servizi: db: immagine: mysql: 5.7 volumi: - db_data: / var / lib / mysql restart: sempre ambiente: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: dipende_on: - db wordpress: ultime porte: - riavvio "8000: 80": sempre ambiente: WORDPRESS_DB_HOST: db: 3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: volumi wordpress: db_data: {}

3. Esegui il comando docker-compose up in modalità staccata con:

docker-compose up -d
Creazione della rete "wordpress-sysdig_default" con il driver predefinito Creazione del volume "wordpress-sysdig_db_data" con il driver predefinito Pulling wordpress (wordpress: latest) ... latest: pulling from library / wordpress 8ec398bc0356: pull complete 85cf4fc86478: pull complete 970dadf4ccb6: pull complete 8c04561117a4: estrazione completa d6b7434b63a2: estrazione completa 83d8859e9744: estrazione completa 9c3d824d0ad5: estrazione completa 9e316fd5b3b3: estrazione completa 578b40496c37: estrazione completa 814ae7711d3c: estrazione completa 4896fed78b671 Pull completo ecda5b7aad12: pull completo 84256a6b6b44: pull completo 35d4f385efb7: pull completo bf697c2ae701: pull completo d054b015f084: pull completo digest: sha256: 73e8digdbdbd85d_bd85e premi_1 ... fatto

4. Puoi verificare lo stato dei tuoi contenitori con:

docker ps

Se tutto sta andando bene, dovresti vedere qualcosa di simile al seguente output:

ID CONTENITORE COMANDO IMMAGINE STATO CREATO PORTI NOMI f390eec29f52 wordpress: ultime "docker-entrypoint.s ..." Circa un minuto fa Fino Circa un minuto 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 a844840626d8 mysql: 5.7 "docker-entrypoint. s ... "Circa un minuto fa Su Circa un minuto 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1 7b14a23f22eb sysdig / sysdig" /docker-entrypoint.… "13 minuti fa Su 13 minuti sysdig

5. Ora Wordpress è attivo e funzionante. Puntare il browser su http: // localhost: 8000 per avviare la procedura guidata di installazione:

6. Al termine della procedura guidata di installazione, procediamo e creiamo un post di esempio:

Raccolta di dati in un file

In questa sezione, mostreremo come è possibile utilizzare Sysdig per raccogliere eventi e analizzarli in un secondo momento.

  1. Per eseguire il dump di tutti gli eventi acquisiti in un file, passare al contenitore Sysdig e immettere il comando seguente:
sysdig -w monitoring-wordpress.scap

2. In una nuova finestra del terminale, utilizzare ab per effettuare 10000 richieste con un massimo di 100 richieste in esecuzione contemporaneamente:

ab -n 1000 -c 100 http: // localhost: 8000 /? p = 7
Questo è ApacheBench, versione 2.3 <$ Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Concesso in licenza a Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (pazienza) completate 100 richieste completate 200 richieste completate 300 richieste completate 400 richieste completate 500 richieste completate 600 richieste completate 700 richieste completate 800 richieste completate 900 richieste completate 1000 richieste completate 1000 richieste

Si noti che l'output sopra è stato troncato per brevità.

3. Tornare al tour del contenitore Sysdig e interrompere l'acquisizione dei dati immettendo "CTRL + C".

Analisi dei dati

Ora, se osservi le dimensioni del file monitoring-wordpress.scap, noterai che Sysdig ha acquisito non meno di 80 milioni di dati:

ls -lh monitoring-wordpress.scap
-rw-r - r--. 1 root root 80M 7 gennaio 16:28 monitoring-wordpress.scap

Per trovare la strada attraverso questa montagna di dati, utilizzerai qualcosa chiamato scalpello.

Uno scalpello è fondamentalmente uno script Lua che analizza il flusso di eventi ed esegue azioni utili.

È possibile eseguire il comando seguente per visualizzare l'elenco di scalpelli:

sysdig -cl
Categoria: Applicazione --------------------- httplog Registro richieste HTTP httptop Principali richieste HTTP memcachelog registro richieste memcached Categoria: Utilizzo CPU ---------- --------- spettrogramma Visualizza la latenza del sistema operativo in tempo reale. subsecoffset Visualizza il tempo di esecuzione dell'offset del secondo. topcontainers_cpu Contenitori principali per utilizzo della CPU topprocs_cpu Principali processi per utilizzo della CPU Categoria: Errori ---------------- topcontainers_error Contenitori principali per numero di errori topfiles_errors File principali per numero di errori topprocs_errors processi principali per numero di errori

Si noti che l'output sopra è stato troncato per brevità.

Per recuperare informazioni dettagliate su uno scalpello, eseguire il comando sysdig seguito dal flag -i e dal nome dello scalpello, come nell'esempio seguente:

sysdig -i httptop
Categoria: Applicazione --------------------- httptop Principali richieste HTTP Mostra le principali richieste HTTP di: ncalls, time o bytes Args: [string] by - Mostra le principali transazioni HTTP di: ncalls, time o by tes, il default è ncalls

Continuando il nostro esempio, ecco come è possibile utilizzare lo scalpello httptop per visualizzare le principali richieste HTTP:

sysdig -r monitoring-wordpress.scap -c httptop
url del metodo ncalls ----------------------------------------------- --------------------------------- 2001 OTTIENI localhost: 8000 /? P = 7 14 OPZIONI * 2 OTTIENI localhost: 8000 / favicon.ico 1 OTTIENI /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2 1 OTTIENI localhost / v1.24 / containers / 6bd8418eb03f / json 1 OTTIENI localhost / v1.24 / containers / 06def7875617 / json 1 GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 GET /v1.24/images/db39680b63ac47a1d989da7b742f7857d7d

Puoi visualizzare le stesse informazioni in un formato adatto al contenitore con il flag -pcontainer:

sysdig -r monitoring-wordpress.scap -c httptop -pcontainer
url metodo contenitore ncalls ---------------------------------------------- ---------------------------------- 1000 wordpress-sysdig_wo OTTIENI localhost: 8000 /? P = 7 1000 host OTTIENI localhost: 8000 /? p = 7 43 wordpress-sysdig_wo OPTIONS * 1 sysdig OTTIENI /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 sysdig GET localhost / v1.24 / containers / 06d75 / js / v1.24 cd06093b141b / json 1 sysdig GET /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d 1 sysdig GET /v1.24/images/db39680b637472852dcdc

Scavando più a fondo

Sysdig acquisisce informazioni ricche di contenuti che ti consentono di ottenere informazioni dettagliate sul funzionamento interno dei tuoi contenitori. Supponiamo che tu stia eseguendo alcuni container e desideri sapere quale processo consuma più CPU.

  1. Elencare i contenitori attivi durante il periodo in cui sono stati acquisiti gli eventi:
sysdig -r monitoring-wordpress.scap -c lscontainers

2. È possibile identificare il contenitore che ha consumato più CPU con:

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

3. Puoi scavare ancora più a fondo e identificare il processo più intensivo della CPU con lo scalpello topprocs_cpu:

sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name contiene 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

Se vuoi vedere maggiori dettagli, lo scalpello ps offre un'alternativa più dettagliata:

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-dati 235.44M 22.90M 429496729 apache2 8424649 42 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 93 93 49 429499 22.89M 429496729 apache2 9372 9372 www-data 235.44M 22.89M 429496729 apache2 9413 9413 www-data 233.44M 20.77M 429496729 apache2

Consigli utili

Se si esegue Sysdig per acquisire eventi come nell'esempio sopra (sysdig -w monitoring-wordpress.scap), il file degli eventi crescerà continuamente fino a consumare tutto lo spazio disponibile. Esistono alcuni metodi che possono aiutare a prevenire che ciò accada:

  • Specifica il numero di eventi che Sysdig dovrebbe acquisire passandogli il flag -n. Una volta che Sysdig acquisisce il numero specificato di eventi, uscirà automaticamente:
sysdig -n 5000 -w monitoring-wordpress.scap
  • Utilizzare il flag -C per configurare Sysdig in modo da interrompere l'acquisizione in file più piccoli di dimensioni specificate. L'esempio seguente salva continuamente gli eventi in file <10 MB:
sysdig -C 10 -w monitoring-wordpress.scap

Questo creerà un mucchio di file non più grandi di 10 MB:

ls -lh monitoring-wordpress *
-rw-r - r--. 1 radice root 9.6M 7 gennaio 17:13 monitoring-wordpress.scap0 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap1 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap2 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap3 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap4 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap5 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap6 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:14 monitoring-wordpress.scap7 -rw-r - r--. 1 root root 6.4M 7 gennaio 17:14 monitoring-wordpress.scap8
  • Specifica il numero massimo di file che Sysdig deve conservare con il flag -W. Ad esempio, puoi combinare i flag -C e -W in questo modo:
sysdig -C 10 -W 4 -w monitoring-wordpress.scap

Il comando sopra manterrà solo gli ultimi quattro file di acquisizione:

ls -lh monitoring-wordpress *
-rw-r - r--. 1 radice root 7,2M 7 gennaio 17:21 monitoring-wordpress.scap0 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:21 monitoring-wordpress.scap1 -rw-r - r--. 1 radice root 9.6M 7 gennaio 17:21 monitoring-wordpress.scap2 -rw-r - r--. 1 root root 9.6M 7 gen 17:21 monitoring-wordpress.scap3 root @ cd06093b141b: / # sysdig -C 10 -W 4 -w monitoring-wordpress.scap

Monitoraggio in tempo reale

Con Sysdig, puoi anche analizzare i dati in tempo reale. A prima vista, questo può sembrare un compito scoraggiante perché, per impostazione predefinita, tutti gli eventi vengono continuamente stampati sulla console. Fortunatamente, gli scalpelli sono qui per aiutarti.

Facciamo un esempio.

Analizza i tuoi processi in base al contenitore

  1. Eseguire il comando seguente per elencare i contenitori:
docker ps
ID CONTENITORE COMANDO IMMAGINE STATO CREATO PORTI NOMI 5b253e74e8e7 sysdig / sysdig "/docker-entrypoint.…" 9 minuti fa Fino a 9 minuti sysdig 06def7875617 wordpress: ultimo "docker-entrypoint.s…" 3 ore fa Su 3 ore 0.0.0.0:8000 -> 80 / tcp wordpress-sysdig_wordpress_1 6bd8418eb03f mysql: 5.7 "docker-entrypoint.s ..." 3 ore fa Fino a 3 ore 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1

2. Puoi analizzare i processi in esecuzione nel contenitore WordPress con:

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

3. Allo stesso modo, puoi analizzare i processi in esecuzione nel contenitore MySQL:

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

Notare che, non molto diverso da questo esempio, Sysdig può monitorare il traffico di rete, l'utilizzo del disco e così via.

In questo tutorial, sono stati esaminati i fondamenti dell'utilizzo di Sysdig per comprendere chiaramente l'attività generata dai contenitori. Gli esempi in questo post di blog ti hanno aiutato a iniziare e, in tutorial futuri, ti mostreremo come usare Csysdig e Sysdig Inspect.