Ярлык экземпляра Прометея против контейнеров

Question

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

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

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

Если это так, можно ли его каким-либо образом смягчить, например, путем корректировки периодов хранения или с помощью другого механизма хранения, такого как адаптер DB притока? *

Answer 1

Я исследовал это еще немного и нашел это видео от одного из сопровождающих, Фабиана Рейнарца, очень поучительно:

https://m.youtube.com/watch?v=nDalewt4BOw

В принципе, это не проблема для Прометея2.0 и выше, чтобы просто использовать идентификатор контейнера в качестве метки instance.

В Prometheus 2 он имеет новый временной ряд db, который оптимизирован для этого случая.Кроме того, когда Прометей 2 обнаруживает, что instance слишком долго не работает, он предполагает, что он был убит и больше не вернется, и формально закрывает временные ряды этого экземпляра.Это предотвращает постоянно растущий набор временных рядов и помогает решить проблему.

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