Наши партнеры

Библиотека сайта rus-linux.net

Руководство для начинающих пользователей SystemTap. Полезные сценарии SystemTap

Оригинал: SystemTap Beginners Guide
Авторы: Don Domingo, William Cohen
Дата публикации: 20 июля 2009 г.
Перевод: А.Панин
Дата перевода: 3 октября 2014 г.

Глава 5. Полезные сценарии SystemTap

В данной главе описываются некоторые сценарии SystemTap, которые вы можете использовать для мониторинга работы и исследования различных подсистем. Все эти сценарии будут доступны в директории /usr/share/systemtap/systemtap.examples/ сразу же после того, как вы установите RPM-пакет systemtap-testsuite.

5.1. Сеть

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

5.1.1. Профилирование сетевой активности

В данном разделе описывается способ профилирования сетевой активности. Сценарий nettop.stp позволяет оценить вклад каждого из процессов системы в генерацию сетевого трафика.

nettop.stp

#! /usr/bin/env stap

global ifxmit, ifrecv
global ifmerged

probe netdev.transmit
{
  ifxmit[pid(), dev_name, execname(), uid()] <<< length
}

probe netdev.receive
{
  ifrecv[pid(), dev_name, execname(), uid()] <<< length
}

function print_activity()
{
  printf("%5s %5s %-7s %8s %8s %8s %8s %-15s\n",
         "PID", "UID", "УСТР", "ОТПР_ПАК", "ПРИН_ПАК",
         "ОТПР_КБ", "ПРИН_КБ", "КОМАНДА")

foreach ([pid, dev, exec, uid] in ifrecv) {
	  ifmerged[pid, dev, exec, uid] += @count(ifrecv[pid,dev,exec,uid]);
  }
  foreach ([pid, dev, exec, uid] in ifxmit) {
	  ifmerged[pid, dev, exec, uid] += @count(ifxmit[pid,dev,exec,uid]);
  }
  foreach ([pid, dev, exec, uid] in ifmerged-) {
    n_xmit = @count(ifxmit[pid, dev, exec, uid])
    n_recv = @count(ifrecv[pid, dev, exec, uid])
    printf("%5d %5d %-7s %8d %8d %8d %8d %-15s\n",
           pid, uid, dev, n_xmit, n_recv,
           n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0,
           n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0,
           exec)
  }

print("\n")

delete ifxmit
  delete ifrecv
  delete ifmerged
}

probe timer.ms(5000), end, error
{
  print_activity()
}

Обратите внимание на то, что в рамках функции function print_activity() используются следующие выражения:

n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0
n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0

Эти выражения являются ничем иным, как сокращенными версиями условных переходов if/else. Первое выражение является сокращенной формой следующего выражения, записанного в псевдокоде:

if n_recv != 0 then
  @sum(ifrecv[pid, dev, exec, uid])/1024
else
  0

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

PID - идентификатор процесса из списка.
UID - идентификатор пользователя. Идентификатор пользователя, равный 0, соответствует пользователю root.
УСТР - идентификатор сетевого адаптера, использованного процессом для отправки/получения данных (например, eth0, eth1).
ОТПР_ПАК - количество сетевых пакетов, переданных процессом.
ПРИН_ПАК - количество сетевых пакетов, принятых процессом.
ОТПР_КБ - объем данных, переданных процессом, в килобайтах.
ПРИН_КБ - объем данных, принятых процессом, в килобайтах.

Сценарий nettop.stp выводит текущую информацию о сетевой активности через каждые 5 секунд. Вы можете изменить длительность этого периода, соответствующим образом отредактировав строку probe.timer.ms(5000). Пример 5.1, "Вариант вывода сценария nettop.stp" содержит выдержку из вывода сценария nettop.stp за 20-секундный период:

Пример 5.1, "Вариант вывода сценария nettop.stp"

[...]
  PID   UID УСТР    ОТПР_ПАК ПРИН_ПАК ОТПР_КБ ПРИН_КБ КОМАНДА
    0     0 eth0           0        5       0       0 swapper
11178     0 eth0           2        0       0       0 synergyc

PID   UID УСТР    ОТПР_ПАК ПРИН_ПАК ОТПР_КБ ПРИН_КБ КОМАНДА
 2886     4 eth0          79        0       5       0 cups-polld
11362     0 eth0           0       61       0       5 firefox
    0     0 eth0           3       32       0       3 swapper
 2886     4 lo             4        4       0       0 cups-polld
11178     0 eth0           3        0       0       0 synergyc

PID   UID УСТР    ОТПР_ПАК ПРИН_ПАК ОТПР_КБ ПРИН_КБ КОМАНДА
    0     0 eth0           0        6       0       0 swapper
 2886     4 lo             2        2       0       0 cups-polld
11178     0 eth0           3        0       0       0 synergyc
 3611     0 eth0           0        1       0       0 Xorg

PID   UID УСТР    ОТПР_ПАК ПРИН_ПАК ОТПР_КБ ПРИН_КБ КОМАНДА
    0     0 eth0           3       42       0       2 swapper
11178     0 eth0          43        1       3       0 synergyc
11362     0 eth0           0        7       0       0 firefox
 3897     0 eth0           0        1       0       0 multiload-apple
[...]

5.1.2. Трассировка вызовов функций в рамках кода с реализацией механизма сетевых сокетов

В данном разделе описывается способ трассировки вызовов функций ядра ОС, реализованных в рамках файла net/socket.c. Данное действие поможет вам более точно идентифицировать способ взаимодействия каждого из процессов с сетевым стеком на уровне ядра ОС.

socket-trace.stp

#! /usr/bin/env stap

probe kernel.function("*@net/socket.c").call {
  printf ("%s -> %s\n", thread_indent(1), ppfunc())
}
probe kernel.function("*@net/socket.c").return {
  printf ("%s <- %s\n", thread_indent(-1), ppfunc())
}

Сценарий socket-trace.stp идентичен сценарию из Примера 3.6, "thread_indent.stp", который ранее был приведен в разделе "Функции SystemTap" для иллюстрации принципа работы функции thread_indent().

Пример 5.2. Вариант вывода сценария socket-trace.stp

Пример 5.2, "Вариант вывода сценария socket-trace.stp" содержит 3-х секундную выдержку из вывода сценария socket-trace.stp. Для получения дополнительной информации о выводе этого сценария, форматирование которого осуществляется средствами функции thread_indent(), обратитесь к Примеру 3.6, "thread_indent.stp" из раздела "Функции SystemTap".

5.1.3. Мониторинг входящих соединений по протоколу TCP

В данном разделе проиллюстрирован способ мониторинга входящих соединений по протоколу TCP. Эта операция помогает при идентификации любых неавторизованных, подозрительных или по какой-либо причине нежелательных запросов доступа к сети в реальном времени.

tcp_connections.stp

В процессе исполнения сценария tcp_connections.stp будет выводиться следующая информация о любых входящих соединениях по протоколу TCP, принятых системой в реальном времени:

Текущий идентификатор пользователя (UID)
Команда, с помощью который был создан процесс, принявший соединение (КОМАНДА)
Идентификатор процесса, созданного в результате исполнения команды (PID)
Порт, использованный для соединения (ПОРТ)
IP-адрес, с которого было инициировано соединение по протоколу TCP (ИСХОДНЫЙ IP)

Пример 5.3. Вариант вывода сценария tcp_connections.stp

UID        КОМАНДА    PID   ПОРТ      ИСХОДНЫЙ IP
0             sshd   3165     22      10.64.0.227
0             sshd   3165     22      10.64.0.227

5.1.4. Мониторинг TCP-пакетов

В данном разделе проиллюстрирован способ мониторинга TCP-пакетов, принятых системой. Эта операция полезна для анализа сетевого трафика, генерируемого функционирующими в системе приложениями.

tcpdumplike.stp

В процессе исполнения сценария tcpdumplike.stp в реальном времени будет выводиться следующая информация о любых принятых системой TCP-пакетах:

Исходный и целевой IP-адреса (saddr и daddr соответственно)
Номера исходного и целевого портов (sport и dport соответственно)
Флаги пакетов

Для того, чтобы выяснить, какие флаги были использованы при отправке пакета, сценарий tcpdumplike.stp использует следующие функции:

urg - получение указания на важность данных (urgent)
ack - получение указания на необходимость подтверждения (acknowledgement)
psh - получение указания на передачу буферизованных данных приложению (push)
rst - получение указания на сброс соединения (reset)
syn - получение указания на синхронизацию номеров последовательности (synchronize)
fin - получение указания на окончание передачи (finished)

Описанные функции возвращают значения 1 или 0, указывающие на то, использует ли пакет соответствующий флаг.

Пример 5.4. Вариант вывода сценария tcpdumplike.stp

5.1.5. Мониторинг операций отбрасывания сетевых пакетов данных на уровне ядра ОС

Сетевой стек Linux может отбрасывать пакеты данных по разным причинам. Некоторые ядра Linux включают точку трассировки kernel.trace("kfree_skb"), которая позволяет достаточно просто отслеживать точку отбрасывания пакетов данных сетевым стеком. Сценарий dropwatch.stp использует конструкцию kernel.trace("kfree_skb") для трассировки функций, в которых отбрасываются пакеты данных; данный сценарий создает отчеты о функциях, в которых отбрасываются пакеты данных с интервалом продолжительностью в пять секунд.

dropwatch.stp

#! /usr/bin/env stap

############################################################
# Dropwatch.stp
# Автор: Neil Horman <nhorman@redhat.com>
# Пример сценария, повторяющего поведение утилиты dropwatch
# http://fedorahosted.org/dropwatch
############################################################

# Массив для хранения списка обнаруженных функций, отбрасывающих пакеты данных
global locations

# Обращение внимания на пользователя на активацию и деактивацию функций мониторинга
probe begin { printf("Мониторинг операций отбрасывания пакетов данных начинается\n") }
probe end { printf("Мониторинг операций отбрасывания пакетов данных заканчивается\n") }

# увеличение счетчика отброшенных пакетов данных для каждой функции, в которой они были отброшены
probe kernel.trace("kfree_skb") { locations[$location] <<< 1 }

# Вывод отчета о функциях, в которых отбрасывались пакеты данных через каждые 5 секунд
probe timer.sec(5)
{
  printf("\n")
  foreach (l in locations-) {
    printf("%d пакета(ов) данных отброшено в функции %s\n",
           @count(locations[l]), symname(l))
  }
  delete locations
}

Событие kernel.trace("kfree_skb") позволяет осуществить трассировку функций, в рамках которых отбрасываются сетевые пакеты данных. В рамках зонда для события kernel.trace("kfree_skb") может осуществляться доступ к двум аргументам: указателю на освобождающийся буфер ($skb) и адрес функции из кода ядра ОС, в которой данный буфер был освобожден ($location). Сценарий dropwatch.stp реализует возможность сохранения имени функции, полученного на основе адреса из переменной $location, тогда, когда это возможно. Информация, необходимая для сопоставления адреса из переменной $location и имени функции не доступна для используемого сценария в обычных условиях. В SystemTap 1.4 для использования дополнительной информации о соответствии функций может применяться параметр --all-modules, следовательно, для запуска сценария может использоваться следующая команда:

stap --all-modules dropwatch.stp

При работе с более старыми версиями SystemTap вы можете использовать следующую команду для эмуляции параметра --all-modules:

stap -dkernel \
`cat /proc/modules | awk 'BEGIN { ORS = " " } {print "-d"$1}'` \
dropwatch.stp

В результате 15-секундной эксплуатации сценария может быть получен вывод, аналогичный представленному в Примере 5.5, "Вариант вывода сценария dropwatch.stp". В выводе отражено количество отброшенных сетевых пакетов для каждой точки трассировки с соответствующим именем функции, либо ее адресом.

Пример 5.5. Вариант вывода сценария dropwatch.stp

При компиляции сценария на одной машине и запуске на другой машине, параметр --all-modules и директория /proc/modules не будут доступны; в этом случае функция symname будет возвращать необработанный адрес функции. Для того, чтобы сделать необработанный адрес функции, в которой отбрасываются сетевые пакеты данных, более понятным, обратитесь к файлу /boot/System.map-`uname -r`. В этом файле приводятся стартовые адреса каждой из функций ядра ОС, поэтому у вас появляется возможность сопоставления адреса из вывода сценария, представленного в Примере 5.5, "Вариант вывода сценария dropwatch.stp", с соответствующим именем функции. Рассмотрев представленный ниже фрагмент файла /boot/System.map-`uname -r`, можно заметить, что адрес функции 0xffffffff8149a8ed соответствует имени функции unix_stream_recvmsg:

[...]
ffffffff8149a420 t unix_dgram_poll
ffffffff8149a5e0 t unix_stream_recvmsg
ffffffff8149ad00 t unix_find_other
[...]

Следующий раздел : 5.2. Диск.