🛠 Теория мониторинга, версия 2k19

Тед Дзюба — токсичный и душный говнюк среднего калибра, коих в Интернете хоть вагонами вывози(сейчас, судя по твиттеру, он ещё и в политику подался, но не в том суть), однако мысли в его голове появлялись довольно толковые. В особенности те, которые непосредственно касаются моей профессиональной деятельности. Больше всего, конечно, меня впечатлила теория мониторинга — свод правил о том, как делать не надо.

Предисловие, пожалуй, будет банальным пересказом с щепоткой отсебятины: в жизни наступил тот самый момент, когда ожидание очередной on-call смены сопровождалось нервным тиком на левом глазу, а всё, чего моему разуму хотелось от жизни, будучи растерзанным истеричной вопилкой мониторинга, — это послать работу к чертям и напиться до потери памяти.

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

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

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

SLA прежде всего

На момент написания этого текста(2019 год) среднего размера IT компании(аутсорс-галеры во внимание не принимаем, это совершенно отдельная история) уже давно выросли из монопродуктовых штанишек и представляют собой от малого до среднего размера ворох отделов, продуктов и сервисов, взаимодействующих между собой. Как полагается, вместе со взаимодействием появляются и требования.

SLA(Service Level Agreement) — это ваши щит и меч, которыми вам предстоит прикрывать свой тыл. SLA — это не способ сказать "отъебитесь, пожалуйста" при любом удобном случае, а, скорее, заявление "мы гарантируем, что будем копать вот от сих и до сих в таком-то темпе и столько-то времени, а дальше у нас пупок развяжется"(пример: мы гарантируем столько-то RPS, столько-то процентов аптайма и не более стольких-то секунд задержки вот в таких-то местах). В идеале SLA должен появляться ещё задолго до заведения всяких критических триггеров и требований чтобы работало "уже вчера"; в реальности же SLA чаще всего пишется потом и кровью и, скорее всего, не за один день, но уж всяко лучше поздно, чем когда уже вас будут доедать вместе с вашим собственным дерьмом.

В любом случае SLA хорошо помогает отделить мух от котлет и отбиваться от желающих похитить ваши серьёзно ограниченные ресурсы. Любить и обожать вас, конечно же, больше не станут за введение нормативов("нормально же общались, чё вы так сразу-то?"), зато голова будет целее и сон крепче.

Настройки мониторинга должны быть гибкими и прозрачными

Здесь разделю на три части:

Настраиваться должно всё, везде и всеми, кто в этом участвует. Каждый должен иметь возможность принимать алерты, отклонять их, перенаправлять их, создавать их вручную, писать триггеры, удалять триггеры, настраивать политику эскалации, меняться сменами с коллегами и так далее. Наверное, именно из-за этого в одной из компаний, в которых я работал ранее(не будем показывать пальцем), буйным цветом цвела дедовщина, по законам которой свежеприбывшие в команду админы становились в tier 1 эскалации до прихода свежего пушечного мяса.
Настройка мониторинга не должна ни в коем случае походить на спиритический сеанс с вызовом священного духа ручных скриптов: максимум одно или два действия, желательно в веб-интерфейсе или конфигах CI. Опять же кину камень в огород одной из предыдущих компаний: мониторинг там писался админами для админов ещё при царе Горохе; триггеры настраивались плохо документированной утилитой, которая использовала ещё хуже документированный API на перле, и всё это великолепие громоздилось на одном или двух серверах. Убиться об стену головой было проще, чем настроить триггер.
Все изменения должны отслеживаться и версионироваться. Это нужно для отслеживания контекста. Когда я вижу на графиках мониторинга какой-то определённый паттерн, я обычно открываю историю репозитория конфигов(puppet, ansible) и сопоставляю изменения с последствиями; то же самое должно работать и в обратную сторону: важно понимать, в ответ на какие изменения в коде тот или иной триггер был установлен, а также кем установлен и когда установлен. Может случиться так, что уже давно нет смысла мониторить тот или иной сервис, однако поверьте: подземные стуки даже и не подумают перестать будить вас по пустячному поводу в три часа ночи.

Сокращайте количество реактивных алертов до минимально возможного

Почти пересказ записки Теда; если коротко, то убирайте к петухам собачьим ненужные триггеры и оставляйте/настраивайте только те, которые однозначно индентифицируют неработоспособность mission-critical сервисов. Нет смысла оповещать в три часа ночи об одном из десяти упавших контейнров, если нагрузка отлично балансируется; в то же время есть смысл триггерить алерт, если среднее время ответа сервера увеличилось до некомфортных величин, пользователи могут это заметить. Также, например, не стоит ставить триггер на 15000 сообщений в очереди(beanstalkd, всякие *MQ), если, например, размер очереди иногда переваливает за указанный порог; с другой стороны, средняя скорость прохождения сообщения через очередь — это то, на что обратит внимание пользователь, скажем, при рассылке push-уведомлений.

Бороться с остервеневшим мониторингом безусловно полезно и желательно начать это делать до того, как он станет причиной ваших визитов к невропатологу.

Tue, 16 Apr 2019 08:27:47 +0200

RSS // Telegram // Статистика