Мониторинг как процесс, или Как перестать бояться алертов и начать спать по ночам / Хабр

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

Но статья будет не про сравнение систем мониторинга или методов, а про простые практики, которые каждый из вас может применить. Про здравый смысл в применении этих практик. И про опыт ЦФТ — про те боль и проблемы, с которыми столкнулась компания, как их решала и к чему в итоге пришла. Эта история о том, как перестроить процессы внутри компании, чтобы мониторинг перестал быть стихийным и стал актуальным и управляемым.

Нормально делай — нормально будет, и Виталий Медведев, инженер по автоматизации ЦФТ, разделяет эту истину. Эта статья написана по его выступлению на конференции Saint HighLoad 2021.

Лет 7 назад в ЦФТ произошла крупная трансформация процессов. Но мониторинг не успел за изменениями, и инженеров завалило огромное количество ложных алертов. Собравшись с силами, они объявили крестовый поход, героическими усилиями всё исправили и какое-то время могли спать спокойно.

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

Для решения проблем сначала нужно было определиться с целями.

Цели

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

Какие основные проблемы при этом нужно было решить?

Проблемы

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

Много ложных оповещений. Флаппающие алерты, которые были когда-то критичными, перестали таковыми быть. Их становится много, и среди этого шума теряются уведомления с действительно высоким уровнем критичности, на которые нужно обязательно отреагировать. От этого инженеры сильно устают, это вызывает отвращение к работе. Ребята просто ждут, чтобы закончилось дежурство и этот огромный поток сообщений начал разбирать кто-нибудь другой. Это очень плохо!

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

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

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

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

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

Но почему эти проблемы проявились?

Причины

В первую очередь, в ЦФТ изменились процессы разработки и поставки. Раньше было, условно говоря, «два монолита и три хоста», а потом появились новый стек, Kubernetes и множество кластеров. После изменений процессов вырос штат разработчиков и количество команд, но ops’ы остались в том же количестве. Времени у дежурных на всё перестало хватать. Хотя задач и работы никогда меньше не станет, и нужно в любом случае откуда-то это время найти, чтобы инженеры смогли разобрать все задачи.

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

Вместе с мониторингом менялось и всё остальное: появлялись и исчезали новые сервисы, хосты, кластеры. Старого статичного состояния с несколькими известными не стало, а новое с множеством неизвестных нужно было как-то дискаверить. Все постоянно меняется и будет меняться — в ЦФТ больше не было правил, которые неизменны всегда.

Итак, проблемы были описаны, причины найдены, а цели сформулированы — осталось только всё реализовать.

Трансформация

Что касается двух первых причин, то это очень обширная тема. ЦФТ посвятил ей два доклада на весеннем HighLoad++ 2021:

• Flux, flux и в production. Доклад про инструменты, которые используются, чтобы стандартизировать поставку сервисов на продакшн и дать время отделу эксплуатации на развитие.

• 500 Dev vs 10 Ops. Этот доклад о процессе взаимодействия между командами, некая эволюция DevOps. По мотивам доклада была также статья на Хабре.

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

Время для дежурных

На тот момент в команде дежурных инженеров в ЦФТ сложилось несколько ролей. Каждый дежурный на заявках на одну неделю выходил заниматься только операционкой: простейшими инструкциями, как создать пользователя или выдать права. Это достаточно мелкие задачи, которые надо просто взять и сделать, поэтому постоянно отвлекать всех в отделе на такую работу было бы неправильно.

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

Что здесь не так? Дело было в том, что заявки хоть и были простыми, но их было много — и могло так случиться, что после очередного этапа изменений в процессах их становилось еще больше. А еще была «сезонность»: в понедельник люди запланировали, что будут делать всю неделю и к среде-четвергу начинали дружно выкатывать версии. И у дежурного в понедельник было 10 заявок, в среду уже 30, а в четверг — 50. 

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

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

ОК, тогда реорганизовали так:

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

После реорганизации дежурства осталось «самое простое» — взять стихийный мониторинг, который пять лет развивался сам собой, и привести его в порядок.

Мониторинг

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

Аналитика и отчёты

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

Пример среза за месяц

Как только это всё визуализировали в Grafana, сразу стало понятно, что буквально 3-4 алерта генерят порядка тысячи уведомлений в месяц. Что достаточно исправить только их, чтобы вместо тысячи уведомлений получить тридцать, сократив на два порядка «белый шум».

Категоризация алертов

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

Для категоризации, во-первых, выделили отдельный severity, и поменяли его у всех алертов. Этот severity был не минимальным, но близким к максимальному, то есть он приходил по большому количеству каналов, чтобы не пропустить что-то реально критичное, замаскированное под уровень info. И дальше каждую неделю дежурные распределяли эти алерты: из отчета по этому severity брали ТОП-10 и исправляли.

Через 10 недель в отчете не осталось ни одного уведомления с таким severity, а оставшиеся распределили вручную. На весь процесс ушло три месяца, и все правила были приведены в порядок с точки зрения категоризации.

Еженедельная встреча

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

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

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

Но на следующих встречах инженеры поняли, каких правил и соглашений по поводу мониторинга внутри отдела они сами хотят придерживаться, и все обсуждения стали проходить гораздо быстрее. Последняя встреча заняла 7 минут: «Это делаем так и так, а новые мониторинги вот такие. Работаем!» — и разошлись.

Очень полезно стало также обсуждать на таких встречах задачи, стоящие в работе. Так происходил обмен знаниями, потому что сложность систем в ЦФТ становилась всё больше, и один человек уже не мог знать, что происходит везде. Если срабатывал неизвестный алерт, на встрече можно было выяснить, что с ним делать, либо встретиться отдельно, если остальные об этом алерте уже знали.

Runbooks

Конечно, базы знаний, документация — это всё существует и ведётся. Но с ними есть небольшой нюанс. Чаще всего там слишком «много букв» — официальная документация продукта может выдать десятки разделов, сотни или тысячи статей, ссылок и комментариев — как найти нужную информацию? Во внутренней документации может быть всего 3 страницы информации, но в три часа ночи и этого будет слишком много.

Для лучшего понимания, что делать с алертом — внедрили Runbooks. В них кратко и просто написали, о чём уведомление. Но не описание вида: «В очереди скопилось 100 сообщений» (спасибо, капитан, я это и так понимаю из текста сообщения). Нет, там было описано: «Очередь находится в Rabbit, связана с таким-то сервисом, нужна для того и того».

Там же описали возможные причины срабатывания и что делать. Например, продюсер сошел с ума и начал генерить тысячами сообщения, или консьюмер отвалился, ничего больше не потребляет, всё там накапливается. Куда посмотреть, из-за чего могло это все сработать? Что нужно проверить, если сработало? И вообще, если сработало — то что делать? Какими командами найти, в чем проблема?

Или приходит алерт: «Через 2 часа произойдет заполнение диска и Elasticsearch перейдет в read-only». Инженер знает, что посмотреть, но может не помнить команд, а открыв Runbook, может получить их. В Runbooks не должно быть простыней, только конкретные и простые вещи. 

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

Казалось бы, простые вещи. Мы читаем о них в статьях и думаем: «Да-да!» — и никогда не делаем. Инженерам ЦФТ это наконец надоело, и они это реализовали. Это просто, но это работает.

Гарантийный срок 

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

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

Культура проведения плановых работ 

Десять лет назад плановые работы в ЦФТ проводились глубоко ночью. Всё останавливалось (в том числе и мониторинг) вручную, все быстро выполняли работы и поднимали сервисы. 

Теперь есть сотни нод и балансировщики, которые всё сами балансируют, а Kubernetes сам всё поднимает и апдейтит. И на плановых работах  нужно не забывать отключать мониторинг, чтобы 20-30 алертов не падали на голову дежурному инженеру. Хорошо, если он знает о плановых работах. А если он ничего не знает, то это будет беда для его нервной системы. Это тоже просто — вы работаете в команде, уважайте своих коллег, проводите плановые работы с отключением мониторинга.

Также редко кто руками что-то катит. Обычно это скрипты, тулзы и прочее. Но добавьте в них автоматическое отключение алертов, чтобы они сами гасились, если всё включилось — и дежурным не будут приходить ненужные уведомления.

Автоматизация

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

Результаты

В апреле 2020 года инженерам приходило 11 тысяч уведомлений — это 300 с лишним в день! По новому процессу они начали работать летом того же года, и результат был практически сразу — в три раза снизилось количество уведомлений, которые получает дежурный:

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

Бонусы

Бонусом инженеры получили, во-первых, разбор техдолга — он начал понемногу сам собой разгребаться. Во-вторых, улучшился обмен знаниями. На встречах становилось понятно, что происходит и зачем внедрялись какие-то мониторинги. Для новых сотрудников это очень полезно. В тех же Runbooks теперь есть краткие и понятные вещи. Уровень осведомленности вырос, а пресловутый bus factor уменьшился.

Появились соглашения о мониторинге внутри отдела — что инженеры хотят от мониторинга, как они вообще видят всё хозяйство, связанное с мониторингом. Например, все и так знали, что не надо использовать правила, использующие среднее или последнее значение метрики, но без соглашений они все равно проскакивали. Теперь, по соглашению, вместо них используются перцентили или формулы предсказывающие значения: «Место на диске закончится через час». А последние значения показываются на дашбордах, но не приходят дежурным. Каждый новый мониторинг теперь делается по соответствующим соглашениям.

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

Выводы

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

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

Не бойтесь объёмов и не усложняйте. Соберитесь с духом, не стройте ракет, но простыми способами шаг за шагом исправляйте ситуацию. Тем более, что вы не одни. У вас в команде есть другие люди, которых  эта ситуация тоже бесит, и они с радостью вам помогут. Без людей ничего не получится — даже если вы нарисуете красивый процесс и всё автоматизируете, без пользователей системы ничего не заработает.

Культура внутри команды – путь к успеху. Если у вас в команде с культурой здорово, то всё у вас получится. И спать вы будете как Том.

Видео выступления Виталия Медведева на конференции Saint HighLoad 2021:

В Онтико работа кипит, мы приближаемся к главному событию весны – конференции HighLoad++ Foundation. Планируйте свое участие — расписание уже на сайте. Вас ждут интересные и полезные доклады от спикеров, нетворкинг, безумство на стендах партнеров, а также крутые спецпроекты. Полный список тем и тезисов смотрите на нашем сайте.

Встречаемся 17 и 18 марта в Москве в Крокус Экспо!

Обновлятор-1с. Как настроить запуск по расписанию (v3)?

Оглавление

• Общее описание
  • Выбор пользователя
  • Выбор баз
  • Порядок запуска
• Как узнать запускался ли обновлятор по расписанию
  • Быстрая проверка
  • Детальная проверка
  • Если ничего не помогло
• Как настроить облачную систему мониторинга за запуском задач обновлятора
  • Простейший сценарий настройки HealthChecks вместе с обновлятором
  • Настройка более сложного расписания проверки
• Возможен ли запуск по расписанию других задач с другими параметрами

Общее описание

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

Потому что запуск по расписанию работает через стандартный механизм Windows, который называется «Планировщик задач».

И когда пользователь задаёт настройки расписания …

… обновлятор автоматически создаёт или удаляет нужные задачи в планировщике системы:

Чего нельзя забывать

Выбор пользователя

Пользователь, которого мы указываем для запуска задач по расписанию…

а) … должен иметь непустой пароль. Это требование безопасности Windows. Если вы столкнулись именно с этим ограничением, то самым правильным решением будет:

• либо назначить пароль текущему пользователю, под которым вы собираетесь запускать обновлятор по расписанию
• либо создать в системе отдельного пользователя с паролем, которого и прописать в расписании обновлятора

Ну а самым простым (но неправильным с точки зрения безопасности) решением этого ограничения будет отключить опцию «Разрешить использование пустых паролей только при консольном входе» в локальной политике безопасности компьютера.

б) … должен иметь права на вход в качестве пакетного задания.

Это право необходимо, если вы настраиваете выполнение задач расписания в фоновом режиме.

Чтобы дать это право пользователю:

• зайдите в локальную политику безопасности Windows
• пункт ‘Локальные политики’
• подпункт ‘Назначение прав пользователя’
• найдите параметр ‘Вход в качестве пакетного задания’ и добавьте в его значение нужного пользователя
• внимание, если у вас отсутствует пункт ‘Вход в качестве пакетного задания’ — ищите другой пункт ‘Запретить вход в качестве пакетного задания’; в этом случае нужного пользователя (или группу в которую он входит) из этого пункта нужно наоборот удалить

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

• в диалоге выбора пользователя (при сохранении расписания) установите галку ‘Запускать только при вошедшем в систему текущем пользователе’

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

Выбор баз

В операциях, запущенных по расписанию, участвуют только те базы, которые выбраны либо в общем списке баз расписания …

… либо в списке баз конкретной задачи:

При этом не важно стоит ли отметка рядом с базой в главном окне обновлятора:

Эти галки (в главном окне) предназначены только для ручного запуска операций и на запуск задач по расписанию влияния не оказывают.

Порядок запуска

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

Это означает, что если нам, к примеру, нужно настроить, чтобы в 22-00 выполнялась архивация, а сразу после её окончания обновление баз, то достаточно для архивации указать время запуска 22-00, а для обновления, например, 22-05.

Как узнать запускался ли обновлятор по расписанию

Бывает так, что расписание настроили, но что-то идёт не так. И мы вообще не уверены запускался ли обновлятор этой ночью.

Быстрая проверка

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

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

Детальная проверка

Также мы можем зайти в расписание…

… и посмотреть историю выполнения задач вместе с отчётами:

Если ничего не помогло

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

Чтобы включить журнал планировщика Windows заходим в «Расписание» и нажимаем кнопку «Открыть планировщик Windows»:

Это можно сделать также и из панели управления Windows (раздел администрирование).

Здесь находим и нажимаем пункт «Включить журнал всех заданий»:

Готово! Теперь мы сможем просматривать историю работы любой задачи в планировщике.

Например, выделим одну из задач обновлятора:

Как настроить облачную систему мониторинга за запуском задач обновлятора

Сейчас я расскажу о способе как застраховать себя от ситуации «ой, у нас оказывается уже целую неделю не архивируются (обновляются, тестируются..) базы».

Такая ситуация очень даже возможна, если мы настроили запуск архивации по расписанию, а затем:

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

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

Это, на мой взгляд, совершенно гениальная штука, которая называется healthchecks.io. У этих ребят есть и платные тарифы, но нам вполне сгодится их бесплатный тариф.

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

• Эй, HealthChecks, дай мне уникальный Url (адрес интернет ресурса).
• HealthChecks, если по этому адресу никто не будет стучаться (запрашивать) в течение такого-то периода — оповести меня об этом на такую-то почту.

Затем мы укажем этот адрес в обновляторе и он будет запрашивать его, например, в конце каждой архивации, запущенной по расписанию. И если в какой-то момент он вдруг перестанет запускаться или будет аварийно завершаться, то сервис HealthChecks оповестит нас об этом. Даже если наш сервер сгорит, его украдут и разберут на винтики…, мы первыми узнаем об этом от HealthChecks 🙂

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

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

К сожалению, сервис Healthchecks.io собирается прекратить обслуживание российских ip с 01.01.2023. К счастью, гуглятся десятки похожих сервисов, но вот какие из них действительно хороши, чтобы рекомендовать — я пока не знаю. Если начнёте чем-то пользоваться и оно понравится — пожалуйста, напишите мне на helpme1c.box@gmail. com, чтобы я мог написать об этом здесь.

Также обращаю ваше внимание на то, что исходный код сервиса Healthchecks.io идёт по открытой лицензии — вы можете поднять этот сервис на своём сервере (кстати, есть даже контейнер под Docker). Понимаю, что этот вариант подойдёт далеко не всем. Если кто-нибудь из пользователей сможет набросать хотя бы кратенькую инструкцию по развертыванию этого сервиса на своём сервере — я буду очень благодарен и размещу её (или ссылку на неё) здесь.

Альтернативы от пользователей: cronitor.io (сам пока не пробовал, но некоторые мне уже отписались, что очень годная вещь для замены Healthchecks)

Простейший сценарий настройки HealthChecks вместе с обновлятором

Пусть мы настраиваем ежедневную архивацию на сервере с именем DataServer, который принадлежит компании ООО «Ромашка»:

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

1. Переходим на сайт https://healthchecks.io/

2. Нажимаем на ссылку Log In в правом верхнем углу.

3. Регистрируемся на почту, на которую хотим получать оповещения.

3. Переходим в раздел «Checks» и нажимаем большую зелёную кнопку «Add Check».

4. Добавилась новая проверка (Check) со своим уникальным адресом (Ping Url):

5. Изменим имя этой проверки на OOO «Romashka» (DataServer, archiving). Это нужно сделать, чтобы мы понимали с чем именно связана эта проверка (архивация на сервере с именем DataServer в компании ООО «Ромашка»):

6. Укажем период проверки (архивация должна запускаться 1 раз в день, сам процесс архивации может занимать до 12 часов):

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

Дополнительный лимит в 12 часов (grace) я указал намеренно, потому что обновлятор делает запрос к системе мониторинга в конце своей работы, а время окончания может варьироваться от различных условий.

Например, если мы настраиваем обновление по расписанию на запуск в 22-00, то сегодня это обновление может закончиться в 23-00, а уже завтра (вышло много новых обновлений) будет длиться до 4 утра.

Отсюда и дополнительный запас в 12 часов, чтобы не было ложных срабатываний от HealthChecks.

Результат настройки периода будет таким:

7. Но как видите поле Last Ping пустое (Never). Оно будет обновляться по мере обращения к этому адресу обновлятором при архивации. А если обращения не будет больше чем 1 день и 12 часов, то HealthChecks забьёт тревогу и оповестит нас на почту.

8. Копируем Ping URL в настройку архивации по расписанию в обновляторе:

Вот и всё 

Ради интереса запустим созданную задачу из расписания:

Дождёмся пока она отработает, а затем заглянем на панель HealthChecks:

Работает.

А вот пример письма от HealthChecks, если задача перестала запускаться:

В общем штука очень гибкая и я её рекомендую к использованию абсолютно всем.

Настройка более сложного расписания проверки

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

А что если нам нужно настроить расписание проверки чуть сложнее? Скажем у нас есть задача, которая запускается только по рабочим дням в 21-00 и может длиться также до 12 часов.

В этом случае на этапе настройки периода переключаемся с Simple на Cron:

Здесь нужно заполнить поле Cron Expression в соответствии с которым и будет рассчитано расписание:

Синтаксис описан здесь: https://healthchecks.io/docs/cron/

Для нашей задачи (запуск в 21-00, по рабочим дням, работа в течение 12 часов) настройка будет такой:

Если у вас возникнут затруднения с настройкой расписания через Cron — пишите мне на [email protected], я помогу составить правильное выражение.

Возможен ли запуск по расписанию других задач с другими параметрами

Расписание поддерживает следующие виды задач

1. Обновление баз
2. Архивация баз
3. Проверка архивов
4. Скачивание обновлений для баз
5. Тестирование и исправление баз

Но что если нужно поставить в расписание задачу, которой ещё нет в этом списке? В этом случае:

1. Используйте возможности пакетных и onescript скриптов. При их сохранении можно указать добавление в планировщик так и вот так.
2. Используйте ключи командной строки обновлятора.

Или напишите мне на [email protected] о своей проблеме и мы вместе подумаем, как её лучше решить.

С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).

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

Управление метриками и уведомлениями об инцидентах

Управление метриками и уведомлениями об инцидентах

Предыдущий
Следующий
Для корректного отображения этого контента должен быть включен JavaScript

1. Руководство администратора Cloud Control
2. Системная инфраструктура
3. Серверы мониторинга
4. Управление метриками и уведомлениями об инцидентах

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

• Просмотр ошибок сбора метрик

• Редактирование параметров метрики и коллекции

• Редактирование конфигурации мониторинга

• Приостановка уведомлений мониторинга

• Приостановка мониторинга для обслуживания

• Завершение отключения или отключения мониторинга

Просмотр ошибок сбора метрик

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

1. Щелкните Сервер системной инфраструктуры на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Нажмите «Мониторинг», затем нажмите «Ошибки сбора метрик».

Редактирование настроек метрик и коллекций

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

1. Щелкните Сервер системной инфраструктуры на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Нажмите «Мониторинг», затем нажмите «Настройки показателей и сбора».
4. Изменить пороговые значения или расписание сбора. Если поле порога пусто, предупреждение для этой метрики отключено.
5. Нажмите значок «Изменить», чтобы открыть дополнительные настройки.

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

6. Нажмите OK, чтобы сохранить изменения.

Редактирование конфигурации мониторинга

1. Щелкните Сервер инфраструктуры системы на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Щелкните Настройка цели.
4. Щелкните Конфигурация мониторинга.

Приостановка уведомлений мониторинга

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

Вы можете отключить сервер.

1. Щелкните Сервер системной инфраструктуры на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Щелкните Управление.
4. Нажмите «Создать затемнение».
5. Введите имя для события понижения напряжения.
6. Выберите причину из меню и при необходимости добавьте комментарии.
7. Выберите параметры, чтобы определить, как будут выполняться задания и период обслуживания.
8. Нажмите «Отправить».

Приостановка мониторинга для обслуживания

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

1. Щелкните Сервер системной инфраструктуры на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Щелкните Управление.
4. Нажмите «Создать затемнение».
5. Выберите причину из меню.
6. При необходимости добавьте комментарии.
7. Нажмите «Отправить».

Завершение отключения или отключения мониторинга

Вы можете завершить отключение или отключение сервера.

1. Щелкните Сервер системной инфраструктуры на странице Все цели.
2. Щелкните имя цели, чтобы открыть домашнюю страницу.
3. Щелкните Сервер системной инфраструктуры в верхнем левом углу страницы. Щелкните Управление.
4. Щелкните «Завершить затемнение» или «Завершить затемнение».

Настройка предупреждений и уведомлений для Управляемого экземпляра (портал Azure) — Управляемый экземпляр Azure SQL

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

• Статья
• 13. 12.2022

Применимо к:
Управляемый экземпляр SQL Azure

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

Обзор

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

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

Вы можете настроить оповещение, чтобы оно выполняло следующие действия при срабатывании:

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

Вы можете настроить и получить информацию о правилах предупреждений с помощью портала Azure, PowerShell, Azure CLI или REST API Azure Monitor.

Метрики предупреждений доступны для управляемого экземпляра

Важно

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

Следующие метрики управляемого экземпляра доступны для конфигурации предупреждений:

За выбранный период времени записано

Для управляемого экземпляра выделено

Метрическая система	Описание	Единица измерения \ возможные значения
Средний процент ЦП	Средний процент использования ЦП за выбранный период времени.	0-100 (проценты)
Прочитанные байты ввода-вывода	байтов ввода-вывода прочитано за выбранный период времени.	байт
Записано байт ввода-вывода	байтов ввода-вывода.	байт
Количество запросов ввода-вывода	Количество запросов ввода-вывода за выбранный период времени.	Цифровой
Место для хранения зарезервировано	Ток макс. место для хранения, зарезервированное для управляемого экземпляра. Изменения в операции масштабирования ресурсов.	МБ (мегабайт)
Используемое место для хранения	Объем памяти, использованный за выбранный период. Изменения в зависимости от потребления хранилища базами данных и экземпляром.	МБ (мегабайт)
Число виртуальных ядер	виртуальных ядер. Изменения в операции масштабирования ресурсов.	4–80 (виртуальные ядра)

Создайте правило оповещения для метрики с помощью портала Azure

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

2. Выберите пункт меню Метрики в разделе Мониторинг.

3. В раскрывающемся меню Метрика выберите одну из метрик, для которых вы хотите настроить оповещение (в примере показано используемое пространство для хранения).

4. Используйте Агрегирование , чтобы выбрать период агрегации — среднее, минимальное или максимальное значение, достигнутое за данный период времени (Среднее, Мин. или Макс.).

5. Выберите Новое правило предупреждений .

6. В разделе Логика оповещения :

   Поле	Описание
   Порог	Выберите, должен ли порог оцениваться на основе статического значения или динамического значения. Статическое пороговое значение оценивает правило с помощью настроенного вами порогового значения. Dynamic Thresholds использует алгоритмы машинного обучения для непрерывного изучения шаблона поведения метрик и автоматического вычисления пороговых значений. Вы можете узнать больше об использовании динамических порогов для оповещений о метриках.
   Тип агрегата	Варианты типа агрегации: минимум, максимум или среднее (в период детализации агрегации)
   Оператор	Выберите оператор для сравнения значения метрики с порогом.
   Блок	Если выбранный сигнал метрики поддерживает другие единицы измерения, такие как байты, КБ, МБ и ГБ, и если вы выбрали статический порог , введите единицу измерения для логики условия.
   Пороговое значение	Если вы выбрали статический порог , введите пороговое значение для логики условия. Пороговое значение — это значение оповещения, которое будет оцениваться на основе оператора и критериев агрегирования.
   Пороговая чувствительность	Если вы выбрали динамический порог , введите уровень чувствительности. Уровень чувствительности влияет на величину отклонения от шаблона ряда метрик, необходимого для срабатывания оповещения.
   Детализация агрегации	Выберите интервал, используемый для группировки точек данных с помощью функции типа агрегации. Выберите степень агрегации (Период), которая больше, чем Частота оценки , чтобы уменьшить вероятность пропуска первого периода оценки добавленного временного ряда.
   Частота оценки	Выберите, как часто должно выполняться правило предупреждений. Выберите частоту, которая меньше, чем гранулярность агрегации, чтобы создать скользящее окно для оценки.

7. В разделе Когда оценивать :

   Поле	Описание
   Проверять каждые	Выберите, как часто правило предупреждений будет проверять выполнение условия.
   Период ретроспективного анализа	Выберите период ретроспективного анализа, т. е. период времени, на который будет выполняться ретроспективный анализ при каждой проверке данных. Например, каждую 1 минуту вы будете просматривать последние 5 минут.

   В примере, показанном на снимке экрана, используется значение 1840876 МБ, представляющее пороговое значение 1,8 ТБ. Поскольку для оператора в этом примере задано значение больше, оповещение будет создано, если потребление дискового пространства на управляемом экземпляре превысит 1,8 ТБ. Обратите внимание, что пороговое значение для метрик дискового пространства должно быть выражено в МБ.

8. Выберите Далее: Действия > внизу страницы или Действия вкладка.

9. На вкладке Действия выберите или создайте нужную группу действий. Это действие определяет, что произойдет при срабатывании оповещения (например, при отправке электронного письма или звонке вам по телефону). Если вам нужно создать новую группу действий:

   1. Выберите + Создать группу действий .

   2. Введите Имя группы действий и Отображаемое имя и выберите Регион :

      Опция	Поведение
      Глобальный	Служба групп действий решает, где хранить группу действий. Инициативная группа присутствует как минимум в двух регионах для обеспечения региональной устойчивости. Обработка действий может производиться в любом географическом регионе. Действия по голосовой связи, SMS и электронной почте, выполняемые в результате предупреждений о работоспособности службы, устойчивы к инцидентам Azure live-site-incidents.
      Региональный	Группа действий сохраняется в пределах выбранного региона. Группа действий зонально-избыточна. Обработка действий производится в пределах региона. Используйте этот параметр, если вы хотите, чтобы обработка вашей группы действий выполнялась в пределах определенной географической границы.

   3. Выберите Далее:Уведомления> внизу страницы или вкладку Уведомления .

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

      • Тип уведомления : выберите Email Azure Resource Manager Role , чтобы отправить электронное письмо пользователям, которым назначены определенные роли Azure Resource Manager на уровне подписки, или Email/SMS-сообщение/Push/Voice для отправки различных типов уведомлений. конкретным получателям.

      • Имя : введите уникальное имя для уведомления.

      • Сведения : В зависимости от выбранного типа уведомления введите адрес электронной почты, номер телефона или другую информацию.

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

   5. Если вам нужно определить список действий, которые будут запускаться при срабатывании оповещения, выберите вкладку Действия и определите действия, такие как выполнение веб-перехватчика, функции Azure или модуля Runbook, или создайте билет ITSM в вашей совместимой системе.

   6. Если вы хотите назначить пару «ключ-значение» группе действий, выберите вкладку Теги . В противном случае пропустите этот шаг. С помощью тегов вы можете классифицировать свои ресурсы Azure. Теги доступны для всех ресурсов, групп ресурсов и подписок Azure.

   7. Чтобы просмотреть настройки, выберите вкладку Review + create . На этом шаге быстро проверяются введенные вами данные, чтобы убедиться, что вы ввели всю необходимую информацию. Если есть проблемы, о них сообщается здесь. После просмотра настроек выберите Создать , чтобы создать группу действий.

10. На вкладке Сведения заполните сведения и параметры правила оповещения для своих записей и выберите тип серьезности. У вас также есть возможность использовать Пользовательские свойства для добавления собственных свойств в правило оповещения.

11. На вкладке Теги задайте все необходимые теги для ресурса правил предупреждений. В противном случае пропустите этот шаг.

12. На вкладке Review + create запустится проверка, которая сообщит вам о любых проблемах. После прохождения проверки и просмотра настроек нажмите кнопку Создать внизу страницы.

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

Проверка предупреждений

Примечание

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

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

Электронное письмо содержит имя оповещения, подробные сведения о пороге и причину срабатывания оповещения, помогая вам проверить оповещение и устранить неполадки.

• Нажмите кнопку Просмотреть на портале Azure , чтобы просмотреть оповещение, полученное по электронной почте на портале Azure.
• Выберите View Rule > , чтобы просмотреть или изменить правило генерации оповещений, вызвавшее оповещение.
• Выберите Просмотреть ресурс > , чтобы просмотреть управляемый экземпляр, для которого было активировано оповещение.

Просмотр, приостановка, активация, изменение и удаление существующих правил предупреждений

Примечание

Существующими предупреждениями необходимо управлять из меню «Предупреждения» на панели управления портала Azure. Существующие оповещения нельзя изменить из колонки ресурсов управляемого экземпляра.

Для просмотра, приостановки, активации, изменения и удаления существующих предупреждений:

1. Поиск предупреждений с помощью поиска на портале Azure. Нажмите Оповещения.

   Кроме того, вы также можете щелкнуть Оповещения на панели навигации Azure, если она настроена.

2. На панели оповещений выберите Правила оповещения .

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

Следующие шаги

• Узнайте о системе оповещений Azure Monitor, см. Обзор оповещений в Microsoft Azure
• Дополнительные сведения об оповещениях о метриках см. в статье Общие сведения о том, как работают оповещения о метриках в Azure Monitor 9.0006
• Сведения о настройке веб-перехватчика в оповещениях см. в разделе Вызов веб-перехватчика с помощью классического оповещения о метрике
• Узнайте о настройке оповещений и управлении ими с помощью PowerShell, см. Правила действий
• Сведения о настройке оповещений и управлении ими с помощью API см. в справочнике по REST API Azure Monitor

.

This entry was posted in Популярное