Мониторинг количества секунд с момента изменения метри c как временных рядов прометея - PullRequest
Новая
       35

Мониторинг количества секунд с момента изменения метри c как временных рядов прометея

0 голосов
/ 30 марта 2020

На это уже частично ответили в время получения, которое прошло с момента последнего увеличения счетчика Prometheus

Но не достаточно, поэтому я спрашиваю здесь и в Google Prometheus Group: https://groups.google.com/d/msg/prometheus-users/I7gJ15BIvXg/jFlxOSppBAAJ

-

У меня есть шаблон правила записи: 

  - record: last-update
    expr: |
      timestamp(changes(metric-name[450s]) > 0)
        or
      last-update
    labels:
      stat: true
      monitor: false

Однако это не работает. Партия or last-update не возвращает значение.

Я пытался использовать смещение, or (last-update offset 450s), но безрезультатно.

Моя оценочная частота составляет 5 минут (частота, которую вызывает прометей) запускает мои правила записи). Я попробовал смещение в 7,5 минут, потому что теоретизировал, что OR пытался записать last-update как last-update, но последнее обновление было нулевым в эту секунду; если OR пытался написать last-update как значение, которое было во время предыдущей оценки, то он должен найти значение в last-update, но это значение также не вернулось.

Это то, что метри c выглядит графически:

неровно, а не целая лестница (у меня недостаточно репутации, чтобы публиковать фотографии ...)

Заранее спасибо за вашу помощь.

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

1 Ответ

0 голосов
/ 01 апреля 2020

Подводя итог нашей дискуссии: интервал оценки слишком велик; через 5 минут метри c становится устаревшим . Это означает, что при вычислении выражения правая часть вашего выражения OR больше не рассматривается Прометеем и, следовательно, всегда пуста.

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

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

vector1 or vector2 приводит к вектору, который содержит все исходные элементы (наборы меток) + значения) вектора1 и дополнительно все элементы вектора2 , которые не имеют совпадающих наборов меток в векторе1 .

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

Ваше выражение должно быть примерно таким: 

    expr: |
      timestamp(changes(metric-name[450s]) > 0)
        or ignoring(stat,monitor)
      last-update

Или используйте предложение ON(label1,label2,...) в различающем наборе меток, которое позволяет избежать изменения выражения при изменении меток.

...