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

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

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

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

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

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


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

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

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

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


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

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


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

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


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


Понравился текст? Закинь трояк в копилку на хостинг и апгрейды!


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


Подписаться: RSS // Telegram