Мониторинг и оповещение об аномалии прометея по количеству показателей

У нас есть несколько серверов Prometheus, каждый из которых контролирует свой регион (фактически 2 на регион), есть также серверы thanos, которые могут запрашивать несколько регионов, и мы также используем alertmanager для оповещения.

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

Буду рад твоему совету.


person Moses    schedule 13.01.2019    source источник
comment
кто угодно????????!   -  person Moses    schedule 15.01.2019


Ответы (1)


Вы можете либо подсчитать количество таймсерий в головном фрагменте (последние 0–2 часа), либо скорость, с которой вы загружаете образцы:

prometheus_tsdb_head_series

or

rate(prometheus_tsdb_head_samples_appended_total[5m])

Затем вы сравниваете указанное значение с самим собой несколько минут / часов назад, например.

prometheus_tsdb_head_series / prometheus_tsdb_head_series offset 5m

и посмотрите, вписывается ли он в ожидаемый диапазон (скажем, 90–110%), и предупредите в противном случае.

Или вы можете посмотреть только показатели с наибольшей мощностью:

topk(100, count({__name__=~".+"}) by (__name__))

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

label_replace(topk(100, count({__name__=~".+"}) by (__name__)), "metric", "$1", "__name__", "(.*)")
  /
label_replace(count({__name__=~".+"} offset 5m) by (__name__), "metric", "$1", "__name__", "(.*)")

Здесь вам нужен label_replace, потому что соответствие для деления выполняется на этикетках, отличных от __name__. Вычисление этого последнего выражения занимает ~ 10 секунд на моем экземпляре Prometheus с серией 150k, так что это совсем не быстро.

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

person Alin Sînpălean    schedule 16.01.2019
comment
Спасибо за ваш комментарий. Я нашел следующий запрос, который подсчитывает количество названий показателей на этикетку: count(count({__name__=~".+",component="api-browser"}) by(__name__)) есть ли у вас предложение, как его оптимизировать? Благодарю. - person Moses; 17.01.2019
comment
Во-первых, вы можете сбросить бит __name__=~".+". Это было только потому, что Prometheus требует хотя бы одного непустого сопоставления в селекторе. Теперь у вас есть component="api-browser", так что он больше не нужен. Я не думаю, что это улучшит производительность, и я не могу придумать ничего, что могло бы, кроме дальнейшего уменьшения количества совпадений, сделав селектор более конкретным. - person Alin Sînpălean; 18.01.2019