RSS

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

15 Май

Для сбора и анализа информации о системе в 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() 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) brk size=0
21372 13:10:15.384949909 1 cat (8298) mmap
21374 13:10:15.384979452 1 cat (8298) access
21376 13:10:15.384999211 1 cat (8298) open
21378 13:10:15.385014374 1 cat (8298) fstat fd=3(/etc/ld.so.cache)
21380 13:10:15.385016588 1 cat (8298) mmap
21382 13:10:15.385019763 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
63177 12:14:01.493281181 3 gnome-terminal (3910) open
63205 12:14:01.493319526 3 gnome-terminal (3910) 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
open
open
open
open
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 &quot%12user.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-систем.

Источник статьи

Реклама
 

Метки:

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s