Мониторинг распределённых систем — опыт Google (перевод главы книги Google SRE)

16 января 2020, 18:02

SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. В этой статье перевод Главы 6 Monitoring Distributed Systems книги Site Reliability Engineering от Google. Этот перевод я готовил самостоятельно и полагался на собственный опыт понимания процессов мониторинга. В телеграм-канале @monitorim_it и блоге на Медиуме я публиковал также ссылку на перевод 4 главы этой же книги о целях уровня обслуживания.

Перевод по катом. Приятного чтения!

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

Определения

Единого словарного запаса используемого для обсуждения тем, связанных с мониторингом не существует. Даже в Google, приведённые ниже термины не являются общеупотребительными, но мы перечислим наиболее распространенные интерпретации.

Мониторинг

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

Мониторинг White-box

Мониторинг, основанный на показателях, отображаемых внутренними компонентами системы, включая журналы, метрики профилирования виртуальной машины Java или обработчика HTTP, которые генерируют внутреннюю статистику.

Мониторинг Black-box

Тестирование поведения приложения с точки зрения пользователя.

Dashboard (панели мониторинга)

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

Alert (уведомление)

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

Root cause (корневая причина)

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

Node and machine (нода и машина)

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

связанные друг с другом: например, сервер кеширования и веб-сервер;

не связанные сервисы на едином аппаратном обеспечении: например, репозиторий кода и мастер для системы конфигурации, такие как Puppet или Chef.

Push

Любое изменение конфигурации программного обеспечения.

Зачем нужен мониторинг

Есть несколько причин, почему приложения нужно ставить на мониторинг:

Анализ длительных трендов

Насколько велика база данных и как быстро она растёт? Как меняется ежедневное количество пользователей?

Сравнение быстродействия

Быстрее ли выполняются запросы на Acme Bucket of Bytes 2.72 в сравнении с Ajax DB 3.14? Насколько лучше кэшируются запросы после появления дополнительной ноды? Стал ли медленнее работать сайт по сравнению с прошлой неделей?

Alerting (уведомления)

Что-то сломалось и кто-то должен это починить. Или что-то скоро сломается и кто-то должен это скоро проверить.

Создание дашбордов

Дашборды должны отвечать на основные вопросы и включать что-то из "4 золотых сигналов" — задержки (latency), трафик (traffic), ошибки (errors) и величину нагрузки (saturation).

Проведение ретроспективного анализа (debugging)

Задержка обработки запроса увеличилась, а что ещё случилось примерно в это же время?

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

Мониторинг и оповещения позволяют системе рассказать, когда она сломалась, или вот-вот сломается. Когда система не может автоматически восстанавливать себя, мы хотим, чтобы оповещение анализировал человек, определил, актуальна ли проблема, устранил и определил её основную причину. Если вы не осуществляете аудит компонентов системы, вы никогда не получите оповещение просто потому, что "что-то кажется немного странным".

Нагрузка оповещениями человека — довольно дорогое использование времени сотрудника. Если сотрудник работает, оповещение прерывает рабочий процесс. Если сотрудник находится дома, оповещение прерывает личное время и, возможно, сон. Когда оповещения происходят слишком часто, сотрудники бегло их просматривают, откладывают или игнорируют входящие предупреждения. Время от времени они игнорируют настоящее оповещение, которое замаскировано шумовыми событиями. Перерывы в сервисе могут продолжаться длительное время, поскольку шумовые события мешают быстрой диагностике и устранению проблемы. Эффективные системы оповещения имеют хорошее соотношение сигнал/шум.

Определение разумных ожиданий от системы мониторинга

Настройка мониторинга комплексного приложения — сама по себе сложная инженерная задача. Даже имея значительную инфраструктуру инструментов сбора, отображения и оповещения, команда Google SRE с 10–12 членами обычно включает одного или двух человек, основное назначение которых в создании и обслуживании систем мониторинга. Это количество со временем сократилось, по мере того, как мы обобщаем и централизуем инфраструктуру мониторинга, но каждая команда SRE обычно имеет по крайней мере одного сотрудника занимающегося только мониторингом. Должны сказать, что хотя довольно интересно наблюдать за дашбордами системы мониторинга, команды SRE тщательно избегают ситуаций, которые требуют от кого-то смотреть на экран, чтобы следить за проблемами.

В целом, Google перешел на простые и быстрые системы мониторинга с оптимальными инструментами постфактум-анализа. Мы избегаем "волшебных" систем, которые пытаются прогнозировать пороговые значения или автоматически обнаруживают первопричину. Сенсоры, которые обнаруживают непредусмотренное содержимое в запросах конечных пользователей, являются единственным контрпримером; до тех пор пока эти сенсоры остаются простыми, они позволяют быстро обнаружить причины серьезных аномалий. Другие форматы использования данных мониторинга, такие как планирование мощностей или прогнозирование трафика представляют из себя более сложную задачу. Наблюдение, проводимое в течение очень долгого времени (месяцы или годы) с низкой частотой дискретизации (часы или дни), позволит вскрыть долговременную тенденцию.

Команда Google SRE работала с переменным успехом со сложными иерархиями зависимостей. Мы редко используем такие правила, как "если я узнал, что база данных стала медленно работать, получаю оповещение о замедлении базы данных, иначе получаю оповещение о медленно работающем сайте". Правила, основанные на зависимостях, обычно относятся к неизменным частям нашей системы, таким как система для фильтрации пользовательского трафика к центру обработки данных. Например, "если настроена фильтрация трафика к центру обработки данных, не предупреждайте меня о задержках обработки пользовательских запроов" — это одно общее правило для оповещений от центра обработки данных. Немногие команды в Google поддерживают сложные иерархии зависимостей, потому что наша инфраструктура имеет постоянную скорость непрерывного рефакторинга.

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

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

Симптомы против причин

Ваша система мониторинга должна отвечать на два вопроса: "что сломалось" и "почему сломалось".

"Что сломалось" говорит о симптоме, а "почему сломалось" о причине. В таблице ниже приведены примеры таких связок.

Симптом	Причина
Получение HTTP-ошибки 500 или 404	Серверы базы данных отклоняют подключения
Медленные ответы сервера	Высокая утилизация CPU или повреждение кабеля Ethernet
Пользователи в Антарктике не получают гифки с котами	Ваша CDN ненавидит ученых и кошачьих, таким образом, некоторые IP-адреса оказались в чёрном списке
Приватный контент стал доступен отовсюду	Накатывание нового релиза ПО заставило файрволл забыть все ACL и пускает всех подряд

"Что" и "почему" — одни из самых важных кирпичиков для создания хорошей системы мониторинга с максимум сигнала и минимумом шума.

Black-box против White-box

Мы сочетаем обширный White-box мониторинг со скромным Black-box мониторингом для критичных метрик. Самый простой способ сравнить Black-box с White-box — это то, что Black-box ориентирован на симптомы и представляет собой реактивный, а не проактивный мониторинг: "система прямо сейчас работает некорректно". White-box зависит от возможностей внутренней проверки систем: журналов событий или веб-серверов. Таким образом, White-box позволяет обнаруживать грядущие проблемы, неисправности, выглядящие как повторная передача запроса и т. д.

Обратите внимание, что в многослойной системе симптом в зоне ответственности одного инженера является симптомом в зоне ответственности другого инженера. Например, снизилась производительность базы данных. Медленные чтения из базы данных являются симптомом для SRE по базам данных, который их обнаруживает. Тем не менее, для SRE по фронтэнду, наблюдающего медленный веб-сайт, причиной того же медленного чтения базы данных является медленная работа базы данных. Поэтому White-box мониторинг иногда ориентирован на симптомы, а иногда на причины, в зависимости от того, насколько он обширен.

При сборе телеметрии для отладки необходим White-box мониторинг. Если веб-серверы медленно реагируют на запросы, связанные с базой данных, вам нужно знать, насколько быстро веб-сервер взаимодействует с базой данных и насколько быстро она выдаёт ответ. В противном случае, вы не сможете отличить медленный сервер базы данных от сетевой проблемы между веб-сервером и базой данных.

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

Четыре золотых сигнала

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

Задержка

Время, необходимое для обработки запроса. Важно различать задержку успешных и неудачных запросов. Например, ошибка HTTP 500, вызванная потерей соединения с базой данных или другим бэкендом может быть диагностирована очень быстро, однако, ошибка HTTP 500 может указывать на неудачный запрос. Выявление влияния ошибки 500 на общую задержку может привести к ошибочным выводам. С другой стороны, медленная ошибка даже быстрой ошибки! Поэтому важно отслеживать задержку с ошибкой, а не просто отфильтровывать ошибки.

Трафик

Количество запросов к вашей системе, измеряется в высокоуровневыми метриками системы. Для веб-службы это измерение обычно представляет количество HTTP-запросов в секунду, разделённые по характеру запросов (например, статический или динамический контент). Для системы потоковой передачи звука это измерение может быть сконцентрировано на скорости ввода-вывода сети или количестве одновременных сеансах. Для системы хранения ключ-значение такое измерение может являться транзакциями или результатами поиска в секунду.

Ошибки

Это частота неудачных запросов, которые явно (например, HTTP 500), неявно (например, HTTP 200, но в сочетании с неправильным контентом) или политикой (например, "Если вы зафиксировали ответ за одну секунду, любой односекундный является ошибкой "). Если кодов ответа протокола HTTP недостаточно для выражения всех условий сбоя, для выявления частичного отказа могут потребоваться вторичные (внутренние) протоколы. Мониторинг всех таких ошибочных запросов может оказаться неинформативным, в то время как сквозные системные тесты помогут обнаружить, что вы обрабатываете неправильный контент.

Насыщение

Метрика показывает насколько интенсивно используется ваш сервис. Это мера системного мониторинга, выявляющая ресурсы, которые наиболее ограничены (например, в системе с ограниченной памятью, показывает память, в системе с ограничениями ввода/вывода показывается количество вводов-выводов). Обратите внимание, что многие системы ухудшают производительность, прежде чем они достигают 100% использования, поэтому наличие цели использования имеет важное значение.

В сложных системах насыщение может быть дополнено измерением нагрузки более высокого уровня: может ли ваша сервис должным образом обрабатывать двойной трафик, обрабатывать только на 10% больше трафика или обрабатывать еще меньше трафика, чем в настоящее время? Для простых сервисов, у которых нет параметров, которые изменяют сложность запроса (например, "Дайте мне ничего" или "Мне нужно уникальное одно целое монотонное целое число"), которые редко меняют конфигурацию, статическое значение теста нагрузки может быть адекватным, Однако, как обсуждалось в предыдущем абзаце, большинство служб должны использовать косвенные сигналы, такие как утилизация CPU или пропускную способность сети, которые имеют известную верхнюю границу. Повышение задержки часто является основным показателем насыщения. Измерение времени отклика 99-го процентиля в небольшом окне (например, одна минута) может дать очень ранний сигнал насыщения.

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

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

Беспокойство о "хвосте" (или инструментация и производительность)

При создании системы мониторинга "с нуля" возникает соблазн разработать систему, основанную на средних значениях: средняя задержка, средняя утилизация CPU узлов или средняя заполненность баз данных. Опасность двух последних примеров очевидна: процессоры и базы данных утилизируются очень непредсказуемым образом. То же самое относится к задержке. Если вы запускаете веб-сервис со средней задержкой в 100 мс при 1000 запросах в секунду, 1% запросов может занять 5 секунд. Если пользователи зависят от нескольких таких веб-сервисов, 99-й процентиль одного бэкэнда может легко стать медианным временем ответа интерфейса.

Простейший способ разграничения между медленным средним и очень медленным "хвостом" запросов состоит в том, чтобы собирать измерения запросов, выраженные в статистике (подходящий инструмент для отображения — гистограммы), а не фактические задержки: сколько запросов обслужил сервис, которые занимали между 0 мс и 10 мс, между 10 мс и 30 мс, между 30 мс и 100 мс, между 100 мс и 300 мс и т. д. Расширение границ гистограммы приблизительно экспоненциально (с примерным коэффициентом 3) часто является простым способом визуализации распределения запросов.

Выбор подходящей степени детализации для измерений

Различные элементы системы должны измеряться с разной степенью детализации. Например:

Наблюдение за утилизацией загрузки CPU в определенный промежуток времени не покажет длительные выбросы, которые приводят к высоким задержкам.
С другой стороны, для веб-сервиса, ориентированного на не более чем 9 часов простоев в год (99,9% годового времени безотказной работы), проверка на HTTP ответ 200 более одного или двух раз в минуту будет, вероятно, излишне частой.
Точно так же проверка наличия свободного места на жестком диске для 99,9% доступности более одного раза каждые 1–2 минуты, вероятно, не нужна.

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

Измерять загрузку CPU каждую секунду.
Урезать детализацию до 5%.
Агрегировать метрики каждую минуту.

Эта стратегия позволит собирать данные с высоко гранулярностью, не испытывая высоких накладных расходов на анализ и хранение.

Как можно проще, но не проще

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

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

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

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

Правила, которые чаще всего ловят реальные инциденты, должны быть максимально простыми, предсказуемыми и надежными.
Конфигурация для сбора данных, агрегации и оповещения, которые редко выполняются (например, менее чем раз в квартал для некоторых команд SRE), должна быть удалена.
Метрики, которые собираются, но не отображаются на какой-либо предварительной панели и не используются каким-либо предупреждением, являются кандидатами на удаление.

В Google базовый сбор и агрегация показателей, в сочетании с оповещениями и дашбордами, хорошо работают как относительно автономная система (Фактически система мониторинга Google разбита на несколько подсистем, но обычно люди знают обо всех аспектах этих подсистем). Может возникнуть соблазн сочетать мониторинг с другими методами проверки сложных систем: подробное профилирование системы, отладка процесса, отслеживание деталей об исключениях или сбоях, тестирование нагрузки, сбор и анализ журналов или проверка трафика. В то время как большинство из этих вещей имеют общие черты с основным мониторингом, их смешение приведет к слишком большому количеству результатов в создаст сложную и хрупкую систему. Как и во многих других аспектах разработки программного обеспечения, поддержка различных систем с четкими, простыми, слабо связанными точками интеграции является лучшей стратегией (например, использование веб-API для извлечения сводных данных в формате, который может оставаться постоянным в течение длительного периода времени).

Связывание принципов воедино

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

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

Обнаруживает ли это правило, иначе не обнаруживаемое состояние системы, которое является срочным, призывающим к действию и неизбежно влияющим на пользователя?
Могу ли я игнорировать это предупреждение, зная, что оно доброкачественное? Когда и почему я могу игнорировать это предупреждение и как я могу избежать этого сценария?
Означает ли это оповещение, что пользователи подвергаются негативному воздействию? Существуют ли ситуации, когда пользователи не подвергаются негативному воздействию, например, из-за фильтрации трафика или при использовании тестовых систем, оповещения по которым следует отфильтровать?
Могу ли я принять меры в ответ на это оповещение? Является ли эти меры срочными или они могут ждать до утра? Можно ли безопасно автоматизировать действие? Будет ли это действие долгосрочным решением или краткосрочным обходным решением?
Некоторые люди получают несколько оповещений по этой проблеме, поэтому можно ли сократить их количество?

Эти вопросы отражают фундаментальную философию по оповещениям и системам оповещения:

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

Такой подход стирает определенные различия: если оповещение удовлетворяет предыдущим четырем условиям, не имеет значения, отправляется ли оповещение из системы White-box мониторинга или Black-Box. Этот подход также усиливает определенные различия: лучше тратить гораздо больше усилий на выявление симптомов, чем на причины; когда дело доходит до причин, беспокоиться нужно только о неизбежных причинах.

Мониторинг в долгосрочной перспективе

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

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

Bigtable SRE: история о чрезмерном оповещении

Внутренняя инфраструктура Google обычно предоставляется и измеряется с привязкой к уровню обслуживания (SLO). Много лет назад SLO службы Bigtable основывалась на средней производительности синтетической транзакции имитирующей работающего клиента. Из-за проблем в Bigtable и на более низких уровнях стека хранения данных средняя производительность была обусловлена "большим" хвостом: худшие 5% запросов часто были значительно медленнее остальных.

Уведомления по электронной почте отправлялись по мере приближения к порогу SLO, а оповещения в мессенджер отправлялись при превышении SLO. Оба типа предупреждений отправлялись достаточно часто, потребляя неприемлемые объемы инженерного времени: команда потратила значительное количество времени на разбор оповещений, чтобы найти несколько, которые действительно были актуальны. Мы часто пропускали проблему, которая на самом деле затрагивала пользователей, потому что только некоторые из оповещений были по конкретно этой проблеме. Многие из оповещений были несрочными из-за понятных проблем в инфраструктуре и отрабатывались стандартным образом, либо вообще никак не обрабатывались.

Чтобы исправить ситуацию, команда использовала трехсторонний подход: прилагая большие усилия для повышения производительности Bigtable, мы временно определили в качестве нашей цели по SLO 75-ю процентиль для задержки ответа на запрос. Мы также отключили оповещения по электронной почте, так как их было так много, что тратить время на диагностику по ним было невозможно.

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

Gmail: предсказуемые, алгоритмизируемые ответы людей

В самом начале служба Gmail была построена на модифицированной системе управления процессом Workqueue, которая была создана для пакетной обработки фрагментов поискового индекса. Workqueue был адаптирован к долгоживущим процессам и впоследствии применен к Gmail, но некоторые ошибки в непрозрачном коде планировщика оказались очень трудноизлечимыми.

В то время мониторинг Gmail был структурирован таким образом, что предупреждения срабатывали, когда индивидуальные задачи отменялись с помощью Workqueue. Этот подход был не идеален, потому что даже в то время Gmail выполнял много тысяч задач, каждая из которых предоставлялась долям процента наших пользователей. Мы очень заботились о том, чтобы пользователи Gmail пользовались хорошим пользовательским интерфейсом, но отработка такого количества оповещений была недостижима.

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

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

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

В долгосрочной перспективе

Общая тема связывает примеры Bigtable и Gmail: конкуренция между краткосрочной и долгосрочной доступностью. Часто сильное усилие может помочь хрупкой системе достичь высокой доступности, но этот путь обычно недолговечен, чреват выгоранием команды и зависимостью от небольшого количества членов этой самой героической команды. Контролируемое, краткосрочное снижения доступности часто является болезненной, но стратегически важной задачей для долгосрочной стабильности системы. Важно не рассматривать каждое оповещение изолированно, а учитывать, ведет ли общий уровень количества оповещений к здоровой, надлежащим образом доступной системе с жизнеспособной командой и благоприятным прогнозом. Мы анализируем статистику частоты оповещений (обычно выражаемых в виде инцидентов за смену, когда инцидент может состоять из нескольких связанных инцидентов) в ежеквартальных отчетах с руководством, что позволяет лицам, принимающим решения, постоянно представлять нагрузку на систему оповещений и общее состояние команды.

Заключение

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

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

Спасибо, что прочитали перевод до конца. Подписывайтесь на мой телеграм-канал о мониторинге @monitorim_it и блог на Медиуме.

habr.com