Минимальный набор пакетов для диагностики проблем, которые желательно заранее установить на серверы, чтобы не тратить время на установку дополнительных пакетов или поиск специализированных live-дистрибутивов.Установка диагностических утилит во время сбоя может превратиться в решение отдельной проблемы или потребовать много времени, учитывая то, что во время сбоя может пропадать сетевое соединение, возникнуть проблемы с DNS, наблюдаться большие потери пакетов или снижение полосы пропускания, возникать большие задержки ввода команд из-за высокой нагрузки на CPU или исчерпания памяти, дисковый раздел может быть переведён в режим только для чтения и т.п.
Список пакетов для предустановки (названия для Ubuntu) и поставляемые в них диагностические утилиты:
** procps - утилиты ps, vmstat, uptime, top
** util-linux - dmesg, lsblk, lscpu (общая статистика, информация о блочных устройствах и CPU)
** sysstat - iostat, mpstat, pidstat, sar (оценка производительности)
** iproute2 - ip, ss, nstat, tc (настройка сети и управление трафиком)
** numactl - numastat (статистика по NUMA)
** tcpdump - tcpdump (анализ трафика)
** linux-tools-common и linux-tools-$(uname -r) - perf, turbostat (профилировние и мониторинг производительности)
** bpfcc-tools (bcc) - opensnoop, execsnoop, runqlat, softirqs,
hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile (диагностика на базе eBPF)
** bpftrace - bpftrace, opensnoop, execsnoop, runqlat, biosnoop (диагностика на базе eBPF)
** trace-cmd - trace-cmd (CLI-интерфейс для ftrace)
** nicstat - nicstat (информация о сетевых устройствах)
** ethtool - ethtool (информация о сетевых устройствах)
** tiptop - tiptop (PMU/PMC top)
** cpuid - cpuid (информация о CPU)
** msr-tools - rdmsr, wrmsr (информация о CPU)sudo apt install procps util-linux sysstat iproute2 numactl tcpdump linux-tools-common linux-tools-$(uname -r) bpfcc-tools bpftrace trace-cmd nicstat ethtool tiptop cpuid msr-tools
URL: https://www.brendangregg.com/blog/2024-03-24/linux-crisis-to...
Обсуждается: http://www.opennet.ru/tips/info/3246.shtml
Набор пакетов, которые следует установить автору этого топика,и не более того.
> sudo apt installНу прям универсальное средство для _ВСЕХ_ серверов.
Возможно у ТС все сервера на ubuntu.
Кто помнит Финогенова. Похожая книжка могла бы иметь успех: для юзера обзор всех Busybox, Linuxutil и идеи использования. Смузики потонут в осадок.И как вишенка - настройка MC со своими персональными модулями на шелл поверх всего...
> И как вишенка - настройка MC со своими персональными модулями на шелл поверх всегоГлавнее всего, чтоб не "персональными модулями на поверх шелл", остальное можно принять
iproute2: Как вообще сервер без этого обходится?
Легко если обработка идет вне сетевой подсистемы Linux
Только время терять на все это ваше
> Минимальный набор пакетов для диагностики проблем, которые желательно заранееустановить на серверы, чтобы не тратить время на установку дополнительных
пакетов или поиск специализированных live-дистрибутивов.
Пфф... зачем так сложо?
Что-ж вы все такие злые!
Молодой админ открыл для себя мощные утилиты линукса и спешит поделиться новым знанием. Что в этом зазорного?
Можно подумать, что комментаторы сразу родились со знанием iproute2 и tcpdump.
Нет, это админ старой закалки открыл для себя, что куча нужных и полезных утилит теперь выпилены по умолчанию из системы и их нужно ставить отдельно.
Выпилены потому что в современном мире на фиг не нужны на большинстве серверов.Зачем вам в EC2 инстансе cpuid или numastat?
ps/vmstat/top - ок, а теперь возьмите типичный современный стейджинг или подакшен с БД в rds и всем остальным в контейнерах в EKS или другом managed kubernetes, куда/где/как вы получите хоть какие осмысленные результаты этими утилитами?
Я совершенно не против всех этих утилит. Но мир, блин, изменился. 20 лет назад было ок "сервер торомозит, зайди и глянь что там не так". Сегодня это "вчера с 5 до 7 утра по GMT у нас > 5% клиентам отдавалась 500 ошибка, и алерты по метрикам задержек, давайте выясним что это было и как сделать, чтобы больше так не было". И что вы с ps / vmstat будете смотреть вчера? А в реальном времени ни у каких разрабочиков и админов нет времени смотреть туда, есть SRE анализирующий мониторинг и алерты, которые делаются совершенно не этими утилитами. И которые позволяют понять что произошло вчера намного быстрее и точнее, чем медитация над тоннами цифр которые выдаст sar с различными ключиками или срезов atop или что там любит админ старой закалки. Может ему графики нравится смотреть и он вкатил какой-нибудь легкий cacti. Только увы к какому-нибудь pagerduty оно не прикручено, поэтому то, на что смотрит конкретно тот админ, никак не координируется с командой.
А если у нас админ старой закалки у которого локалхост в чулане (NB: я никого не пытаюсь обидеть, у меня самого 3 сервера дома в чулане), то наверное он и так знает, как это все поставить.
Напиши свою статью, аноним, с изложением своей версии того, как делать мониторинг.То есть, о том, что "мир изменился" ты прав, но во-первых, у утилит нового мира внутри те же самые top, sysstat, vmstat.
>алерты, которые делаются совершенно не этими утилитами
А чем? Куча этих самых мониторингов -- это же те же самые обвязки над олдовыми утилитами.
>EC2 инстансе, в контейнерах в EKS или другом managed kubernetes
Хм. Я бы, конечно, не против EC2, EKS, и тому подобного, но у нас airgapped система. Как мне быть?
Мир изменился потому что "вчера с 5 до 7 утра по GMT у нас > 5% клиентам отдавалась 500 ошибка, и алерты по метрикам задержек, давайте выясним что это было и как сделать, чтобы больше так не было" теперь как бы норма.
Раньше был бы звонок админу в 5:03 по GMT что Вася из Зарюпинска не может работать и Маша тоже жалуется. И чтобы исправил, иначе за что тебе деньги платят.
А сейчас да, проснувшись и сладко потянувшись можно днём покумекать чего там больше 5% клиентов два часа утром матерились.
> Мир изменился потому что "вчера с 5 до 7 утра по
> GMT у нас > 5% клиентам отдавалась 500 ошибка, и алерты
> по метрикам задержек, давайте выясним что это было и как сделать,
> чтобы больше так не было" теперь как бы норма.
> Раньше был бы звонок админу в 5:03 по GMT что Вася
> из Зарюпинска не может работать и Маша тоже жалуется. И чтобы
> исправил, иначе за что тебе деньги платят.
> А сейчас да, проснувшись и сладко потянувшись можно днём покумекать чего
> там больше 5% клиентов два часа утром матерились.Если предприятие работает вне часовой зоны ИТ отдела, то нанимают
дежурных инженеров работающих 24/7 и не долбят мозг главному инженеру,
а решают вопросы с закончившимся местом, отвалившимся коннектом,
ошибкой маршрута самостоятельно, а вот если вопрос серьезный, то
тогда уже оформляют как положено баг репорт и решают в штатном порядке
в рабочее время.
При распределенной команде кстати есть шанс что ошибку отловят и исправят
и вообще в тот же час разработчики из тойже часовой зоны.Вообще распределенка сэры давно с удаленкой...
Тут ожидание и реальность.
Ожидание - удалёнка, дежурная смена, whatever.
Реальность - половина нод завалилась, инженегра два на полставки, и те джуны, потому что архитекта задолбало лопатить за десятерых за полторы зарплаты, и он свалил, whatever.
> А сейчас да, проснувшись и сладко потянувшись можно днём покумекать чего там больше 5% клиентов два часа утром матерились.И то только покумекать, потому что индусский саппорт какого-нибудь Emc2 будет спать ещё часа 4, и только потом заявку примет.
iotop
Не совсем для сбоев, но рекомендую также ставить vnstat. Иногда очень полезно посмотреть динамику по занятости каналов. Главное ставить его заранее, чтобы статистика по трафику уже была к тому момент, когда она понядобится.
В паре с реалтаймовым мониторингом в bmon получается очень даже хорошо.И то и другое у меня ставится на все новые сервера даже несмотря на то, что в параллель по сути те же метрики экспортируются ещё и в prometheus. Однако, локально на сервере смотреть числа выходит гораздо удобнее.