Как определить оповещения за исключением в InfluxDB / Kapacitor - PullRequest
Новая
       46

Как определить оповещения за исключением в InfluxDB / Kapacitor

0 голосов
/ 10 июля 2019

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

Каков подход, когда вы хотите отклониться от вышеуказанной настройки для хоста, то есть вместо X% для конкретного серверамы хотим предупредить о Y%?

Я рад, что для настраиваемых значений можно создать отдельный тикскрипт, но как мне исключить хост из исходного «глобального»?

Это простой сценарий, но он должен удовлетворять потребностям 10 000 хостов, из которых будут возникать сотни исключений, и это также будет охватывать 10/100 глобальных определений предупреждений.

Я изо всех сил пытаюсь понять, как вы могли бы использовать платформу в качестве основного источника мониторинга / оповещения.

Ответы [ 2 ]

0 голосов
/ 13 июля 2019

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

Допустим, вы хотите убедиться, что ваши серверы InfluxDB не перегружены. Вы можете разрешить 100 измерений по умолчанию. Только на одном сервере, который получает огромное количество точек данных, вы хотите ограничить его до 10 (значение, которое легко превышает базу данных _internal, но хорошо для нашего примера).

Учитывая следующую выдержку из сценария тиков 

var data = stream
    |from()
        .database(db)
        .retentionPolicy(rp)
        .measurement(measurement)
        .groupBy(groupBy)
        .where(whereFilter)
    |eval(lambda: "numMeasurements")
        .as('value')

var customized = data
    |sideload()
        .source('file:///etc/kapacitor/customizations/demo/')
        .order('hosts/host-{{.hostname}}.yaml')
        .field('maxNumMeasurements',100)
    |log()

var trigger = customized
    |alert()
        .crit(lambda: "value" > "maxNumMeasurements")

и имя сервера с исключением influxdb и файл /etc/kapacitor/customizations/demo/hosts/host-influxdb.yaml, выглядящий следующим образом 

maxNumMeasurements: 10

Критическое предупреждение будет активировано, если value, и, следовательно, numMeasurements превысит 10, а тег имени хоста будет равен influxdb ИЛИ, если value превысит 100.

Существует пример в документации по обработке запланированных простоев с использованием боковой загрузки

Кроме того, я создал пример, доступный на github, используя docker-compose

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

0 голосов
/ 11 июля 2019

Управление оповещениями вручную напрямую в Chronograph / Kapacitor невозможно при большом количестве настраиваемых оповещений.

В AMMP Technologies нам нужно управлять оповещениями для каждой базы данных, клиента, клиента. Число может войти в 1000-е годы. Мы выбрали нестандартное решение, в котором сохранен стандартный набор шаблонных текстовых сценариев (не путать с шаблонами Kapacitor), и мы предоставляем интерфейс для пользователя, который предоставляет только соответствующие переменные. После этого служба (написанная на python) объединяет значения для этих переменных с помощью тикскрипта и с помощью API Kapacitor развертывает (обновляет или удаляет) задачу на сервере Kapacitor. Затем это автоматизируется, чтобы данные о новых клиентах / объектах объединялись с шаблонами и автоматически развертывались в Kapacitor.

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

...