Кризисные инструменты Linux

Если у вас произошел сбой, вызванный проблемой производительности, вы не хотите терять драгоценное время только на установку инструментов, необходимых для его диагностики. Вот список «антикризисных инструментов», которые я рекомендую установить на ваши Linux-серверы по умолчанию (если они еще этого не сделали), а также имена пакетов (Ubuntu), из которых они взяты:

Упаковка	Обеспечивает	Примечания
реквизит	пс(1), vmstat(8), время безотказной работы(1), верх(1)	базовая статистика
утилита-Linux	dmesg(1), lsblk(1), lscpu(1)	системный журнал, информация об устройстве
системная статистика	iostat(1), mpstat(1), pidstat(1), sar(1)	статистика устройства
iproute2	ip(8), сс(8), nstat(8), tc(8)	предпочтительные сетевые инструменты
нумактл	пронумерован(8)	Статистика NUMA
tcpdump	tcpdump(8)	Сетевой сниффер
Linux-инструменты-общие Linux-инструменты-$(uname -r)	производительность(1), турбостат(8)	профайлер и статистика PMU
bpfcc-инструменты (скрытая копия)	opensnoop(8), execsnoop(8), runqlat(8), softirqs(8), hardirqs(8), ext4slower(8), ext4dist(8), биотоп(8), biosnoop(8), биолатентность(8), tcptop(8), tcplife(8), трассировка(8), argdist(8), funccount(8), профиль(8) и т.д.	стандартные инструменты eBPF[1]
bpftrace	bpftrace, базовые версии opensnoop(8), execsnoop(8), runqlat(8), biosnoop(8) и т. д.	сценарии eBPF[1]
трассировка-cmd	трассировка-cmd(1)	Интерфейс командной строки Ftrace
Никстат	никстат(1)	чистая статистика устройств
эттул	эттул(8)	сетевая информация об устройстве
отлично	типтоп(1)	PMU/PMC верхняя часть
идентификатор процессора	идентификатор процессора(1)	Сведения о процессоре
msr-инструменты	рдмср(8), врмср(8)	Процессор копает

(Это основано на Таблице 4.1 «Инструменты Linux Crisis» в Сисперф 2.)

Несколько более длинных примечаний: [1] bcc и bpftrace имеют множество пересекающихся инструментов: инструменты bcc более функциональны (например, параметры CLI), а инструменты bpftrace можно редактировать на лету. Но это не значит, что один из них лучше или быстрее другого: они испускают один и тот же байт-код BPF и одинаково быстры при запуске. Также обратите внимание, что bcc развивается и переносит инструменты с Python на libbpf C (с CO-RE и BTF), но мы еще не переработали пакет. В будущем «bpfcc-tools» должен быть заменен гораздо меньшим пакетом «libpf-tools», который представляет собой просто двоичные файлы инструментов.

Этот список является минимальным. На некоторых серверах есть ускорители, и вам также потребуется установить их инструменты анализа: например, на серверах с графическим процессором Intel — пакет intel-gpu-tools; на NVIDIA, nvidia-сми. Инструменты отладки, такие как gdb(1), также могут быть предварительно установлены для немедленного использования в случае кризиса.

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

Основным недостатком добавления этих пакетов является их размер на диске. В облачных экземплярах добавление мегабайт к образу базового сервера может увеличить время развертывания экземпляра на секунды или доли секунды. К счастью, пакеты, которые я перечислил, в основном довольно малы (и bcc будет становиться меньше), и их размер и время не будут стоить больших затрат. Я видел, что из-за этой проблемы с размером по умолчанию не включается отладочная информация (всего около 1 Гбайт).

Могу ли я просто установить их позже, когда это необходимо?

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

• 4:00 вечера: Тревога! Сайт вашей компании не работает. Нет, некоторые говорят, что оно все еще актуально. Это вверх? Он работает, но слишком медленно, чтобы его можно было использовать.
• 16:01: Вы смотрите на свои панели мониторинга и обнаруживаете, что группа серверных серверов ненормальна. Это высокий объем дискового ввода-вывода? Что является причиной этого?
• 16:02: вы подключаетесь по SSH к одному серверу, чтобы копнуть глубже, но для входа в систему по SSH требуется целая вечность.
• 16:03: вы получите приглашение для входа в систему и для начала введите «iostat -xz 1» для получения базовой статистики диска. Долгая пауза и, наконец, сообщение «Команда «iostat» не найдена… Попробуйте: sudo apt install sysstat». Фу. Учитывая медленную работу системы, установка этого пакета может занять несколько минут. Вы запускаете команду установки.
• 16:07: установка пакета не удалась, поскольку не удалось разрешить репозитории. Что-то не так с конфигурацией /etc/apt. Поскольку владельцы серверов сейчас находятся в чате SRE, чтобы помочь с отключением, вы спрашиваете: «А как вы устанавливаете системные пакеты?» Они отвечают: «Мы никогда этого не делаем. Мы только обновляем наше приложение». Фу. Вы находите другой сервер и копируете его рабочую конфигурацию /etc/apt.
• 16:10: Вам нужно сначала запустить «apt-get update» с фиксированной конфигурацией, но это ужасно медленно.
• 16:12: …неужели это действительно занимает так много времени??
• 16:13: apt вернул «Ошибка: время ожидания соединения истекло». Может быть, эта система слишком медленная из-за проблем с производительностью? Или он не может подключиться к репозиториям? Вы начинаете отладку сети и спрашиваете серверную команду: «Используете ли вы брандмауэр?» Они говорят, что не знают, спросите у службы сетевой безопасности.
• 16:17: Команда сетевой безопасности ответила: Да, они заблокировали любой неожиданный трафик, включая исходящие запросы HTTP/HTTPS/FTP. Гах. «Можете ли вы редактировать правила прямо сейчас?» “Это не так просто.” «А как насчет полного отключения брандмауэра?» — Э-э, в случае чрезвычайной ситуации, конечно.
• 16:20: Брандмауэр отключен. Вы снова запускаете apt-get update. Это медленно, но работает! Затем apt-get install и… ошибки разрешения. Что!? Я root, это не имеет смысла. Вы рассказываете о своей ошибке в чате SRE, и кто-то замечает: разве команда безопасности платформы не создала систему? неизменный?
• 16:24: Команда безопасности платформы сейчас находится в чате SRE и объясняет, что в некоторые части файловой системы можно производить запись, но другие, особенно для исполняемых двоичных файлов, заблокированы. Га! «Как нам это отключить?» «Вы не можете, вот в чем дело. Вам придется создавать новые образы серверов с отключенной функцией».
• 16:27: К настоящему моменту команда SRE объявила о серьезном сбое и проинформировала об этом руководство, которому нужны регулярные обновления статуса и расчетное время прибытия, когда оно будет исправлено. Статус: Пока мало что сделал.
• 16:30: вы начинаете использовать «cat /proc/diskstats» как элементарный iostat(1), но вам придется потратить время на чтение исходного кода Linux (admin-guide/iostats.rst), чтобы разобраться в этом. Это просто подтверждает, что диски заняты, о чем вы и так знали из панели мониторинга. Вам действительно нужны инструменты трассировки дисков и файловой системы, такие как biosnoop(8), но вы не можете их установить. Если только вы не сможете взломать и элементарные инструменты трассировки… Вы «cd /sys/kernel/debug/tracing» и начинаете искать документацию FTrace.
• 16:55: Наконец-то запускаются новые образы серверов со всеми записываемыми файловыми системами. Вы входите в систему – ох, это быстро – и «apt-get install sysstat». Прежде чем вы успеете запустить iostat, в чате появятся сообщения: «Веб-сайт восстановлен! Спасибо! Что вы сделали?» «Мы перезапустили серверы, но пока ничего не исправили». У вас такое ощущение, что отключение вернется ровно через 10 минут после того, как вы сегодня заснули.
• 00:50 утра: Пинг! Я знал, что это случится. Вы встаете с кровати и открываете рабочий ноутбук. Сайт не работает – его взломали – кто-то отключил брандмауэр и безопасность файловой системы.

К счастью, я не присутствовал на мероприятии в 12:50, но остальные основаны на реальном опыте. На моей предыдущей работе эта последовательность часто могла принимать другой оборот: «группа трафика» могла инициировать аварийное переключение облачного региона примерно через 15 минут, поэтому в конечном итоге я устанавливал iostat, но тогда эти системы простаивали.

Установка по умолчанию

Приведенный выше сценарий объясняет, почему в идеале желательно предварительно установить антикризисные инструменты, чтобы можно было быстро приступить к устранению производственных проблем во время простоя. Некоторые компании уже делают это, и у них есть команды по ОС, которые создают собственные образы серверов со всем необходимым. Но есть много сайтов, которые все еще используют версии Linux по умолчанию, которые учатся этому на собственном горьком опыте. Я бы порекомендовал дистрибутивам Linux добавить эти антикризисные инструменты в свои корпоративные варианты Linux, чтобы большие и малые компании могли сразу взяться за дело в случае сбоев в производительности.