Настройка мониторов в UI
Начало работы
Какими способами можно попасть на страницу конфигурирования монитора:
сверху на странице
Мониторыи слева от строки поиска расположена синяя кнопка+- это создание нового мониторана этой же странице в списке мониторов, у каждого монитора справа есть карандашик редактирования этого монитора из списка
если войти в конкретный монитор, на странице его состояния сверху справа от имени есть ещё один карандаш его редактирования со страницы
Если войти на страницу создания нового, первые две секции Общая информация и Настройка групп, скорее всего, почти целиком поместятся на одном экране. Хотя мы специально не стремились к этому, получилось удачно. Вы можете начать с любой из них, в зависмости от вашей подготовки.
Если вы пришли создавать монитор, уже достаточно хорошо разбираясь в теме, у вас уже заготовлено проверенное на странице VictoriaMetrics выражение запроса, вы знаете какие лейблы возвращается в ответе и какие из них вы будете использовать для формирования событий, то, конечно, можете идти по порядку с
Общей информациис имени монитора и шаблона описания.Но если вы не так хорошо подкованы, то рекомендуем начать работу с
Настройки групп. Дело в том, что когда вы познакомитесь с выражением, группировкой и агрегацией, вам будет легко разобраться, что от вас требуется в имени и описании.\
Все обязательные поля формы создания монитора помечены красными звёздочками. Работать с секциями можно в произвольном порядке, кнопка Сохранить не станет активна, пока всё необходимое не будет заполнено правильно.
Если при знакомстве с именем и описанием, вы захотите лучше понять что такое группировка оповещений, то вы сможете забежать даже ещё немного вперёд и почитать о ней в третьей главе Настройка оповещений.
Примечание
В интерфейсе есть поля, подготовленные к тому, чтобы вмещать в себя достаточно большие списки или строки. Описание, Запрос, Получатели оповещений, Обязательные лейблы и Исключить лейблы - все они имеют в правом нижнем углу контроль в виде треугольника, за который можно тянуть вниз и увеличивать их высоту. Это замена полос прокрутки.
1. Общая информация
Имя монитора
Обязательное поле. Имя монитора определяет какой будет текстовая часть Summary создаваемых событий.
Событие (event) имеет краткое и развёрнутое описание, Summary и Description соответственно. Имя монитора - это про Summary.
Summary события состоит из двух частей префикса и краткого текстового описания.
Свойства префикса:
он зашит в код, нигде не настраивается и имеет несколько строго фиксированных значений
он однозначно характеризует переход группы монитора в другое состояние, то есть отражает характера перехода (предупреждение, срабатывание, восстановление)
он отвечает только на вопрос
Куда?(откуда - его не касается)он позволяет использовать после себя один и тот же текст описания и при этом последний визуально приобретает разный смысл
Какое имя придумать
имя должно звучать, как сообщение о проблеме -
Мало места на диске ... на хосте ...,Высокий IOWAIT на хосте...Пример полохого имени[Warn] Процент успользования CPU...имя не должно содержать явного указания на критичность, оно должно быть нейтральным в её отношении - префикс возьмёт на себя передачу критичности. Пример полохого имени
[Warn] Критически мало места на дискепри подстановке конкретного числового значения, его место в строке нужно подбирать аккуратно. Пример плохого выбора места
[Recovered] Высокая температура в 15°C в комнате 220Ане забывайте сразу устанавливать округление выводимого числового значения, если оно есть, до нужного количества знаков
Примечание
В сочетании с префиксом [Recovered] и с зелёным цветом индикации, текст в виде сообщения о проблеме выглядит нормально и логически не конфликтует с ним. Например, даже в самом бедном случае «бесшаблонного» имени монитора вида «Высокая температура на улице», если до этого вам пришло сообщение «(Warn) Высокая температура на улице», то пришедшее следом «[Recovered] Высокая температура на улице» выглядит вполне нормально. Сообщает, что плохая ситуация с температурой на улице улучшилась. Конечно, такие голые имена мониторов на практике не применяются. Монитор создан для контроля большого количества групп одновременно и без параметризации имени тут не обойтись.
Примеры событий из имени: High temperature in the room {{index .Labels "room_number"}}
Имя монитора задаёт вид Summary всех будущих событий (без No data)
Простые имена мониторов
Пример запроса, возвращающего номера комнат с их температурами:
|
|
|
|---|---|---|
room_temperature |
220A |
26 |
Группировка: room_number
Значение этого лейбла можно адресовать в имени как {{.Group}}.
Для данного примера, с одним лейблом в качестве группировки, это эквивалентно: {{index .Labels "room_number"}}
Примеры имен и событий:
Имя монитора ( |
Пример события ( |
|---|---|
Высокая температура в комнате |
[Warn] Высокая температура в комнате 220A |
Высокая температура в комнате |
[Triggered] Высокая температура в комнате 220A, 32°C |
Высокая температура в комнате |
[Triggered] Высокая температура в комнате 220A, 32°C при пороге 30°C |
Справка:
{{.Value0}}- отбрасывает дробную часть{{.Value2}}- оставляет два знака после запятой{{.Threshold}}- подставляет значение сработавшего порога из решающего правила
Сложные имена с разделением лейблов
Пример запроса о свободном месте на диске:
|
|
|
|
|---|---|---|---|
brest.astralinux |
/run |
tmpfs |
26.353648748 |
Группировка: hostname, mountpoint
Для подобных составных имен используем отдельные лейблы:
Имя монитора ( |
Пример события ( |
|---|---|
Мало места на диске |
Мало места на диске /run на хосте brest.astralinux свободно 26.35% |
Мало места на диске |
Мало места на диске /run fs:tmpfs на хосте brest.astralinux свободно 26% |
Примечание:
{{.Host}} - сокращение для {{index .Labels "hostname"}}. Рекомендуется использовать полную форму.
Имена с агрегированием оповещений
Другой пример запроса о свободном месте на дисках:
Значение в поле Группировка:
hostname, mountpointЗначение в поле Группировка оповещений:
hostname
Пример данных:
hostname |
mountpoint |
value |
|---|---|---|
brest.astralinux |
/mnt |
34.09 |
brest.astralinux |
/opt |
16.73 |
holod.astralinux |
/info |
76.34 |
holod.astralinux |
/ |
86.65 |
Образец названия для монитора с группами оповещений:
monitor name |
event example |
|---|---|
Мало места на дисках: |
[Warn] Мало места на дисках: holod.astralinux,/info=76% holod.astralinux./=86% на хосте holod.astralinux |
Мало места на дисках: |
[Warn] Мало места на дисках: holod.astralinux,/info holod.astralinux,/ на хосте holod.astralinux |
Примечание
Имя подгруппы всегда начинается с имени надгруппы.
Вас не должно смущать, что имя хоста повторяется и в названии каждой подгруппы, это вытекает из принципа, что имя подгруппы обязательно начинается с имени надгруппы. Подробно принцип работы группировки оповещений будет описан в разделе «Настройка оповещений» В общем, здесь об этом упоминается только, чтобы вы не забыли сюда вернуться, с тем чтобы проверить правильное ли имя вы дали монитору, если уже потом решились на группировку оповещений.
Дополнительная информация
Специальные переменные:
LabelsAsString - имя метрики в формате Prometheus
Пример: node_load1{hostname="holod.local",dc="sochi"}
Group - имя группы (генерируется на основе Monitor.GroupBy)
Пример: holod.local,c:\
Примеры для разных режимов:
Без групп оповещений (метрика hostname,mountpoint):
{{.Group}}: holod.local,/opt{{.LabelsAsString}}: disk_usage{hostname=»holod.local», «mountpoint=/opt»}{{.Name}}: disk_usage
С группами оповещений (группировка по hostname):
{{.Group}}: holod.local{{.LabelsAsString}}: {hostname=»holod.local»}{{.Name}}: holod.local
Предназначение поля Summary
Поле Summary является ключевым элементом системы уведомлений:
Главное поле в таблицах и списках событий
Заголовок (Subject) для email-уведомлений
Унифицированный идентификатор для событий одной группы
Преимущества единого формата:
Быстрое восприятие Позволяет мгновенно выделять связанные события в длинных списках
Удобство обработки Одинаковый шаблон помогает оперативно распознавать:
Срабатывания мониторов
Восстановления состояний
Повторные события
Эффективная группировка Обеспечивает визуальную связность событий одной группы
Где используются разные форматы:
Элемент |
Характеристики |
Пример использования |
|---|---|---|
Summary |
Краткий, единообразный |
«Высокая температура в комнате 220A» |
Описание |
Подробное, с дополнительной информацией |
Включает: |
Рекомендации по оформлению - Best practice
Для Summary используйте краткие неизменяемые шаблоны для событий одного монитора
Для Описаний применяйте:
подстановочные переменные
ссылки на связанные объекты
инструкции по реагированию
дополнительные метрики и данные
Важно
Единообразие Summary критически важно для эффективного мониторинга и оперативного реагирования.
Описание - Шаблонизированное развёрнутое описание Description
Можно ли совсем не заполнить Description? Можно, оно не обязательно. Тогда монитор в будущее событие просто подставит содержимое Summary в качестве Description. Пользы от такого описания будет мало, но для отладки группировок и порогов вполне подойдёт и такой вариант. Хорошо продуманное и информативное описание можно будет добавить на завершающем этапе разработки монитора.
Описание использует тот же самый синтаксис подстановок, который обсуждался в разделе имени, но, поскольку он создан для конкретного толкового рассказа о произошедшем, в нём смогут быть свои кейсы для каждого случая. Всё что написано вне блоков условий будет представлено в описании любого срабатывания и восстановления.
Синтаксис условий для разных описаний в зависимости от характера события
Приведём два примера заполнения поля Описание кодом для шаблонизатора. Без использования группировки оповещений и с ней
Вариант без группировки оповещений
Имя монитора: Мало места на диске {{index .Labels "mountpoint"}} на хосте {{.Host}} свободно {{.Value0}}%
Группировка: hostname, mountpoint
Группировка оповещений: (пусто)
{{ if .IsAlert}}<p> Критичная ситуация с оставшимся свободным местом на на диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}% при пороге на ALERT {{.Threshold}}%</p>{{end}}
{{ if .IsAlertRecovery}}<p> Разрешилась бывшая критичной ситуация с местом на диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}% при пороге на Recovery из АLERT {{.Threshold}}%</p>{{end}}
{{ if .IsAlertToWarning}}<p> Снизилась до Warning критичная ситуация с местом на диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}% при пороге {{.Threshold}}%</p>{{end}}
{{ if .IsWarning}}<p> Тревожная ситуация с местом на диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}% при пороге {{.Threshold}}%</p>{{end}}
{{ if .IsWarningRecovery}}<p> Разрешилась тревожная ситуация с местом на диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}% при пороге {{.Threshold}}% </p>{{end}}
{{ if .IsNoData}}<p> Прекратилось поступление актуальных данных о диске {{index .Labels "mountpoint"}} хоста {{.Host}} </p>{{end}}
{{ if .IsNoDataRecovery}}<p> Возобновилось поступление данных о диске {{index .Labels "mountpoint"}} хоста {{.Host}}, занято {{.Value}}%</p>{{end}}
<hr>
<p>Ссылка на монитор:
<a href="http://monitoring.example.org//monitoring/monitors/{{.ID}}">
http://monitoring.example.org//monitoring/monitors/{{.ID}}
</a>
</p>
<p>Ссылка на группу метрик монитора:
<a href="http://monitoring.example.org/monitoring/monitors/{{.ID}}?group={{.MetricID}}">
http://monitoring.example.org//monitoring/monitors/{{.ID}}?group={{.MetricID}}
</a>
</p>
<p>Описание путей решения проблемы в конфлюэнс: <a href="http://example.org">http://example.org</a></p>
Вариант с группировкой оповещений
Имя монитора: Мало места на дисках: {{range .Subgroups}} {{.Name}}={{.Value0}}%{{end}} на хосте {{.Name}}
Группировка: hostname, mountpoint
Группировка оповещений: hostname
<h1>
{{ if .IsAlert}} На хосте {{.Name}} имеются диски с критически малым свободным местом {{end}}
{{ if .IsAlertRecovery}} На хосте {{.Name}} разрешилась ситуация с наличием критически занятых дисков. На всех дисках достаточно свободного места {{end}}
{{ if .IsAlertToWarning}} На хосте {{.Name}} больше нет критически загруженных дисков, но ещё остаются тревожно занятые {{end}}
{{ if .IsWarning}} На хосте {{.Name}} высокая загрузка процессора! {{end}}
{{ if .IsWarningRecovery}} На хосте {{.Name}} имеются диски, на которых становится мало свободного места {{end}}
{{ if .IsNoData}} На хосте {{.Name}} имеются диски, о которых перестали поступать данные о состоянии {{end}}
{{ if .IsNoDataRecovery}} На хосте {{.Name}} разрешилась ситуация с непоступлением данных от отдельных дисков. Все диски под контролем и на них достаточно свободного места {{end}}
</h1>
<ul>
{{range .Subgroups}}<li>{{.Name}} = {{.Value}}</li>
{{end}}
</ul>
<hr>
<h2>Статистика</h2>
<p>Группы в состоянии Сritical: {{.SubgroupsInCritical}}</p>
<p>Группы в состоянии Warning: {{.SubgroupsInWarning}}</p>
<p>Группы в состоянии NoData: {{.SubgroupsInNoData}}</p>
<p>Группы в состоянии OK: {{.SubgroupsInOK}}</p>
<p>Ссылка на монитор:
<a href="http://monitoring.example.org//monitoring/monitors/{{.ID}}">
http://monitoring.example.org//monitoring/monitors/{{.ID}}
</a>
</p>
<p>Ссылка на группу метрик монитора:
<a href="http://monitoring.example.org//monitoring/monitors/{{.ID}}?group={{.MetricID}}">
http://monitoring.example.org//monitoring/monitors/{{.ID}}?group={{.MetricID}}
</a>
</p>
<p>Описание путей решения проблемы в конфлюэнс: <a href="http://example.org">http://example.org</a></p>
2. Настройки групп
В этой секции нам придется дать ответ на главный вопрос - что будет считаться логической сущностью, выводимой нам как «объект мониторинга», а в соответствии с нашей терминологией - группой монитора.
Второй, не менее важный вопрос, какой смысл будет нести числовое значение, которое будет возвращаться монитору выражением (запрос/query) и по которому он будет оценивать состояние каждой группы.
Запрос - Query
Astra Monitoring использует ставший стандартом де-факто язык запросов Prometheus PromQL и его расширение от VictoriaMetrics MetricsQL. С примерами выражений на этом языке вы можете ознакомиться прямо в Admin интерфейсе АМ в готовых мониторах. В сообществе сгенерирована всеохватывающая база знаний по технологии экспортеров Prometheus и готовых запросов к данным, собираемым ими.
В MetricsQL есть несколько типов функций, но для понимания запроса и группировки достаточно знать чем отличаются Rollup functions и Aggregate functions.
Rollup functions - функции агрегации значений по времени - всех замеров (экземпляров данных) каждой группы за указвнный период времени в прошлом. Чаще всего это скользящее временное окно. Примеры:
rate(series_selector[d])для counters иavg_over_time(series_selector[d])для guages. Использование агрегации по времени широко используется в выражениях для мониторинга Документация Rollup functionsAggregate functions - агрегируют или укрупняют до выбранных сочетаний лейблов - по сути до групп и их вычисленных значений. Примеры:
avg(q) by (group_labels),count_over_time(q) by (group_labels).
Документация VictoriaMetrics Aggregate
Rollup функции, где требуется их использование, вводят в состав Запроса, то есть их выполнение отдается VictoriaMetrics, она делает всю необходимую математику. Например, среднее значение за последние 10 минут и для кадого уникального сочетания леблов вернёт только одно число.
Важно
Event Processing AM самостоятельно не делает агрегации по времени. Это делается в запросе. Поэтому необходимо протестировать запрос перед попыткой вставить его в монитор и убедиться, что он возвращает Instant vector - исключительно одно числовое значение для каждого ряда.
А вот к агрегирующим, группирующими функциям, например средняя загрузка CPU по всем ядрам процессора, в АМ противоположное отношение. Мы рекомендуем, везде где это возможно и оправдано, по максимуму исключать групповую агрегацию из запроса и полагаться на встроенный в АМ механизм агрегации в группы.
Важно
Агрегация в группы по сочетанию лейблов, где это возможно, должна делаться не в выражении, а на стороне Event Processing и настраиваться в мониторе
Далее в описании про Группировку будет рассказано о том, что можно сочетать эти группировки и делать их и в выражении, и в мониторе.
Вот несколько взятых наугад примеров выражений поля Запрос.
(100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100))
share_eq_over_time(systemd_unit_state_id{name=~"apache2.service|rabbitmq-server.service|postgresql@.*.service", product="ald-pro", component="repositoring"}[5m], 1) * 100
((node_filesystem_avail_bytes{device!~"rootfs",mountpoint!~"/etc/hostname",mountpoint!~"/etc/resolv.conf",mountpoint!~"/etc/hosts"} * 100) / node_filesystem_size_bytes{device!~"rootfs",mountpoint!~"/etc/hostname",mountpoint!~"/etc/resolv.conf",mountpoint!~"/etc/hosts"} and ON (instance, device, mountpoint) node_filesystem_readonly == 0) * on(instance, hostname, job, group) group_left (nodename) node_uname_info
Обратите внимание, что первое и третье выражение не используют Rollup functions, а второе использует - [5m].
Последнее большое выражение, а это и есть «поставщик» данных для наших примеров про имена, возвращает процент занятого места на точках монтирования хостов (условно можно считать дисках), правда набор лейблов здесь сокращён до достаточного для объяснения объёма. Для краткости будем именовать его used_space
Пример возвращаемого выражением массива без агрегирования
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
aquilla01 |
nagatinskaya |
prod |
dc02.local |
/dev/mapper/vg0-root |
ext4 |
36.665054 |
aquilla29 |
ostankino |
test |
dc03.local |
/dev/mapper/vg0-home |
ext4 |
39.737389 |
aquilla01 |
nagatinskaya |
prod |
dc02.local |
/run/tmpfs |
tmpfs |
11.838383 |
dev |
ostankino |
prod |
dc05.local |
/opt |
ext4 |
87.949494 |
Примечание
Мы помним, что в ответе на запрос все строки имеют уникальные сочетания значений лейблов. Двух одинаковых быть не может
Группировка
Почему не использовать агрегирование в группы только в выражении? Дело в том, что, допустим, вы используете функцию avg(q) by (group_labels), тогда вы должны поимённо перечислить все лейблы, которые представляют для вас интерес и соответственно должны присутствовать в ответе.
Если дать запрос avg(used_space) by (hostname), то получим вот такой скудный ответ с одним лейблом
|
|
|---|---|
dc02.local |
36.665054 |
dc03.local |
39.737389 |
dc02.local |
11.838383 |
dc05.local |
87.949494 |
Другими словами, в этом случае мы незаслуженно отбрасываем все лейблы, кроме перечисленных в by(***), и что обидно, и все те, которые никак не конфликтуют (не требуют агрегации, не дублируют строки) с применённой группировкой. А если в будущем на уровне агента мы добавим новый лейбл, то он никогда не появится в ответе, пока мы не добавим его и в выражение. Это приводит к трудностям в поддержке решения, всегда нужно заботиться о «прописке» в выражении всех новых, полезных лейблов.
АМ берёт функцию агрегации груп в свои руки и это решает проблему наилучшим образом.
Алгоритм работы группировки Event Processing АМ
берутся за основу все перечисленные в
Группировкалейблыесли вернулась только одна строка, то все без исключения её лейблы идут в ответ
если вернулось несколько строк для заданной комбинации (группообразующих) лейблов, то
все лейблы, имеющие одинаковые значения во всех строках передаются в ответ со своими значениями
если в комбинации есть разные значения каких-то лейблов (конфликтуют), таки лейблы отбрасываются и их не будет в ответе
Таким образом, мы не теряем никаких полезных лейблов, в том числе и будущих.
Важно
Принудительное Агрегирование значений в группы - это основополагающая, принципиальная функция Event Processing АМ. Какое бы выражение вы не поместили в поле запрос, вы начнёте с того, что получите одну группу с именем Entire infrastructure и одним числовым значением ей соответствующему. Не агрегировать совсем не получится.
Теперь главное, какие лейблы выбрать для группировки. Итак, когда вы ещё ничего не делали, как сказано поле Группировка предзаполнено Entire Infrastructure, но как только вы туда встанете, вам будут предложены все лейблы, которые присутствуют во всех строках ответа на запрос. То есть те, которые имеют право быть выбранными как группообразующие.
Важно! Выбираем от того главного уровня, под которым могут быть одинаковые имена лейблов, которые мы хотим иметь в имени группы. Понимая иерархию именования лейблов и возможные наложения пространств значений имён, это нетрудно.
Примеры
hostnameотлично подходит для экспортера утилизации CPU, который пишет по каждому ядру отдельно.hostnamemountpointмы же хотим знать на каком именно диске кончается местоenvironmenthostnamemountpoint- если у нас несколько окружений и в них есть хосты с одинаковыми именами, перехлёстывающиеся пространства имён или IP адресов (overlapping IP ranges)
Вот другой пример. Надуманный, но наглядный.
У вас есть несколько полщадок по районам города site в них есть именованные залы datacenters а в них есть система снятия показаний температуры с множества датчиков sensor_id, расставленных по ЦОД. Все показания пишутся в TSDB по каждому сенсору - свой ряд.
Как мы рассуждаем. Мне неинтересно получать отдельные оповещения персонально от имени сенсоров, я вообще не хочу их отображать по отдельности в АМ. Здесь важна установка «я не хочу про них знать». Но я хочу знать о цодах как о целых объектах в смысле температуры в них. Тогда я делаю выражение с группировкой site datacenter. На следующем шаге выберу max и как только хоть один сенсор перегреется, я получу событие по поводу наличия факта перегрева без указания какой сенсор. То есть такой группировкой в ответе не будет id сенсора и включить его в Summary не получится. А вот о том случае, когда я не хочу отрисовывать тысячу сенсоров на главной странице монитора и уж тем более не хочу получать по каждому в отдельности оповещения, но при этом в оповещении про перегрев в ЦОД хочу данные конкретного горячего сенсора, то решение есть. Об этом рассказано в секции Настройка оповещений - Группировка оповещений
Примечание
Если в процессе развития у вас появятся более крупные группообразующие лейблы - появятся перехлёстывающиеся именные пространства - то нужно не забывать включить их в группировку монитора. Иначе вы автоматически станете получать «среднюю температуру по больнице».
Агрегация
Здесь совсем просто. Вы вибираете что делать при агрегации. avg(default), max, min, sum, count. Разумеется, никакого none здесь быть не может в принципе.
Период обновления монитора
Интервал времени с окончания предыдущей проверки и инициации новой. Например 1m 10m 1h
Шаг
У этой настройки два предназанчения
с таким шагом отрисовывается справочный график
это реальная величина
stepв запросе, если выражение не использует Rollup, то есть оно Instant vector запрос, step позволяет установить, что считать отсутствием данных.
Для выражений с Rollup более 5m, эта настрока практически ни на что не влияет
Примечание
Предустановленный шаг 5 минут подходит для большинства ситуаций и можно его оставить как есть
назначение и принцип работы графика
Это график-помощник. Вам для подсказки, чтобы дать представление, что вы правильно распорядились запросом и группировкой
График имеет следующий режим, зашитый в него жестко
за последний час
не более 10 групп в случайном порядке (как вернула VictoriaMetrics)
Позволяет увидеть:
что правильно задана группировка и что имена групп в таком виде вас устраивают
как ведут себя значения, чтобы потом при настройке правил, приблизительно знать какие числа вписывать в пороги
3. Настройки оповещений
Это в целом необязательная секция. Что будет если здесь ничего не заполнить? Просто никаких оповещений отправляться не будет. Но тут есть очень важный элемент, который, если настроить, изменит не только смысл/характер оповещений, но в корне изменит отображение состояния монитора и наложит новые требования на формат имени и описания монитора. Сразу о нём.
Группировка оповещений
Примечание
При фокусе на этом поле на выбор предлагаются только лейблы, которые установлены в поле Группировка. И если их несколько, а при одном эта агрегация не имеет смысла, то выбирать нужно от самого крупного к более мелкому.
В приведённом выше примере рассказывалось про температурные датчики в ЦОДах, где мы остановились на группировке site datacenter и отреклись от sensor_id, потеряв адресность где именно в ЦОД перегрев.
При этом, вопрос по сохранение информации про сенсор и про отношение к группе (объекту) как к ЦОД в целом мы оставили до этого торжественного момента.
Так вот, если выбрать в группировке все лейблы site datacenter sensor_id
а в группировке оповещений указать site и datacenter, то мы получим следующее, новое поведение системы в целом.
Что будет нового?
У нас появится новая агрегированная сущность
Надгруппа, берущая на себя роль группы в плане инициации событий и оповещений. По этой причине она и продолжит называтьсяГруппой, но нести будет другой смысл. Надгруппы будут отображаться на главной странице монитора вместе со статистикой состояний своих подгрупп - сами подгруппы уйдут в интерфейсе этожом ниже.Оригинальные, изначальные группы теперь станут
Подгруппамисвоей Группы, они будут отображаться если в надгруппу войти
Как изменится поведение оригинальных групп?
По сути они никуда не исчезают, они остаются объектами мониторинга с той точки зрения, что данные с них по-прежнему контроллируются и оценивается их состояние, но важно, что по ним больше не создаются события и раз нет событий, то по поводу них нет и оповещений. Но, помним, у них есть состояние и значение. Их группа знает эти состояния и значения. И полосы в диаграмме по каждой из них рисуются на странице подгрупп.
Как определяет своё состояние такая новая агрегированная Группа и имеет ли она Value?
Состояние группы определяется по максимальной критичности среди её подгрупп. По приоритету в следующем порядке: Crit, Warn, No data, OK. Сколько каких не важно - будет одна красная и 10 желтых, группа будет красная. Значения как такового у неё нет, но есть состояние и знание статистики своих подгрупп.
Создаётся ли событие при смене состава подгрупп, задающих текущую критичность?
Нет, события не будет. И в этом смысл агрегации оповещений. Один дополнительный пришёл, один ушёл - не важно. При этом, судить о том, что «количество влиятельных игроков» изменилось мы всё таки сможем на странице монитора по статисктике групп и детально на странице подруппы.
Сколько уровней подгрупп можно сделать?
Только два - одна надгруппа может включать несколько подгрупп, а у подгрупп не может быть своих подгрупп в принципе. Устанавливая значение Группировка оповещений из группобразующих лейблов из настройки Группировка, мы как бы задаём линию раздела - где группа генерирующая события и оповещения, а где подгруппы, имеющие только состояния, значения и влияние на группу. Далее на примерах это будет показано понятнее. Таким образом мы разрезаем группировку на две части и переподключаем механизм оповещений к получившейся первой (логической, искусственной) части - к надгруппе.
Изменятся ли мена подгрупп?
Нет, имена подгрупп остаются в неизменном полном виде, то есть включают в себя и начинаются именем группы.
Примеры
Одно правило >= 24 Warning, >= 26 Critical
|
|
|
|
|---|---|---|---|
Варшавское |
Главный |
AB898 |
23.3 |
Варшавское |
Главный |
GB776 |
22.5 |
Варшавское |
Резервный |
AB898 |
25.3 |
Варшавское |
Резервный |
GB776 |
21.3 |
Огородный |
Главный |
AA2222 |
26.3 |
Огородный |
Главный |
BB4444 |
24.1 |
Огородный |
Резервный |
AB111 |
22.8 |
Огородный |
Резервный |
AA8888 |
- |
Усады |
Основной |
JK332 |
25.2 |
Усады |
Основной |
BF768 |
- |
Примечание
Прочерк в поле значения температуры сенсора поставлен для наглядности. На самом деле, если нет данных от сенсора, этой строки просто не будет в ответе на запрос. Однако, монитор отслеживает эту ситуацию и, как увидите дальше, знает его текущее состояние как No data.
Вариант 1 Группой и фокусом внимания будет каждый ЦОД
|
Основная |
|---|---|
site, datacenter |
site, datacenter, sensor_id |
|
|
|
|
|
|
|---|---|---|---|---|---|
Варшавское,Главный |
OK |
- |
Варшавское,Главный,AB898 |
OK |
23.3 |
Варшавское,Главный, GB776 |
OK |
22.5 |
|||
Варшавское,Резервный |
Warn |
- |
Варшавское,Резервный,AB398 |
Warn |
25.3 |
Варшавское,Резервный,GB793 |
OK |
21.3 |
|||
Огородный,Главный |
Crit |
- |
Огородный,Главный,AA2222 |
Crit |
26.3 |
Огородный,Главный,BB4444 |
Warn |
24.1 |
|||
Огородный,Резервный |
No data |
- |
Огородный,Резервный,AB111 |
OK |
22.8 |
Огородный,Резервный,AA888 |
No data |
- |
|||
Усады,Основной |
Warn |
- |
Усады,Основной,JK332 |
Warn |
25.2 |
Усады,Основной,BF768 |
No data |
- |
Имя монитора
Высокая температура в ЦОД {{.Group}} по сенсорам {{range .Subgroups}} {{.Name}}={{.Value0}}°C{{end}}
Примеры Summary событий для имени монитора
[Triggered] Высокая температура в Огородный,Главный сенсоры Огородный,Главный,АА2222=26.3°C
Ситуация, когда надгруппа Огородный,Главный из исходного Crit состояния обусловленного совокупным влиянием сенсоров - A2222:Crit,B444 и A9::Warn, A12:OK, из-за охлаждения зоны сенсора А2222 до Warn вся преходит/опускается до Warn.
[Warn] Высокая температура в Огородный,Главный сенсоры Огородный,Главный,АА2222=25.8°C, Огородный,Главный,B4444=24.1,Огородный,Главный,A9=24,3°C
Примечание
Детально настроив шаблон описания для случая перехода isAlertToWarning мы получим информацию, что это улучшение ситуации, нежели её ухудшение
Вариант 2 Группой и фокусом внимания будет район, площадка - site
|
Основная |
|---|---|
site |
site, datacenter, sensor_id |
|
|
|
|
|
|
|---|---|---|---|---|---|
Варшавское |
Warn |
- |
Варшавское,Главный,AB898 |
OK |
23.3 |
Варшавское,Главный, GB776 |
OK |
22.5 |
|||
Варшавское,Резервный,AB398 |
Warn |
25.3 |
|||
Варшавское,Резервный,GB793 |
OK |
21.3 |
|||
Огородный |
Crit |
- |
Огородный,Главный,AA2222 |
Crit |
26.3 |
Огородный,Главный,BB4444 |
Warn |
24.1 |
|||
Огородный,Резервный,AB111 |
OK |
22.8 |
|||
Огородный,Резервный,AA888 |
No data |
- |
|||
Усады |
Warn |
- |
Усады,Основной,JK332 |
Warn |
25.2 |
Усады,Основной,BF768 |
No data |
- |
Имя монитора Мы немного изменили формулировку, чтобы он звучал как для сайта.
Высокая температура в ЦОД района {{.Group}} по сенсорам {{range .Subgroups}} {{.Name}}={{.Value0}}°C{{end}}
Примеры Summary событий для имени монитора
[Triggered] Высокая температура в ЦОД района Огородный сенсоры Огородный,Главный,АА2222=26.3°C
Получается, что в событиях мы часто не будем видеть всех актуальных влияющих групп на данный момент. А бывают ли исключения?
Да, бывают. Во первых, если одновременно сработали две и более групп и перевели надгруппу на другой уровень, то мы увидим их все. И ещё, когда последняя группа снижается с Crit до Warn, а там уже сеть несколько Warn (они до этого не влияли на состояние надгруппы), то в событии будут перчисленны все в результате оказавшиеся по факту в Warn подгруппы.
Использовать политику оповещений
Кнопка-трейлер к функционалу будущего релиза. Эта кнопка размещена здесь умышленно. Она для того, чтобы вы имели ввиду, что идёт работа над глобальной настрокой оповещений на уровне политики и вскоре её можно будет настраивать и включать. Пока эта кнопка не активна и это не баг.
Канал оповещений
Здесь мы должны выбрать один (пока только один для монитора) из преднастроенных через seed файл каналов. Это временное ограничение и скоро будет любая комбинация Contact points.
Получатели оповещений (только для email)
Это поле заполняется только, если выбран канал оповещений E-mail. Через запятую указываются e-mail адреса получателей. Это временное решение, впоследствии это уйдёт в настройку именованных contact points.
Пока нет контроля по каким критичностям отправлять оповещения, а по каким нет. Это в разработке.
4. Настройки NoData
Режим отображения No Data
На что влияет режим No data
Важно
При рассмотрении всех режимов No data нужно помнить, что
обычные штатные срабатывания Triggered, Warn и восстановления Recovery не подчиняются и не затрагиваются режимами No data. При возобновлении поступления данных, «на выходе» из состояния, они срабатывают как обычно, но есть особенности, описанные ниже для каждого режима.
отработка ситуации No data начинается спустя интервал задержки, заданный в поле Задержка обработки No data, по дефолту он ставится 10 минут. Если остановили подачу данных, то увидите вы это не сразу.
Для объяснения мы логически разделим вход в ситуацию после истечения времени задержки и всё ещё отсутствия данных и выход из ситуации, как только приход данных возобновится.
Действия для каждого входа и выхода описаны по следующему шаблону:
Диаграмма - влияние на полосу группы на диаграмме
Событие - какое событие записывается
Проблема - как изменяется существующая проблема и создаётся ли новая
Уведомление - отправка или не отправка уведомления
Четыре режима отработки ситуации прекращения поступления данных по группе
Show last known Последнее известное состояние» (Default mode)
Смысл этого режима в том, чтобы не обращать внимания на сам факт прекращения прихода данных, не показывать вида, притворяться, изображать, что всё без изменений - «как было, так и есть». Это значит, не только не создавать событие, проблему и не оповещать об этом, а не закрывать существующую по этой группе активную проблему, если она есть. В общем, ничего не менять в отображении проблем в расчёте на веру/предположение, что во время отсутствия данных, ситуация остаётся как была. Используется, когда отсутствие данных от группы совсем не констатирует что она «не работает», когда такое случается часто и повода каждый раз поднимать тревогу в таких случаях нет.
Посмотрите на первую диаграмму на этой странице, где речь идёт о температуре в комнате 220А. На ней видно, что режим предполагает полное остутсвие в нём состояния No data. Группа монитора в этом режиме никогда не бывает серой - не бывает в состоянии No data, поскольку его нет. На диаграмме не может быть серого цвета как не бывает и событий с префиксом [No data].
Show OK «сделать принудительный Resolve группе и закрыть проблему»
Вообще, Show OK и Show last known - оба про то, что не нужно «делать проблему из прекращения прихода данных». Только режим Show OK категоричнее «в своей оптимистичности» чем Show Last known. При No data он диктует закрыть проблему, забыть о ней и не оповещать о пропадании данных. Звучит как «Нет данных - нет проблемы», а когда данные пойдут, начать «жизнь с чистого листа».
No data notify Показывать No data и создавать проблемы
Здесь задумано так, чтобы сообщить о самом No data, создать тематическую новую No data проблему или обновить критичность существующей до No data, а также уведомить о ней. Как было сказано выше, здесь No data это полноценный отдельный уровень критичности.
Этот режим предполагает, что в схеме переходов монитора есть полноправное состояние No data, соответственно на диаграмме может быть серый цвет и будут события с префиксами [No data].
No data - без оповещений.
Принцип тот же, что и No data notify, только уведомлений о No data не отправляется совсем. А серые цвета есть.
Задержка обработки No Data
Задержка, после которой инициируются действия по отработке ситуации No data. Рекомендовано 10 минут, для выражений пятиминутного охвата или без агрегации окна. Но если ваше выражение использует Rollup window, например в 1 час [1h], то этот интервал желательно выставить, как удвоенное время окна - т.е. в случае примера в 2 часа.
Удалить группу No Data через
Время через которое монитор забудет о группе, не присылающей данные. Вне зависимости от выбранного режима, «считающиеся почившими» группы удаляются из кеш монитора и как следствие
исчезают из диаграммы групп,
исчезают из событий страницы монитора
их проблемы закрываются.
Если впоследствии они возродятся, то начнут новую жизнь.
Примечание
Но что замечательно, когда «удалённые» возвращаются, то подтягивается всё их прошлое в диаграмме и их события
Важно
Отличительной способностью Astra Monitoring является сохранение состояния метрики в момент опроса. Во всемя сбоев сетевой связности, метрики могут не иметь возможности оперативно поступать на сервер в TSDB. Чтобы не допустить потери данных, предусмотрено их кешировние на агенте в течение значительного времени, 30 минут по дефолту. После восстановления сети метрики досылаются в базу данных и если после этого сделать запрос к временным рядам объектов, картина будет выглядеть так, будто никакого сетевого сбоя и не было, что данные поступали равномерно. График метрики покажет непрерывную линию и мы не сможем судить о плохой надёжности связи с объектами мониторинга. Но Event Processing AM помнит всё. Он ведёт свои временные ряды «в реальном времени = в момент опроса» и о получаемых из выражения данных, и о состояниях групп, включая все периоды No data. Глядя на диаграммы групп монитора в прошлом, мы всегда будем видеть периоды, когда монитор пребывал в состоянии отсутствия данных от группы. Такую способность вы вряд ли найдёте в Prometheus подобных системах.
5. Правила
При всей кажущейся простоте этой секции, здесь кроется особенная гибкость и мощь AM Event Processing.
Главные черты
поддержка стека правил с привязкой по лейблам, который работает как многоступенчатый сортировочный конвейер и позволяет а рамках одного монитора, в зависимости от значений лейблов, селективно применять правила с совершенно разными условиями и даже типами
поддержка как симметричных, там и асимметричных двухуровневых правил, и любых одноуровневых, разумеется
Важно
Вы не можете создать монитор без единого правила либо с пустым или незаполненным правильно правилом.
В зависимости от того, что вы заполнили в четырёх полях числовых значений АМ автоматически определяет, какой тип правила будет создан. В процессе заполнения порогов система подскажет вам, где вы ошибаетесь и что введённые данные неверны - выделит красными рамками.
Правила делятся на
одноуровневые - только один порог, или Crit или Warn
двухуровневые - задействованы оба порога
симметричные - один или оба порога на срабатывание совпадает с порогом/ами на Recovery. Возможно всего три варианта: Crit, Warn, Crit+Warn
асимметричные - пороги на Recovery выставлены дополнительно (это опция), задают более строгие требования на Recovery. Также три варианта
Важно
При асимметричном варианте, в зависимости от выбранного типа сравнения, нужно обязательно учитывать, что порог на восстановление не может быть выставлен «слабее» порога срабатывания. Например, если порог для температуры на Crit 30°C, то порог на Recovery разумеется должен быть ниже (напр. 25°C).
Примечание
Техники бы назвали это свойством гистерезисом.
Гистерезис - это явление, когда система не сразу реагирует на изменение внешних условий, а как бы «запоминает» предыдущее состояние, что приводит к разнице в ее поведении при увеличении и уменьшении воздействия.
Асимметричное правило как бы диктует условие, что вернуться в нормальное или Warn состояние будт сложнее, требования будут более высокими.
Наблюдаемое значение должно быть >= (default) или <= (когда активно) указанного порога
Определяет будет ли это прямой или реверсный режим логики работы оценки. А по-простому, если,
когда больше - это в сторону хуже, то это дефолтный режим >=. Он действет, когда контроль серый и на нём написано >=
например, чем больше числовое значение температуры, тем хуже хуже. Это дефолтное поведение и пороги будем выставлять соответственно Warn должен быть обязательно меньше Critкогда меньше - это в сторону хуже, в этом случае всё наоборот
Значки выбранного условия сранения дублируются перед каждым полем ввода значения
Примечание
Планируется реализовать полный набор возможных условий сравнения: >,<,>=,<=,=,!=
Пока же наличие только двух вариантов не накладывает ограничений ни на какие готовые мониторы и, зная как работать с MetricsQL в выражении запроса, всегда можно выйти из положения.
Обязательные лейблы
Лейблы имя=значение, точнее группы с такми значениями лейблов, на которые будет влиять настраиваемое правило. Если у вас только одно правило вряд ли имеет большой смысл заполнять это поле (накладывать ограничения в нём). Ведь все созданные мониторм группы, которые не попадут под условия по заданным лейблам, просто никогда не будут срабатывать. Теоретически можно представить, что это может кому-то понадобитья, чтобы смотреть на текущие числовые значения таких вечнозелёных групп. Но на практике не используется.
Забегая вперёд скажем, что правило применется к группе при первом же совпадении по лейблам. Низлежащие в стеке правила, которые тоже могут удовлетворять этой группе, не «выполняются».
Примечание
Для обеспечения слективного воздействия монитора в целом используйте фильтр в самом выражении запроса вида q{environment="dev"}
Исключить лейблы
По аналогии. Это лейблы, на которые НЕ будет влиять правило.
Если группа не соответствует обязательным и исключённым лейблам, то «рассмотрение её дела» предаётся на следующее лежащее под ним в стеке правило. И так далее.
+ Новое правило
Важно
Операции со стеком правил пока недоступны и добавление правила погашено - dimmed. Тем не менее, для полноты картины, рекомендуем прочитать это описание, чтобы быть готовыми к использованию этой важной функции.
Добавляя новое правило, вы можете создать стек из правил. Построить своего рода сортировочный конвейер с селективным применением правил. Движение по конвейеру идёт сверху вниз.
Примечание
Только что добавленное правило попадает в самый низ стека и помечается красными скобками, чтобы подчеркнуть его временный «неперемещаемый» статус. Вы можете заполнить всё для него необходимое, но поднять на другую позицию в стеке вы пока не сможете. Нужно сохранить монитор и вернувшись в его редактирование переместить (drag&drop) это правило на нужное место и тем самым задать ему нужный вам приоритет.
Рассмотрим пример, в котором нам нужно для монитора процента использованного места на диске (mountpoint), в зависимости от расположения объекта, применить разные требования:
для prod окружения площадки «огородный» - самые строгие требования
для prod окружений всех остальных (и даже не указанных) площадок менее строгие, при этом исключить product = brest, на него пусть действую дефолтные для организации пороги
для всех остальных = любых окружений, не зависимо от площадок, применить дефолтные слабые требования
Допустим ментрика показывает процент занятого места. Логично, что чем меньше будет значение порога, тем строже правило. Оно начнёт поднимать тревогу раньше других.
Перетаскивание правил
Нажав в любом пустом месте области правила можно его перетащить вверх или вниз по стеку. Тем самым поменять порядок прохождения «конвейера». Как уже было сказано, правила «примериваются» и применяются по порядку сверху вниз.
При перемещении правил, нужно всегда помнить, что если найдено совпадение по лейбла, все правила ниже ИГНОРИРУЮТСЯ. Так, если мы перетащим нижнее правила из примера, на самый верх, то все остальные вообще никогда не будут работать. Первое правило просто «поймает» все группы монитора.
Мощь стека правил в том и заключается, что нам не нужно создавать разные мониторы для разных правил и ещё, что нам не нужно в этих мониторах явно указывать что исключить.
Чтобы проиллюстрировать это, приведём пример трёх примитивно устроенных мониторов, в которых возможно всего по одному правилу, а фильтр задаётся на этапе определения метрики.
Согласитесь, выглядит как пергруженное дублирующей информацией и трудно поддерживаемое решение.
Важно
Поддержка стека правил в комбинации с их асимметричностью - уникальная черта Astra Monitoring
Сохранить
Кнопка сохранить не станет активна до тех пор, пока все обязательные поля не будут корректно заполнены.
Отменить
В правом верхнем углу страницы есть крестик, который выполняет ту же задачу.