Продолжение статьи внедрение мониторинга часть 1
Несколько слов по работе с инцидентами
Я, как бывший эксплуататор, расскажу про алерты. Здесь есть не состыковка с нашим видением и те, что бывает у людей. И что делать, когда у нас пришла смска? То есть порядок действий на наш взгляд. Первое, на что следует обратить внимание – это правильные severity на мониторинге. К ним относят CRITICAL — уведомления по SMS/IM, WARNING — можно уведомлять на email или без уведомления, INFO — без уведомления.
Рассмотрим их более подробно. Примеры CRITICAL:
- сайт не работает (например, время ответа выросло, и пользователи начали уходить);
- ошибки бизнес-логики, приема платежей;
- пропал поток покупок.
В перечисленных случаях нельзя ничего откладывать, то есть, бросаем все и чиним! Никто никуда не уходит, пока есть проблема.
Все остальные severity созданы для того, чтобы разобраться с CRITICAL. Примеры WARNING:
- диск кончается;
- какой-то сервис недоступен, дает много ошибок или «тупит»;
- много ошибок на сетевом интерфейсе;
- сервер недоступен (это реально warn!!!);
- Swap IO процесса > 1 Mb/s.
Многие наши клиенты отключают уведомления на WARNING, поэтому они видят только особо опасные из них. Рекомендуем такой подход в работе с WARNING:
- желательно закрыть в течение дня (большинство наших клиентов, которые нам доверились, они отключили нотификацию на WARNING, поэтому у них нет так называемой «мониторинговой слепоты», и если придерживаются техники чистого мониторинга, то они спокойно чинят те пять WARNING, которые у них загорелись);
- если алерт не по делу – добавляем исключение;
- если WARNING часто загораются-погасают – это надо крутить в мониторинге.
Примеры INFO. Тут тоже спорно, так как они на самом деле у многих CRITICAL.
Disk IO — это диск где-то в полке. WARNING – это такие лампочки. Когда вы приходите чинить CRITICAL, и видите рядом два невзначай WARNING. Тут вот в базе cpu в полке. Пошел, посмотрел и все.
Действия в случае INFO:
- используем в качестве подсказок во время поиска причин CRITICAL или WARNING;
- если загораются бессмысленные алерты – добавляем исключения.
Рассмотрим общие принципы подхода к конструированию алертов.
- Первый — когда они показывают причину возникшей проблемы (идеально!).
- Второй — не нужны зависимости и автомагия.
- Третий — глазами можно быстро просмотреть 100+ алертов и выбрать подходящий.
- Четвертый — алертам, которые не помогают, можно понизить severity.
То есть все, что вам нужно делать – это подчищать ненужные алерты.
На что нужно в первую очередь обратить внимание при работе с инцидентами? Важно считать продолжительность CRITICAL (он же downtime).Если critical != downtime, то чиним severity.
Хорошо бы даунтаймы классифицировать. Это необходимо для понимания из-за чего возникла проблема. Предлагаю следующую классификацию:
- плохой релиз;
- человеколажа;
- перегруз;
- хостинг/ДЦ;
- что-то еще по вкусу.
Алгоритм при работе с инцидентами, когда пришла смска:
- тушим пожар;
- докапываемся до причины;
- классифицируем;
- заводим задачи, чтобы не повторялось то же самое;
- PROFIT через N итераций.
Когда инцидент закрылся, он должен закрыться и в системе мониторинга. Так, в Google они мониторингом не закрываются, инцидент закрывает человек. Наше мнение – инцидент должен проверить мониторинг.
Но после того, как инцидент закрыт, оказывается, что на самом деле это не так. Он ждет, пока вы докопаетесь до причины. Это нужно, чтобы проблемы не повторялись. Действия:
- смотрим, какой класс проблем доставляет больше всего проблем;
- если хостинг – переезжаем;
- если люди – автоматизируем стрёмные места, нагоняем страх на исполнителей, то есть действуем в зависимости от управленческих навыков, например, автоматизировать процессы, та как машины лажают реже;
- если релизы – нагоняем страх на QA и так далее по стеку.
По статистике за квартал мы сможем понять, что больше всего дало даунтайма и в этом направлении работать.
Выводы
- Мониторинг мы раскладываем на две задачи: «мониторинг = обнаружение проблем + поиск причины проблемы». Если вас не устраивает время, затраченное на поиск причины, настраивайте время мониторинга.
- Мониторинг — оптимизация преобладает над ручной диагностикой.
- Чем точнее мониторинг, тем быстрее становится понятна причина проблемы.
Не следует забывать и об алгоритме внедрения: сначала обеспечиваем нужную точность обнаружения, и только потом оптимизируем диагностику.
Частые вопросы и ответы на них
— Расскажите, пожалуйста, про подход к тому, как в новый сервис добавить новую машину. Обычно мы делаем это так: подключили, воткнули шаблоны стандартные, затем начинается творческий процесс, например, пытаемся убрать ложные срабатывания и т.п. Ваше мнение?
— Наш подход: с машины снимаем все. Когда добавили 10 фронтенд, то с него снимется все, что там есть. Мы зажжем алерт, добавив тайминги. Это WARNING без нотификации. Следует в течение дня добавить его и все. Но это в случае, если машина такая же, как уже имеющиеся. Если машина другая, то по ресурсам снимаем все. Этот подход очень хорошо работает, чтобы не забыть добавить метрику. Заинструментировать все наперед нельзя. До первого фокапа вы живете в неведении, а потом только понимаете, что вам нужно.
— Про пороги и нотефаи…
— В среднестатистическом проекте несколько сотен машин и пороги одинаковы для всех. Автоматические триггеры, которые на всех пользователей выкатывают по умолчанию, мы их делаем примерно общими. То есть условно в любом проекте плохо настроен автовакуум, если воркер в автовакууме в планке два часа и более, это значит, что он никогда не сделает свою работу (практически для 99% случаев). Такие общие триггеры подают исчерпывающую информацию.
— В какой момент определяется порог CRITICAL? Кто это делает?
— Вы приходите с задачей, что хотите создать порог CRITICAL для своего проекта. Пробуете его устанавливать на практике и смотрите на результаты: сколько алертов было получено неделю назад?
— Нагрузка всего этого доброго мониторинга. Наши сервера в Амазоне. Хочется понять, какова же нагрузка, если вы предлагаете снять все?
— В среднем она вообще незаметная. Но если вы парсите 50 тысяч рпс в логе, то это будут единицы процентов ядра. Мы занимаемся только мониторингом, поэтому измеряем единицы агента. Если у вас нет слота для мониторингового агента по ресурсам на сервере, значит, вы что-то делаете не так. Всегда должен быть слот.
Все клиенты, находящиеся у нас на обслуживании подключаются в нашу систему мониторинга, а для больших проектов подымаются отдельные сервера.
Если вопросы или желание доверить свои сервера, обращайтесь [email protected]