Sysdig — инструмент для диагностики Linux-систем

    Sysdig — инструмент для диагностики Linux-систем

    Для сбора и анализа информации о системе в Linux используется целый набор утилит. Для диагностики каждого из компонентов системы используется отдельный диагностический инструмент.



    Информация о наиболее распространенных диагностических утилитах наглядно представлена на следующей схеме:

    Sysdig — инструмент для диагностики Linux-систем

    Недавно мы узнали об утилите Sysdig, разработанной компанией Draios. Она собирает информацию абсолютно обо всем:

    • о входящих сетевых соединениях и связанных с ними процессах;
    • о файлах, работа с которыми сопряжена с наибольшей нагрузкой на систему ввода/вывода;
    • о трафике в привязке к процессам;
    • о файлах и директориях, к которым обращаются пользователи;
    • о системных вызовах, файлах и сетевых соединениях, работа с которыми завершилась ошибкой…


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

    DTrace, Systemtap и Sysdig



    Sysdig является далеко не первой попыткой создать инструмент с расширенными возможностями для сбора информации о работающей Linux-системе.
    В числе близких по функциональности инструментов следует прежде всего назвать, во-первых, DTrace — фреймворк динамической трассировки, разработанный компанией Sun Microsystems. Он используется для наблюдения за количеством потребляемой памяти, процессорным временем, сетевыми ресурсами, которые используются активными процессами на работающей системе.

    В DTrace используются скрипты на языке D (Си-подобный язык, включающий также специализированные функции и переменные для трассировки). Скрипты включают список датчиков (probes), которым соответствуют определенные действия. Датчики срабатывают при выполнении заданного условия (например, при открытии файла или запуске процесса), после чего выполняется соответствующее действие. Имеется возможность передачи информации от одного датчика к другому.

    DTrace представляет собой мощный, но при этом сложный в работе инструмент. Он требует от пользователя достаточно глубоких технических знаний. Написание и отладка D-скриптов также представляют собой трудоемкий (в особенности для пользователей, не имеющих должных навыков программирования) процесс, занимающий много времени.

    Весьма близок к DTrace по принципу работы и набору функций инструмент Systemtap (год с небольшим назад о нем была опубликована небольшая статья на Хабре). Systemtap представляет собой интерфейс командной строки и скриптовый язык. Он осуществляет мониторинг системных событий и в случае наступления какого-либо события назначает для него обработчик.

    В качестве событий могут выступать, например, начало или конец сессии Systemtap, срабатывание таймера и т.п.). Обработчиком события называется последовательность скриптовых операторов, которые выполняются, когда событие срабатывает. Обычно обработчики вычленяют информацию из контекста события или выводят ее на консоль.

    Существенным минусом SystemTap является очень сложный синтаксис скриптового языка. Написание и отладка скриптов также забирают у пользователя немало времени и сил.

    В отличии от упомянутых выше инструментов Sysdig устроен по-другому. По архитектуре он близок к таким продуктам, как libcap, tcpdump, wireshark. Специальный драйвер sysdig probe перехватывает системные события на уровне ядра, после чего запускается функция ядра tracepoints, которая, в свою очередь запускает для этих событий обработчики. Обработчики сохраняют информацию о событии в cовместно используемом буфере. Затем эта информация может быть выведена на экран или сохранена в текстовом файле.

    Благодаря такой архитектуре sysdig не влияет на производительность системы. Детальную информацию о системных событиях можно получать при помощи простых команд. Для выполнения некоторых операций используются готовые скрипты на языке Lua (более подробно о них еще пойдет речь ниже).

    Установка



    В официальные репозитории sysdig пока что не включен. Чтобы запустить автоматическую установку Sysdig, нужно выполнить следующую команду:

    curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
    


    О процедурах ручной установки для различных дистрибутивов Linux можно подробно почитать в официальной документации.

    Первое знакомство



    По завершении установки введем следующую команду:

    # sysdig
    


    Все события, происходящие в системе, будут записываться в стандартный вывод:

    63889 15:25:12.908695644 3 notify-osd (7209) > poll fds=3:u5 timeout=4294967295 
    63890 15:25:12.908698249 3 notify-osd (7209)  writev fd=3(<u>) size=4 
    63893 15:25:12.908704065 2 gnome-terminal (18260) > lseek fd=24(/tmp/vteIVHGFX (deleted)) offset=0 whence=2(SEEK_END) 
    63894 15:25:12.908704595 2 gnome-terminal (18260)  lseek fd=24(/tmp/vteIVHGFX (deleted)) offset=0 whence=2(SEEK_END) 
    63896 15:25:12.908709655 2 gnome-terminal (18260)  write fd=24(/tmp/vteIVHGFX (deleted)) size=80 
    63899 15:25:12.908710722 3 notify-osd (7209) > writev res=4 data=+... 
    63900 15:25:12.908713828 3 notify-osd (7209) < poll fds=3:u1 timeout=4294967295 
    63901 15:25:12.908714531 2 gnome-terminal (18260) < write res=80 data=1275 15:25:12.596942000 1 rs:main (941) < open fd=-2(ENOENT) name=/dev/xconsole 
    


    В каждой строке вывода содержится информация об одном событии. Она отображается в следующем формате:

    %evt.num %evt.time %evt.cpu %proc.name (%thread.tid) %evt.dir %evt.type %evt.args
    


    Вывод состоит из следующих полей:

    • evt.num — номер события;
    • evt.time — время события;
    • evt.cpu — номер процессора, в котором было перехвачено событие;
    • proc.name — имя процесса;
    • thread.tid — номер потока (у однопотоковых процессов он совпадает c номером процесса);
    • evt.dir — направление события (< — для входящих процессов, > — для исходящих);
    • evt.type — тип события;
    • evt.args — аргументы события.


    Сохранение информации в файлах



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

    # sysdig -w myfile.scap
    


    Если нужно записать в файл информацию не обо всех системных событиях, а лишь об ограниченном их количестве (скажем, только о 100 событиях), используется опция -n:

    # sysdig —n 100 —w myfile.scap
    


    Вывести на консоль информацию, ранее сохраненную в файле, можно с помощью опции -r:

    # sysdig -r myfile.scap
    


    Sysdig сохраняет в каждом файле полный снимок операционной системы (запущенные процессы, активные файлы, активные пользователи и т.п.).

    Фильтры



    Как мы уже увидели из приведенных выше примеров, sysdig пишет в стандартный вывод вcю информацию о событиях. Мы можем сделать так, чтобы на консоль выводилась только та информация, которая нужна нам. Для этого используются фильтры.

    Они указываются в конце строки (как, например, в tcpdump). Они могут быть применены как при записи событий «на лету», так и при записи в файл. Попытаемся проследить за работой какой-либо команды& — например, cat:

    # sysdig proc.name = cat 
    
    21368 13:10:15.384878134 1 cat (8298) < execve res=0 exe=cat args=index.html. tid=8298(cat) pid=8298(cat) ptid=1978(bash) cwd=/root fdlimit=1024
    21371 13:10:15.384948635 1 cat (8298) > brk size=0
    21372 13:10:15.384949909 1 cat (8298) < brk res=10665984
    21373 13:10:15.384976208 1 cat (8298) > mmap
    21374 13:10:15.384979452 1 cat (8298) < mmap
    21375 13:10:15.384990980 1 cat (8298) > access
    21376 13:10:15.384999211 1 cat (8298) < access
    21377 13:10:15.385008602 1 cat (8298) > open
    21378 13:10:15.385014374 1 cat (8298) < open fd=3(/etc/ld.so.cache) name=/etc/ld.so.cache flags=0(O_NONE) mode=0
    21379 13:10:15.385015508 1 cat (8298) > fstat fd=3(/etc/ld.so.cache)
    21380 13:10:15.385016588 1 cat (8298) < fstat res=0
    21381 13:10:15.385017033 1 cat (8298) > mmap
    21382 13:10:15.385019763 1 cat (8298) < mmap
    21383 13:10:15.385020047 1 cat (8298) > close fd=3(/etc/ld.so.cache)
    21384 13:10:15.385020556 1 cat (8298) < close res=0
    


    Попробуем применить фильтры. Их можно задавать при помощи стандартных операторов сравнения (=, !=, <, <=, >, >=, contains). Можно также использовать булевы операторы (or, and, not) и скобки.

    Введем следующую команду:

    # sysdig proc.name = cat and proc.name = vi
    


    Она будет отслеживать всю активность программ cat и vi:

    56239 12:14:01.449463618 0 BrowserBlocking (2587) > open 
    56240 12:14:01.449467018 0 BrowserBlocking (2587) < open fd=142(/proc/16213/statm) name=/proc/16213/statm flags=1(O_RDONLY) mode=0 
    63158 12:14:01.493237287 3 gnome-terminal (3910) > open 
    63177 12:14:01.493281181 3 gnome-terminal (3910) < open fd=18(/tmp/vteHGSYFX) name=/tmp/vteHGSYFX flags=39(O_EXCL|O_CREAT|O_RDWR) mode=0 
    63200 12:14:01.493309748 3 gnome-terminal (3910) > open 
    63205 12:14:01.493319526 3 gnome-terminal (3910) < open fd=18(/tmp/vteHESYFX) name=/tmp/vteHESYFX flags=39(O_EXCL|O_CREAT|O_RDWR) mode=0 
    


    Команда

    # sysdig proc.name!=cat and evt.type=open
    


    будет выводить на консоль информацию об открытых событиях для всех процессов, кроме cat:

    2111 12:15:47.656367409 1 rs:main (914) > open 
    2112 12:15:47.656368926 1 rs:main (914)  open 
    2114 12:15:47.656371170 1 rs:main (914)  open 
    2116 12:15:47.656374373 1 rs:main (914)  open 
    2118 12:15:47.656376563 1 rs:main (914)  open 
    2120 12:15:47.656378615 1 rs:main (914)  open 
    


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

    # sysdig -l
    


    (подробные разъяснения и комментарии см. здесь).

    С помощью фильтров можно легко получать полезную и важную информацию. Например, просмотреть информацию о входящих сетевых соединениях, полученных всеми процессами, кроме apache, можно при помощи простой команды:

    # sysdig evt.type=accept and proc.name!=apache
    


    Как уже было сказано выше, в выводе sysdig присутствуют поля evt.arg и evt.rawarg. О них следует рассказать отдельно. Каждое событие, регистрируемое sysdig, относится к определенному типу (например, open, read и т.п.), а также обладает определенными параметрами (fd, name и т.п.), которые закодированы по определенным правилам. Не будем разбирать все это подробно (заинтересованных читателей отсылыем к официальной документации) и остановимся на том, как эти аргументы могут быть использованы при создании фильтров.

    Рассмотрим следующую команду:

    # sysdig evt.type=execve and evt.arg.ptid=bash
    


    Она выведет на консоль список процессов, запущенных интерактивными пользователями. Установленный фильтр принимает системные вызовы execve (которые используются для выполнения программ) только в случае, если для них родительским процессом для них является bash.

    Различие между evt.arg и evt.rawarg заключается в том, что последний не расшифровывает идентификационные номера процессов, коды ошибок и т.п., оставляя все аргументы в «сырой» цифровой форме.
    Например, просмотреть список процессов, вызвавших ошибки, можно с помощью команды:

    # sysdig "evt.rawarg.res<0 or evt.rawarg.fd<0"
    
    257727 15:57:35.398754060 3 chrome (17326) < futex res=-110(ETIMEDOUT) 
    257737 15:57:35.399218996 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257749 15:57:35.399362914 1 Xorg (1153) < read res=-11(EAGAIN) data= 
    257834 15:57:35.401067094 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257836 15:57:35.401106092 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257849 15:57:35.402594284 2 chrome (4446) < futex res=-110(ETIMEDOUT) 
    257882 15:57:35.407348870 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257884 15:57:35.407358705 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257888 15:57:35.407373908 0 chrome (2493) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
    257922 15:57:35.407757377 1 Xorg (1153) < read res=-11(EAGAIN) data= 
    


    Полный список событий и параметров, которые могут быть использованы в фильтрах, можно посмотреть при помощи команды

    # sysdig -L
    


    Форматирование выводов



    Всю информацию, которую sysdig выводит на консоль, мы также можем представить в нужном нам формате. Для форматирования вывода нужно воспользоваться опцией -p, после которой указываются необходимые поля вывода:

    # sysdig -p"user:%user.name dir:%evt.arg.path" evt.type=chdir
    
    user:ubuntu dir:/root
    user:ubuntu dir:/root/tmp
    user:ubuntu dir:/root/Download
    


    Приведенная выше команда собирает информацию о системных вызовах chdir (они осуществляются каждый раз при выполнении команды cd) и выводят на консоль имена пользователей, выполняющих команду cd и имена директорий, в которые они переходят.

    С опцией -p используется следующий синтаксис:

    • перед именами полей ставится знак процента (%);
    • в строки можно добавлять любой текст (как в функции printf на языке С);
    • по умолчанию строка выводится на консоль только в том случае, когда в событии присутствуют все элементы, указанные после опции -p. Если в начале строки указать звездочку (*), то вывод будет представлен в неполном виде; отсутствующие поля будут обозначены как N/A.


    Введем команду:

    # sysdig -p"%evt.type %evt.dir %evt.arg.name" evt.type=open
    


    Она будет выводить только информацию об открытых исходящих событиях, например.

    open < /proc/23533/task/23533/stat
    open < /proc/23533/task/23535/stat
    open < /proc/23533/task/23536/stat
    open < /proc/23533/task/23539/stat
    open < /proc/23533/task/23540/stat
    open < /proc/23533/task/23541/stat
    open < /proc/23533/task/23542/stat
    open < /proc/23533/task/23543/stat
    open < /proc/23533/task/23544/stat
    


    Входящие события не имеют имени, поэтому информация о них в выводе не отображается.

    Если же мы введем команду

    # sysdig -p "*%evt.type %evt.dir %evt.arg.name" evt.type=open
    


    то в вывод будет включена информация и об исходящих событиях:

    open < /proc/22832/task/22838/stat
    open > 
    open < /proc/22832/task/22839/stat
    open > 
    open < /proc/22832/task/22840/stat
    open > 
    open < /proc/22832/task/22841/stat
    open > 
    open < /proc/22832/task/22842/stat
    open > 
    open < /proc/22832/task/22843/stat
    open > 
    open < /dev/urandom
    


    Чизелы



    Для анализа списка событий в Sysdigs используются небольшие скрипты, написанные на языке Lua. Разработчики называют их chisels (в русском переводе слово chisel означает «долото», «стамеска»). Для этого термина вряд ли можно найти адекватный русский эквивалент, поэтому мы решили оставить его без перевода и называть эти скрипты чизелами.
    Вывести на консоль список доступных чизелов можно при помощи команды:

    # sysdig -cl
    


    Просмотреть описание конкретного чизела и список используемых с ним аргументов можно с помощью опции -i:

    # sysdig -i fileslower
    
    Category: Performance
    ---------------------
    fileslower Trace slow file I/O
    Use the -i flag to get detailed information about a specific chisel
    Trace file I/O slower than a threshold, or all file I/O
    
    Args:
    [int] min_ms — minimum millisecond threshold for showing file I/O
    


    Запуск чизелов осуществляется с помощью опции -с. Попробуем запустить чизел topfiles_bytes (он выводит на экран список файлов на локальной машине, к которым осуществляется наибольшее количество обращений):

    # sysdig -c topfiles_bytes
    
    Bytes     Filename  
    ------------------------------
    3.21KB    /dev/input/event4
    2.93KB    /tmp/vte7IZWFX (deleted)
    864B      /dev/urandom
    800B      /tmp/vteL7ZWFX (deleted)
    498B      /dev/ptmx
    224B      /dev/dri/card0
    219B      /proc/16213/task/16221/stat
    217B      /proc/16213/task/16229/stat
    217B      /proc/16213/task/16219/stat
    215B      /proc/16213/task/16225/sta
    


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

    # sysdig -c topfiles_bytes "not fd.name contains /dev"
    Bytes     Filename  
    ------------------------------
    1.90KB    /tmp/vte7IZWFX (deleted)
    438B      /proc/16139/task/16145/stat
    438B      /proc/16139/task/16141/stat
    434B      /proc/16139/task/16150/stat
    430B      /proc/16139/task/16146/stat
    430B      /proc/16139/task/16147/stat
    430B      /proc/16139/task/16149/stat
    430B      /proc/16139/task/16148/stat
    428B      /proc/16139/task/16139/stat
    420B      /proc/16139/task/16142/stat
    


    С помощью фильтров можно также просмотреть информацию об обращениях к файлам в конкретной директории:

    # sysdig -c topfiles_bytes "fd.name contains /var/log/" 
    
    Bytes     Filename
    ------------------------------
    596B      /var/log/kern.log
    596B      /var/log/syslog
    596B      /var/log/messages
    


    Еще один фильтр позволяет увидеть, к каким файлам обращается указанный процесс:

    # sysdig -c topfiles_bytes "proc.name=vi" 
    


    Можно также посмотреть, к каким файлам обращается пользователь:

    $ sysdig -c topfiles_bytes "user.name=username" 
    
    Bytes     Filename  
    ------------------------------
    1.90KB    /tmp/vte7IZWFX (deleted)
    576B      /dev/urandom
    384B      /tmp/vteL7ZWFX (deleted)
    355B      /dev/ptmx
    


    Можно запускать несколько чизелов одновременно:

    # sysdig -c stdin -c stdout proc.name=cat
    


    Как уже было отмечено, все чизелы написаны на языке Lua, поэтому их можно без труда отредактировать или даже написать новые.
    С руководством по написанию скриптов можно ознакомиться здесь.

    Примеры использования



    Рассмотрим примеры типовых диагностических процедур, которые можно проводить с помощью sysdig.

    Сеть



    Просмотреть список всех подключений, не обслуживаемых Apache:

    # sysdig -p "%proc.name %fd.name" "evt.type=accept and proc.name!=httpd"
    


    Просмотреть, какими данными сервер обмениваются 192.168.0.1:
    в двоичном коде:

    # sysdig -s2000 -X -c echo_fds fd.cip=192.168.0.1
    


    в кодировке ASCII:

    # sysdig -s2000 -A -c echo_fds fd.cip=192.168.0.1
    


    Просмотреть информацию о процессах, потребляющих больше всего трафика:

    # sysdig -c topprocs_net
    Bytes     Process   
    ------------------------------
    885B      avahi daemon
    6.44KB    Chrome
    


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

    # sysdig -c fdcount_by fd.sport "evt.type=accept";
    


    объем отправленной информации, байт:

    # sysdig -c fdbytes_by fd.sport
    


    Просмотреть информацию о клиентских IP:

    количество установленных соединений:

    # sysdig -c fdcount_by fd.cip "evt.type=accept"
    


    объем отправленной информации, байт:

    # sysdig -c fdbytes_by fd.cip
    
    Bytes     fd.cip    
    ------------------------------
    375B      192.168.40.99
    250B      192.168.40.255
    226B      192.168.40.101
    133B      192.168.30.88
    125B      255.255.255.255
    


    Просмотреть информацию о запросах к внешнему MySQL серверу, осуществляемых через Apache:

    # sysdig -A -c echo_fds fd.sip=192.168.30.5 and proc.name=apache2 and evt.buffer contains SELECT
    


    Дисковая подсистема



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

    # sysdig -c topprocs_file
    Bytes     Process   
    ------------------------------
    12.61KB   BrowserBlocking
    3.89KB    Xorg
    3.79KB    Chrome_IOThread
    3.09KB    gnome-terminal
    


    Просмотреть информацию о процессах, использующих большое количество файлов:

    # sysdig -c fdcount_by proc.name "fd.type=file"
    
    BrowserBlocking	365
    Chrome_IOThread	44
    irqbalance	12
    upowerd	7
    dropbox	5
    Xorg	3
    alsa-sink	2
    rs:main	2
    compiz	1
    rsyslogd	1
    gnome-terminal	1
    


    Отслеживать операции чтения-записи, осуществляемые процессами:

    # sysdig -c topfiles_bytes
    
    Bytes     Filename  
    ------------------------------
    5.41KB    /dev/input/event4
    1.90KB    /tmp/vteHGSYFX (deleted)
    576B      /dev/urandom
    554B      /dev/ptmx
    384B      /tmp/vteHESYFX (deleted)
    219B      /proc/16139/task/16145/stat
    219B      /proc/15857/task/15865/stat
    219B      /proc/16139/task/16141/sta
    


    Просмотреть список файлов, с которыми apache осуществляет наибольшее количество операций чтения-записи:

    # sysdig -c topfiles_bytes proc.name=httpd
    


    Отслеживать открытие файлов в реальном времени:

    # sysdig -p "%12user.name %6proc.pid %12proc.name %3fd.num %fd.typechar %fd.name" evt.type=open
    
    root         1143   irqbalance   3   f /proc/interrupts
    root         1143   irqbalance   3   f /proc/stat
    root         1143   irqbalance   3   f /proc/irq/42/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/41/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/16/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/43/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/17/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/23/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/40/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/10/smp_affinity
    root         1143   irqbalance   3   f /proc/irq/18/smp_affinity
    


    Использование процессора



    Просмотреть статистику использования процессора:

    # sysdig -c topprocs_cpu
    
    CPU%      Process
    ------------------------------
    0.31%     sysdig
    0.09%     sshd
    0.03%     mysqld
    0.01%     nginx
    0.01%     php5-fpm
    

    Просмотреть статистику использования CPU0:
    # sysdig -c topprocs_cpu evt.cpu=0
    


    Просмотреть стандартный вывод для процесса:

    # sysdig -s4096 -A -c stdout proc.name=cat
    


    Производительность и ошибки



    Просмотреть информацию об ошибках открытия файлов httpd:

    # sysdig "proc.name=httpd and evt.type=open and evt.failed=true"
    


    Просмотреть статистику о файлах, на которые затрачивается больше всего времени:

    # sysdig -c topfiles_time 
    
    Time      Filename  
    ------------------------------
    403us     /dev/urandom
    267us     /dev/input/event4
    84us      /dev/dri/card0
    63us      /tmp/vte7IZWFX (deleted)
    34us      /tmp/vteL7ZWFX (deleted)
    20us      /proc/3467/task/3467/stat
    13us      /dev/ptmx
    11us      /proc/16010/task/16010/st
    


    Просмотреть информацию о процессах, на которые apache затрачивает больше всего времени:

    # sysdig -c topfiles_time proc.name=httpd
    


    Просмотреть информацию о процессах, при выполнении которых возникают ошибки ввода-вывода:

    # sysdig -c topprocs_errors
    
    ------------------------------
    2363      notify-osd
    1327      Xorg
    688       compiz
    349       chrome
    82        pulseaudio
    76        gtk-window-deco
    62        gnome-terminal
    50        alsa-sink
    30        Chrome_ChildIOT
    20        gnome-screensav
    20        nautilus
    14        Chrome_IOThread
    10        syndaemon
    10        gnome-settings-
    7         soffice.bin
    6         nm-applet
    6         dbus-daemon
    4         AudioThread
    3         pidgin
    2         NetworkManager
    2         mission-control
    1         gdbus
    


    Просмотреть информацию о файлах, при работе с которыми возникают ошибки ввода-вывода:

    # sysdig -c topfiles_errors
    
    #Errors   Filename  
    ------------------------------
    43        /dev/input/event4
    2         /dev/ptmx
    


    Просмотреть информацию о системных вызовах, возвращающих ошибки:
    # sysdig -c topscalls "evt.failed=true"
    
    # Calls   System Call                                                                                                        
    ------------------------------
    384       recvfrom
    273       futex
    169       read
    133       sendto
    41        select
    3         recvmsg
    


    Отслеживать ошибки при открытии файлов по мере их появления:

    # sysdig -p &"user.name %6proc.pid %12proc.name %3fd.num %fd.typechar %fd.name" evt.type=open and evt.failed=true
    
    root         1607   upowerd      -1  f /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0e/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_now
    root         1607   upowerd      -1  f /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0e/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_avg
    root         1607   upowerd      -1  f /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0e/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_max_design
    root         1607   upowerd      -1  f /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0e/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/power_now
    


    Вывести список операций ввода-вывода, выполнение которых происходит с задержкой более 1 мс:

    # sysdig -c fileslower 1
    
    TIME                    PROCESS      TYPE     LAT(ms) FILE
    2014-05-13 12:46:57.190 rsyslogd     read        3524 /proc/kmsg
    2014-05-13 12:46:57.197 rsyslogd     read           7 /proc/kmsg
    2014-05-13 12:46:57.205 rsyslogd     read           7 /proc/kmsg
    2014-05-13 12:46:57.209 rsyslogd     read           4 /proc/kmsg
    2014-05-13 12:46:57.221 rsyslogd     read          11 /proc/kmsg
    2014-05-13 12:46:57.225 rsyslogd     read           3 /proc/kmsg
    2014-05-13 12:46:57.233 rsyslogd     read           7 /proc/kmsg
    2014-05-13 12:46:57.241 rsyslogd     read           7 /proc/kmsg
    2014-05-13 12:46:58.362 upowerd      read         220 /sys/devices/LNXSYSTM:00/LN
    


    Безопасность



    Просмотреть информацию о директориях, посещаемых root-пользователем:

    # sysdig -p "%evt.arg.path" "evt.type=chdir and user.name=root"
    


    Отслеживать активность ssh:

    # sysdig -A -c echo_fds fd.name=/dev/ptmx and proc.name=sshd
    


    Отображать все события при открытии файла из директории /etc:

    # sysdig evt.type=open and fd.name contains /etc
    97367 12:50:02.164137993 0 unity-panel-ser (2193) < open fd=13(/etc/timezone) name=/etc/timezone flags=1(O_RDONLY) mode=0 
    97385 12:50:02.164419642 0 unity-panel-ser (2193) < open fd=13(/etc/localtime) name=/etc/localtime flags=1(O_RDONLY) mode=0 
    97405 12:50:02.164642935 0 unity-panel-ser (2193) < open fd=13(/etc/localtime) name=/etc/localtime flags=1(O_RDONLY) mode=0 
    


    Заключение



    Sysdig — проект еще молодой. В числе его несомненных преимуществ следует назвать простой синтаксис команд. Во многих случаях Sysdig дает более подробную, чем DTrace и Systemtap, информацию о системных событиях, и представляет ее в более понятной человекочитаемой форме. Еще один важный плюс заключается в том, что анализ работы системы может выполняться после сбора всех данных, а не одновременно с возникновением ошибки или проблемной ситуации.

    Перспективы у sysdig, несомненно, есть, и весьма неплохие. Надеемся, что продукт будет усовершенствован и займет достойное место в ряду утилит для диагностики Linux-систем.

    Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.
    Метки:
    Селектел 179,91
    Компания
    Поделиться публикацией

    Вакансии компании Селектел

    Комментарии 14
    • +4
      ЖИЗНЬ — 3.14
      Многозначительно..)
      • +2
        А, блин, я понял, это скрытая реклама!
        image
      • +14
        нужно выполнить от имени root-пользователя следующую команду:
        curl -s s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash


        Во-первых, от root'а sudo не используют обычно, если не предполагается запуск от другого пользователя, например «sudo -u nobody bash».
        Во-вторых, вы таким образом забиваете на безопасность. Скачали что-то там и сразу от рута запустили.
        НИКОГДА так не делайте!
        • +3
          Спасибо за замечание, внес в текст поправку.
          • +10
            Мешаете людям пополнять ботнет :-)
          • +7
            | Введем следующую команду:
            |
            | # sysdig proc.name = cat and proc.name = vi
            |
            | Она будет отслеживать всю активность программ cat и vi:

            Странный тут AND. А что тогда будет искать c OR?

            # sysdig proc.name = cat or proc.name = vi
            • +3
              Спасибо за статью.
              недавно пробовал разобраться с system-tap, но закончилось это тем что я так и не смог запустить второй пример с оф сайта, так как мне не совсем хочется загружать гигабайты debug info под конкретное ядро на продакшн. Ну и где-то час потратил только на то что бы понять почему у меня не работают простейшие примеры.

              Тут все работает и показывает действительно интересные данные.
              Интересует как это грузит систему, не вносит ли некий элемент нестабильности (загрузка лишнего модуля в ядро и тд) и можно ли это использовать на продакшне на постоянной основе в целях мониторинга?
              • +1
                Признаться, загрузка лишнего модуля в ядро меня и многих моих коллег тоже смущает. Но систему он не нагружает (разработчики сами пишут об этом на сайте продукта). Когда я исследовал возможности sysdig, никакой нестабильности замечено не было. Но для полноценного использования в продакшне инструмент, как мне кажется, еще сыроват.
              • +4
                Забаненный ValdikSS пишет:

                Разработчики называют их chisels (в русском переводе слово chisel означает «долото», «стамеска»). Для этого термина вряд ли можно найти адекватный русский эквивалент, поэтому мы решили оставить его без перевода и называть эти скрипты чизелами.

                Я их костылями обозвал, а меня забанили :(
                www.peeep.us/aa3429ef

                Инструмент отличный. Я его использовал для отслеживания действий на honeypot, и, видимо, разработчикам sysdig тоже. Очень удобно, сохраняет буквально все, что происходит с системой (даже то, что читалось и писалось в файлы и сокеты).

                В любом случае, ваша статья куда лучше моей.
                • +1
                  «Костыли», как мне кажется, вариант не очень удачный, т.к. в этом слове присутствует оценочный момент, причем пренебрежительно-негативный.
                  Я долго ломал голову над тем, как лучше по-русски передать термин chisels, но в конце концов решил оставить его без перевода: здесь как раз тот случай, когда без заимствования иностранного слова не обойтись.
                  • +2
                    Разработчики называют их chisels (в русском переводе слово chisel означает «долото», «стамеска»). Для этого термина вряд ли можно найти адекватный русский эквивалент, поэтому мы решили оставить его без перевода и называть эти скрипты чизелами.
                    Дятел же!) Это я о термине.

                    Правда, я сначала расмышлял так — что, если пройтись по схожим терминам: долото -> чекан -> stamp -> штамп?

                    Как бы там ни было, но чизел совершенно чужд русскому уху и языку, особенно чизелы, и не несет смысловой нагрузки.

                    Вы же столькими языками владеете, вы просто должны, нет, вы обязаны подобрать эквивалент! :) Шучу, конечно.
                    • +4
                      по поводу чизелей:
                      В русском (и даже еще в «советском») сельскохозяйственном языке чизелями называют особые плуги для безотвального рыхления почвы.
                      Вот так он выглядит:
                      image

                      фактически — Плуг, это и есть адекватный русский эквивалент, потому как в идеологии sysdig чизели как раз помогают перепахивать «сырые» данные.

                      а сам по себе sysdig — очень хорош, искренне благодарен вам, за то, что теперь я про него знаю.
                • +4
                  Собственно SysDig получил поддержку OpenVZ и скоро станет основным инструментом диагностики проблем с нодами. Как показали первые тесты, оверхед минимальный.
                  • +2
                    Супер инструмент! А еще в новой версии он может работать на OpenVZ ядрах :)

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

                    Самое читаемое