Котлеги, привет. Вдохновленный серией статей от Евгения Козлова про CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async, я решил написать свой цикл статей по инструментам диагностики производительности Linux с примерами.

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

Long story short — sysdig использует модуль ядра для перехвата системных вызовов и событий, что открывает нам невероятные возможности в плане диагностики. Вы буквально можете расковырять практически все что происходит у вас в системе. Можно использовать realtime‑диагностику или собрать трейс с системы за определенный период, обычно при проблемах достаточно до 5–30 секунд сбора данных.

Установка sysdig

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

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

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

Сбор эвентов системы и анализ

sysdig -w capture.scap -M 30

Конечно можно не использовать консольный гуй, а вытащить из трейса событий нужные данные. Но это обычно работает, если вы точно знаете что искать. Примеры:

# Вывести срезы которые доступны в этом трейсе (тут вы получите список срезов в различных категориях. 
# Например, bottlenecks - cамые медленные системные вызовы) 
root@server:~# sysdig -r capture.scap  -cl

# выведем top процессов утилирующих cpu
root@server:~# sysdig -r capture.scap -c topprocs_cpu

CPU%                Process             PID
--------------------------------------------------------------------------------
15.00%              redis-server        1095390
12.60%              redis-server        1095391
12.20%              redis-server        1095375

# Показать top файлов с которыми велась работа (R+W) 
root@server:~# sysdig -r capture.scap -c topfiles_bytes proc.name=redis-server

Bytes               Filename
--------------------------------------------------------------------------------
72.00M              /data/temp-27.rdb
40.00M              /data/temp-28.rdb
82.72KB             /proc/self/stat

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

Открываем консольный гуй csysdig и скармливаем ему capture.scap

csysdig -r ./capture.scap

После этого переходим в режим Views (F2) и можем нырять на столько глубоко на сколько у вас хватит фантазии. 

Перед нами открываются все тайны нашей системы: что именно передавалось установленным соединением определенного процесса. Сколько данных было передано, порты, ip адреса и т.д. Какие ошибки происходили в системе и в каких процессах. Какие процессы какие файлы писали с каким рейтом. Какие открывались каталоги, какие контейнеры работали и какие процессы были запущенные внутри, какие действия делали эти контейнеры. Какие происходили ошибки Page Faults. Где какой был латенси на файлах. Какие порты были открыты и сколько с них было передано данных. Этот список можно продолжать бесконечно. 

В следующий раз расскажу о более простых (но также очень полезных) инструментах первичной диагностики.

А на этом все - спасибо за внимание. При желании заглядывайте в тележку https://t.me/devopsbrain.