07.06.2022

Мониторинг: хуевый и охуенный

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

Мониторинг?

Мониторинг – это гораздо больше, чем просто сбор метрик и отправка алертов. Многие не понимают этого, но мониторинг – это взаимодействие людей и машин.

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

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

Люди включены в процесс мониторинга, они – часть этой системы. В больших командах возникает список дежурных на разные системы, правила эскалации. Алерты документируются, а после аварий пишутся постмортемы.

Комфорт

Система мониторинга выступает в роли интерфейса, с которым взаимодействует человек – оператор. Этому оператору должно быть максимально удобно.

Если человеку работать неудобно, то растет когнитивная нагрузка. Оператор сильнее напрягается, быстрее устает. Из-за этого вероятность ошибки растет. Удобная система снижает нагрузку на человека, максимально помогая ему работать. Он концентрируется на решение проблемы, а не на “борьбе с системой мониторинга” и не на “поиске концов у этого алерта”.

Боль и напряжение

Все это не значит, что система мониторинга должна быть совершенно естественной для человека и любое напряжение с его стороны – это плохо. Так не бывает. Даже ко всему самому удобному надо привыкнуть, чтобы оценить удобство. В процессе работы нужно обращать внимание на два больших направления:

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

И порог вхождения и когнитивную нагрузку надо снижать.

Свойства системы

Удобство не просто измерить. У системы есть свойства, на которые надо обращать внимание при оценке удобства пользования.

Точность формулировок

Любое текстовое описание должно быть конкретным. Никаких догадок, или двусмысленных фраз тут быть не должно.

Плохо:

Host unusual network throughput in (instance hostname1.cluster.dc.company.ru)

Host network interfaces are probably receiving too much data (> 100 MB/s)

Идеальный пример бесполезного и вызывающего одни вопросы текста. Необычная пропускная способность? А обычная, это какая? По каким критериям необычная? Почему хост вероятно получает слишком много данных? Какова вероятность? У нас что, есть метрика вероятности получения большого количества данных? Отдельно замечу, что количество трафика указано в мегабайтах. Так делать нельзя, трафик всегда считаем в мегабитах.

Хорошо:

Network interface rx saturation
hostname1.cluster.dc.company.ru
	eth0 140Mb/s

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

Количество и качество информации в алертах

Должно быть минимальное и достаточное количество информации. Никаких эпитетов, разных формулировок одной и той же мысли, названий системы мониторинга, версий экспортеров. Ничего лишнего.

Плохо:

Host CPU steal noisy neighbor (instance hostname1.cluster.dc.company.ru)

CPU steal is > 10%. A noisy neighbor is killing VM performances or a spot instance may be out of credit.
VALUE = 35

Первое предложение не несет вообще никакого смысла. А единственная, вероятно, полезная информация почему-то взята в скобки. Интересно, как должно выглядить сообщение с несколькими инстансами.

Дальше указано, что стилтайм превышает порог. Ну хорошо, но зачем нам это? Эта информация очевидна. Не было бы превышения порога, не было бы и алерта. Потом идет предложение с предположением о том, что какой-то шумный сосед убивает производительность, или какие-то кредиты закончились. Зачем? Что за кредиты? Человек просыпается в три часа ночи, какой вывод из этого текста он должен сделать? Ответ простой – это все нахуй не нужно.

Хорошо:

Steal time
hostname1.cluster.dc.company.ru
hostname2.cluster.dc.company.ru

Полнота документации

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

Документация на алерты должна описывать то, на какую метрику опирается этот алерт, и куда смотреть дальше, чтоб найти источник проблемы. Здесь нет необходимости давать название метрики. Нужно описать для людей: что это такое? Как оно считается? Почему алерт заведён именно такой? На что ещё надо обратить внимание при срабатывании?

В идеальном случае в доке будет последовательность действий. Если она появилась, то ее можно автоматизировать.

Плохо:

StealTime
expression: rate(node_cpu_seconds_total{mode="steal"}[5m]) * 100 > 10
severity: high
Steal time превышает установленый порог

Когда инженер открывает и читает такую документацию – он просто тратит время впустую. Ничего из этого ему не поможет в решении проблемы совсем никак.

Хорошо:

StealTime

Причина
Steal time возникает при конкуренции виртуальной машины с другими процессами на хосте-гипервизоре за процессорное время. Причины на стороне облака могут быть разные, но нашей виртуалке не хватает цпу для обработки всех данных. Подробнее описано здесь(ссылка).

Что делать
Если такая виртуальная машина одна, то ее нужно смигрировать. Для этого переходим по ссылке, выбираем хостнейм и нажимаем "запустить живую миграцию".
Если таких машин много, то, вероятно, проблема массовая, обратись к cloud ops.

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

Замечу, что конкретные действия зависят от зоны ответственности, инструментов и процессов в конкретном отделе и компании.

Скорость доступа к необходимой информации

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

Плохо: Ссылки на дашборд нет в алерте. Инженеру приходится отдельно открывать браузер, заходить в систему, искать нужный дашборд, выбирать нужные значения переменных, выбирать правильный промежуток времени. Дашборды перегружены информацией, нужно постоянно листать экран, нет возможности увидеть несколько графиков на экране. Большая часть информации на дашборде – это показатели критичных значений на текущий момент времени, без графиков. Оценить относительность изменений невозможно, как и невозможно увидеть что было пять минут назад. Нет возможности перейти с одного дашборда на другие без потери значений переменных. Инженеру приходится искать нужные дашборды, заново вводить значения переменных.

Хорошо: Ссылка из сообщения об алерте ведет прямо на дашборд, где все переменные уже переданы в uri, остается только посмотреть. На дашборде необходимый минимум информации, его легко оценить визуально. Оперативные данные представлены графиком значений ко времени. Видно не только текущее значение, но и историю на небольшой отрезок времени. При желании, можно отмасштабировать график, чтобы оценить суточные или недельные тренды. По ссылкам с дашборда можно перейти на другие дашборды со связанной или более детальной информацией.

О дашбордах

Дизайн дашбордов важен. Необходимая информация должна легко интерпретироваться. Идея такая же, как в описании алертов – описание должно быть точное, формулировки конкретные. Общее правило: при взгляде на график не должно возникать вопросов к интерпретации.

Создание хороших дашбордов занимает много времени. Дело в том, что на них важная каждая деталь. Правильно выставленные единицы измерения, короткий и конкретный заголовок, наиболее подходящий тип графика.

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

Про уровни критичности

Частая ситуация: инженеры создают несколько алертов на одну и ту же метрику, с разными уровнями критичности. Никто не думает о том, что же эти уровни критичности значат.

Ежу понятно, что чем критичней, тем важнее. Но как от этого зависит реакция на эти алерты? Какой практический смысл? Нужно ли бросать работу над алертом с критичностью “warning”, если пришел “critical”? А если это “critical” по той же метрике, то нужно работать быстрее?

Бывает так, что хотят получать какой-то алерт, просто “чтобы быть в курсе”, что что-то происходит. Для таких алертов задают уровень критичности со спокойным название вроде “info”. Это деструктивная привычка, которая приводит к частым переключениям внимания и усталости.

Раскрою тайну. Уровни критичности – это такой же инструмент для решения задачи, как и все остальное. Задача, которую он решает – это разделение алертов, которые требуют срочной реакции от тех, которые требуют не срочной реакции. И самое главное следствие отсюда: не срочные алерты не нужно отправлять людям.

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

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

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

У такого подхода есть важный плюс: пока не наступит специальный момент времени, об этих метриках можно не думать. Они не будут маячить перед глазами инженеров постоянно и у ответственного не будет страха забыть посмотреть их до отпуска.

Заключение

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

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

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