Курс: Продающий лендинг для вашего бизнеса Бесплатно
Создайте сайт с нуля за 40 минут и запустите продажи

Sysdig: как анализировать данные сервера с Ubuntu 16.04

Обсудить

Введение

Sysdig – это комплексное системное приложение, которое позволяет следить, сохранять и анализировать данные работы вашей системы. Принцип работы утилиты – она подключается к ядру системы и следит за всей информацией, проходящей через ядро. Как правило, приложение мониторит только тот сервер, на котором оно установлено, однако при желании есть возможность использовать утилиту Sysdig Cloud, которая позволяет удаленно наблюдать за состоянием нескольких серверов.

Возвращаясь к приложению для одного сервера – оно доступно практически для всех ОС семейства Linux, а также для Windows и Mac OS (но с чуть урезанным функционалом). Помимо возможности работать в командной строке Sysdig дает возможность использовать csysdig – интерактивный пользовательский интерфейс.

В этом руководстве мы установим и используем Sysdig для мониторинга сервера на Ubuntu 16.04: понаблюдаем за происходящими в системе событиями, сохраним их в файлы и применим фильтры к результатам, чтобы проанализировать их.

Требования

Для того, чтобы выполнить необходимые действия, вам понадобится сервер с установленной ОС Ubuntu 16.04 и пользователем, который может выполнять команды sudo.

 

Сервер на Timeweb

 

Шаг 1: установка Sysdig при помощи официального скрипта

В репозиторий Ubuntu входит пакет Sysdig, однако чаще всего он на одну или две версии отстает от последней версии. Поэтому лучше всего устанавливать эту утилиту, используя официальный скрипт, который можно найти на странице разработчиков. Так мы поступим и в этой статье.

Для начала обновите список доступных пакетов, чтобы можно было скачать самый новый из имеющихся:

$ sudo apt-get update

Теперь загрузите скрипт установки Sysdig, используя следующую команду:

$ curl https://s3.amazonaws.com/download.draios.com/stable/install-sysdig -o install-sysdig

Скрипт установки будет сохранен в файл install-sysdig в текущей директории. Далее вам необходимо выполнить этот скрипт, но так как выполнять скачанные из сети файлы небезопасно, перед запуском скрипта его лучше проверить. Поэтому откройте файл в любом текстовом редакторе либо выполните команду less, чтобы его содержимое высветилось на экране.

$ less ./install-sysdig

Проверьте команды, которые будет выполнять скрипт – если нет ничего странного, то запустите скрипт следующей командой:

$ cat ./install-sysdig | sudo bash

Далее будут установлены все зависимости, включая заголовки ядра и модули. Вы увидите на экране примерно такой вывод:

* Detecting operating system
* Installing Sysdig public key
OK
* Installing sysdig repository
* Installing kernel headers
* Installing sysdig
...
sysdig-probe:
Running module version sanity check.
- Original module
 - No original module exists within this kernel
- Installation
 - Installing to /lib/modules/4.4.0-59-generic/updates/dkms/
depmod....
DKMS: install completed.
Processing triggers for libc-bin (2.23-0ubuntu5) ...

Теперь, когда утилита Sysdig установлена, разберемся, для чего ее можно использовать.

Шаг 2: мониторинг системы в реальном времени

В этом разделе вы узнаете о том, как использовать Sysdig для мониторинга событий на сервере с Ubuntu 16.04. Для того, чтобы запустить Sysdig, вы должны обладать административными правами. При этом команда запуска может иметь несколько различных ключей, но мы запустим ее в самом базовом виде:

$ sudo sysdig

Команда даст вам возможность в реальном времени видеть данные по состоянию сервера, которые обновляются каждые две секунды. Однако как только вы выполните команду, вам будет тяжело анализировать данные, так как они будут постоянно меняться. Остановить Sysdig можно сочетанием клавиш CTRL+C.

Перед тем, как снова запустить утилиту, давайте ознакомимся со стандартным выводом, который она дает.

253566 11:16:42.808339958 0 sshd (12392) > rt_sigprocmask
253567 11:16:42.808340777 0 sshd (12392) < rt_sigprocmask
253568 11:16:42.808341072 0 sshd (12392) > rt_sigprocmask
253569 11:16:42.808341377 0 sshd (12392) < rt_sigprocmask
253570 11:16:42.808342432 0 sshd (12392) > clock_gettime
253571 11:16:42.808343127 0 sshd (12392) < clock_gettime
253572 11:16:42.808344269 0 sshd (12392) > read fd=10(<f>/dev/ptmx) size=16384
253573 11:16:42.808346955 0 sshd (12392) < read res=2 data=..

Каждая строка посвящена одному из событий. Каждая колонка вывода имеет свое значение, в целом они расшифровываются вот так:

%evt.num %evt.outputtime %evt.cpu %proc.name (%thread.tid) %evt.dir %evt.type %evt.info

Значения колонок:

  • evt.num – возрастающий номер события;
  • evt.outputtime – время события, которое вы можете настроить;
  • evt.cpu – номер процессора, где было перехвачено событие. Если смотреть вывод выше, то можно увидеть цифру 0 – она равняется первому процессору сервера;
  • proc.name – имя процессора, где было создано событие;
  • thread.tid – номер потока, где было создано событие (если это однопотоковый процесс, то данный показатель совпадает с номером процесса);
  • evt.dir – направление события. Для входящих событий вы увидите значок >, для исходящих <;
  • evt.type – тип события (например, write – запись, read – чтение и так далее);
  • evt.info – список аргументов события.

Нет смысла рассказывать в этой статье обо всех фильтрах, давайте попробуем использовать несколько из них. Начнем с фильтра syslog.severity.str в классе syslog, который покажет посылаемые в syslog сообщения, имеющие определенный уровень важности. Например, следующая команда покажет сообщения, которые отсылаются на информационном уровне:

$ sudo sysdig syslog.severity.str=info

Примечание. В зависимости от уровня, который вы выберете, вы можете не увидеть никакого вывода после ввода команды. Либо вывод может занять долгое время. Для решения возможной проблемы откройте второй эмулятор терминала и выполните команду, которая должна создать сообщение в syslog. Например, установите какой-нибудь пакет или обновите систему.

Прервите команду, нажав CTRL+C.

Вывод (который достаточно легко расшифровать) будет выглядеть примерно так:

10716 03:15:37.111266382 0 sudo (26322) < sendto syslog sev=info msg=Jan 24 03:15:37 sudo: pam_unix(sudo:session): session opened for user root b
618099 03:15:57.643458223 0 sudo (26322) < sendto syslog sev=info msg=Jan 24 03:15:57 sudo: pam_unix(sudo:session): session closed for user root
627648 03:16:23.212054906 0 sudo (27039) < sendto syslog sev=info msg=Jan 24 03:16:23 sudo: pam_unix(sudo:session): session opened for user root b
629992 03:16:23.248012987 0 sudo (27039) < sendto syslog sev=info msg=Jan 24 03:16:23 sudo: pam_unix(sudo:session): session closed for user root
639224 03:17:01.614343568 0 cron (27042) < sendto syslog sev=info msg=Jan 24 03:17:01 CRON[27042]: pam_unix(cron:session): session opened for user
639530 03:17:01.615731821 0 cron (27043) < sendto syslog sev=info msg=Jan 24 03:17:01 CRON[27043]: (root) CMD ( cd / && run-parts --report /etc/
640031 03:17:01.619412864 0 cron (27042) < sendto syslog sev=info msg=Jan 24 03:17:01 CRON[27042]: pam_unix(cron:session): session closed for user

Фильтр можно поставить и на определенный процесс. Например, можно посмотреть события, связанные с текстовым редактором nano:

$ sudo sysdig proc.name=nano

Так как фильтр сосредоточен на nano, для того, чтобы появился какой-нибудь вывод, вам необходимо использовать текстовый редактор, то есть открыть в nano какой-нибудь файл. Откройте еще один терминал, подключитесь к своему серверу и выполните команду nano, чтобы открыть текстовый файл. Запишите в нем что-нибудь, затем сохраните файл и вернитесь в первый терминал.

И тогда вы увидите примерно вот такой вывод:

21840 11:26:33.390634648 0 nano (27291) < mmap res=7F517150A000 vm_size=8884 vm_rss=436 vm_swap=0
21841 11:26:33.390654669 0 nano (27291) > close fd=3(<f>/lib/x86_64-linux-gnu/libc.so.6)
21842 11:26:33.390657136 0 nano (27291) < close res=0
21843 11:26:33.390682336 0 nano (27291) > access mode=0(F_OK)
21844 11:26:33.390690897 0 nano (27291) < access res=-2(ENOENT) name=/etc/ld.so.nohwcap
21845 11:26:33.390695494 0 nano (27291) > open
21846 11:26:33.390708360 0 nano (27291) < open fd=3(<f>/lib/x86_64-linux-gnu/libdl.so.2) name=/lib/x86_64-linux-gnu/libdl.so.2 flags=4097(O_RDONLY|O_CLOEXEC) mode=0
21847 11:26:33.390710510 0 nano (27291) > read fd=3(<f>/lib/x86_64-linux-gnu/libdl.so.2) size=832

Затем снова остановите процесс, нажав CTRL+C.

Просмотр событий в реальном времени – это зачастую не самый лучший способ использовать Sysdig. Существует и другой метод – сохранить данные для того, чтобы позже проанализировать их. В следующем разделе мы рассмотрим, как это можно сделать.

Шаг 3: сохранение состояния системы в файл

Если вы сохраните события, происходящие в системе, в файл, то сможете потом проанализировать информацию из него. Для того, чтобы сделать это, введите команду sysdig с ключом –w и укажите конкретное имя файла. Должно получится примерно так:

$ sudo sysdig -w testname.scap

Теперь Sysdig будет сохранять информацию в этот файл до тех пор, пока вы не нажмете CTRL+C. Со временем этот файл может стать достаточно большим. Поэтому вы можете использовать ключ –n, который указывает, какое количество событий будет сохранено в файл. После того, как заданное количество событий будет сохранено, команда перестанет выполняться. Например, вот так будет выглядеть команда для 200 событий:

$ sudo sysdig -n 200 -w testfile.scap

Однако несмотря на то, что вы можете указать определенное количество событий для сохранения в файле, намного удобнее будет использовать ключ –С, который позволяет разделять сохраненные данные на несколько файлов определенного размера. А для того, чтобы память не была переполнена, вы можете задать Sysdig хранить лишь несколько из сохраненных файлов. Иными словами, Sysdig поддерживает логирование событий с возможной настройкой работы с файлами – и это можно задать одной командой.

Например, если вы хотите сохранять события в файлы, которые весят не более 1 Мб, и сохранить лишь последние 5 файлов из них (за это отвечает ключ –W), то вам нужно выполнить вот такую команду:

$ sudo sysdig -C 1 -W 5 -w testfile.scap

Выведите список файлов, используя команду ls –l testfile*, и вы увидите примерно вот такой вывод:

-rw-r--r-- 1 root root 985K Nov 23 04:13 testfile.scap0
-rw-r--r-- 1 root root 952K Nov 23 04:14 testfile.scap1
-rw-r--r-- 1 root root 985K Nov 23 04:13 testfile.scap2
-rw-r--r-- 1 root root 985K Nov 23 04:13 testfile.scap3
-rw-r--r-- 1 root root 985K Nov 23 04:13 testfile.scap4

При этом фильтры можно применять и к сохраненным событиям. Например, чтобы сохранить 300 событий, связанных с текстовым редактором nano, используйте следующую команду:

$ sudo sysdig -n 300 -w testfilenano.scap proc.name=nano

Теперь протестируйте эту команду – откройте другой терминал и используйте в нем редактор nano для изменения и сохранения какого-либо текста в файлах. Все эти действия будут сохраняться в файл testfilenano.scap до тех пор, пока их не станет 300.

Фильтр можно использовать и для выделения, скажем, всех событий, связанных с записью. Команда будет выглядеть следующим образом:

$ sudo sysdig -w sysdig-write-events.scap evt.type=write

Чтобы остановить ее, нажмите CTRL+C.

При помощи Sysdig можно сделать гораздо больше интересных вещей, однако я надеюсь, что примеры, показанные выше, дали вам общее представление о том, как можно использовать эту утилиту для записи. Теперь перейдем к тому, как анализировать данные.

Шаг 4: чтение и анализ событий

Читать сохраненные в файлах данные так же легко, как набрать ключ –r в следующей команде:

$ sudo sysdig -r testfile.scap

Эта команда выгрузит все содержимое файла на экран, и это не самый удобный способ работать с информацией, особенно если файл большой. Однако к этому файлу вы можете применить те же фильтры, которые применяете при записи файла.

Например, если вам нужно отследить какой-то определенный тип события, вы можете указать его в “evt.type”, и тогда команда будет выглядеть следующим образом:

$ sysdig -r testfilenano.scap evt.type=write

Вывод будет выглядеть следующим образом:

21340 13:32:14.577121096 0 nano (27590) < write res=1 data=.
21736 13:32:17.378737309 0 nano (27590) > write fd=1 size=23
21737 13:32:17.378748803 0 nano (27590) < write res=23 data=#This is a test file..#
21752 13:32:17.611797048 0 nano (27590) > write fd=1 size=24
21753 13:32:17.611808865 0 nano (27590) < write res=24 data= This is a test file..# 
21768 13:32:17.992495582 0 nano (27590) > write fd=1 size=25
21769 13:32:17.992504622 0 nano (27590) < write res=25 data=TThis is a test file..# T
21848 13:32:18.338497906 0 nano (27590) > write fd=1 size=25
21849 13:32:18.338506469 0 nano (27590) < write res=25 data=hThis is a test file..[5G
21864 13:32:18.500692107 0 nano (27590) > write fd=1 size=25
21865 13:32:18.500714395 0 nano (27590) < write res=25 data=iThis is a test file..[6G
21880 13:32:18.529249448 0 nano (27590) > write fd=1 size=25
21881 13:32:18.529258664 0 nano (27590) < write res=25 data=sThis is a test file..[7G
21896 13:32:18.620305802 0 nano (27590) > write fd=1 size=25

Теперь давайте посмотрим содержимое файла из предыдущего шага (файл sysdig-write-events.scap). Мы знаем, что все события, сохраненные в этом файле, касаются записи, поэтому давайте посмотрим содержимое:

$ sudo sysdig -r sysdig-write-events.scap evt.type=write

Ниже вы увидите частичный вывод. Если на сервере была какая-то активность, связанная с SSH, то вы увидите примерно следующее:

42585 19:58:03.040970004 0 gmain (14818) < write res=8 data=........
42650 19:58:04.279052747 0 sshd (22863) > write fd=3(<4t>11.11.11.11:43566->22.22.22.22:ssh) size=28
42651 19:58:04.279128102 0 sshd (22863) < write res=28 data=.8c..jp...P........s.E<...s.
42780 19:58:06.046898181 0 sshd (12392) > write fd=3(<4t>11.11.11.11:51282->22.22.22.22:ssh) size=28
42781 19:58:06.046969936 0 sshd (12392) < write res=28 data=M~......V.....Z...\..o...N..
42974 19:58:09.338168745 0 sshd (22863) > write fd=3(<4t>11.11.11.11:43566->22.22.22.22:ssh) size=28
42975 19:58:09.338221272 0 sshd (22863) < write res=28 data=66..J.._s&U.UL8..A....U.qV.*
43104 19:58:11.101315981 0 sshd (12392) > write fd=3(<4t>11.11.11.11:51282->22.22.22.22:ssh) size=28
43105 19:58:11.101366417 0 sshd (12392) < write res=28 data=d).(...e....l..D.*_e...}..!e
43298 19:58:14.395655322 0 sshd (22863) > write fd=3(<4t>11.11.11.11:43566->22.22.22.22:ssh) size=28
43299 19:58:14.395701578 0 sshd (22863) < write res=28 data=.|.o....\...V...2.$_...{3.3|
43428 19:58:16.160703443 0 sshd (12392) > write fd=3(<4t>11.11.11.11:51282->22.22.22.22:ssh) size=28
43429 19:58:16.160788675 0 sshd (12392) < write res=28 data=..Hf.%.Y.,.s...q...=..(.1De.
43622 19:58:19.451623249 0 sshd (22863) > write fd=3(<4t>11.11.11.11:43566->22.22.22.22:ssh) size=28
43623 19:58:19.451689929 0 sshd (22863) < write res=28 data=.ZT^U.pN....Q.z.!.i-Kp.o.y..
43752 19:58:21.216882561 0 sshd (12392) > write fd=3(<4t>11.11.11.11:51282->22.22.22.22:ssh) size=28

Обратите внимание, что все строчки с информацией о входящих событиях содержат 11.11.11.11:51282->22.22.22.22:ssh. Эти события исходят от внешнего IP-адреса клиента 11.11.11.11 на IP-адрес сервера 22.22.22.22 . Так как эти события происходили через SSH-соединение, то их можно назвать ожидаемыми. Но, может быть, были еще какие-то события не с известного адреса? Это легко выяснить.

Вы можете использовать различные операторы сложения, работая с Sysdig. Вы уже видели равно (=); другие, которые можно использовать: !=, >, >=, < и <=. В следующей команде идет фильтрация по удаленному IP-адресу. Используйте знак неравенства для того, чтобы увидеть события с других IP-адресов (не 11.11.11.11):

$ sysdig -r sysdig-write-events.scap fd.rip!=11.11.11.11

Теперь вывод покажет вам все события, которые были выполнены с других IP-адресов:

294479 21:47:47.812314954 0 sshd (28766) > read fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) size=1
294480 21:47:47.812315804 0 sshd (28766) < read res=1 data=T
294481 21:47:47.812316247 0 sshd (28766) > read fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) size=1
294482 21:47:47.812317094 0 sshd (28766) < read res=1 data=Y
294483 21:47:47.812317547 0 sshd (28766) > read fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) size=1
294484 21:47:47.812318401 0 sshd (28766) < read res=1 data=.
294485 21:47:47.812318901 0 sshd (28766) > read fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) size=1
294486 21:47:47.812320884 0 sshd (28766) < read res=1 data=.
294487 21:47:47.812349108 0 sshd (28766) > fcntl fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) cmd=4(F_GETFL)
294488 21:47:47.812350355 0 sshd (28766) < fcntl res=2(<f>/dev/null)
294489 21:47:47.812351048 0 sshd (28766) > fcntl fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) cmd=5(F_SETFL)
294490 21:47:47.812351918 0 sshd (28766) < fcntl res=0(<f>/dev/null)
294554 21:47:47.813383844 0 sshd (28767) > write fd=3(<4t>33.33.33.33:49802->22.22.22.22:ssh) size=976
294555 21:47:47.813395154 0 sshd (28767) < write res=976 data=........zt.....L.....}....curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-s
294691 21:47:48.039025654 0 sshd (28767) > read fd=3(<4t>221.229.172.117:49802->45.55.71.190:ssh) size=819

Дальнейшее расследование показывает, что IP-адрес 33.33.33.33 принадлежит компьютеру из Китая. Это повод для беспокойства!

Это всего лишь один из способов использования Sysdig – для того, чтобы следить за траффиком на своем сервере.

Перейдем к некоторым дополнительным скриптам для анализа данных о событиях.

Шаг 5: использование чизелов для мониторинга и анализа

Чизелы (chisels) – это скрипты Lua, которые вы можете использовать для анализа потока данных о событиях в Sysdig. Вместе с установкой Sysdig у вас в наличии будет еще около 50 скриптов, увидеть список всех доступных скриптов можно при помощи следующей команды:

$ sysdig -cl

Список интересных и полезных чизелов включает в себя:

  • netstat: список (и при желании фильтр) сетевых соединений;
  • shellshock_detect: показывает shellshock атаки;
  • spy_users: показывает интерактивную пользовательскую активность;
  • listloginshells: выводит список ID шелл логинов;
  • spy_ip: показывает, какие данные были изменены заданным IP-адресом;
  • spy_port: показывает, какие данные были изменены заданным номером порта.
  • httptop: показывает основные (топ) HTTP-запросы.

Если вы хотите получить больше информации о каком-то из чизелов, то используйте ключ –i. Например, узнать о netstat можно следующим образом:

$ sysdig -i netstat

После этого воспользуемся самой командой netstat:

$ sudo sysdig -c netstat

Вывод будет выглядеть примерно так:

Proto Server Address Client Address State TID/PID/Program Name
tcp 22.22.22.22:22 11.11.11.11:60422 ESTABLISHED 15567/15567/sshd
tcp 0.0.0.0:22 0.0.0.0:* LISTEN 1613/1613/sshd

Гораздо более интересным функционалом обладает чизел spy_users, который позволяет следить за действиями пользователей. Давайте разберемся, как он работает. Введите команду:

$ sudo sysdig -c spy_users

Теперь откройте второй терминал и подключитесь к своему серверу. Выполните в этом терминале какие-либо команды, а потом вернитесь в первый терминал. Все команды, которые вы выполнили во втором терминале, отобразятся в первом терминале, где вы выполнили команду sysdig -c spy_users.

Теперь перейдем к изучению Csysdig, графического пользовательского интерфейса.

Заключение

Sysdig поможет вам следить за своим сервером и отслеживать любые возникающие ошибки. Программа даст вам возможность заглянуть глубже в работу системы на сервере. Также в этом руководстве вы познакомились с чизелами – мощными инструментами Sysdig. Они написаны на Lua, поэтому вы всегда можете настроить их или даже написать новые.

Комментарии

С помощью соцсетей
У меня нет аккаунта Зарегистрироваться
Нажимая кнопку «Зарегистрироваться», я даю согласие на обработку своих персональных данных, указанных в форме регистрации.
С помощью соцсетей
У меня уже есть аккаунт Войти
Нажимая кнопку «Зарегистрироваться», я даю согласие на обработку своих персональных данных, указанных в форме регистрации.
Инструкции по восстановлению пароля высланы на Ваш адрес электронной почты.
Пожалуйста, укажите email вашего аккаунта
Ваш баланс 10 ТК
1 ТК = 1 ₽
О том, как заработать и потратить Таймкарму, читайте в этой статье
Чтобы потратить Таймкарму, зарегистрируйтесь на нашем сайте