диски теряешь? ну и ладно, у тебя же ecx

волшебная штука

Господа, пожскажите, есть ли способ в проме протестировать алерты на старых данных?

Бекап всё равно делать

Господа, есть такая проблема: кубеня, прометей, стейтфулсет, в каждый под воткнут statsd_exporter, питоноаппликуха и там таки есть каунтеры. Которые при редеплое сбрасываются, конечно. Гранулярность по лейблам большая. Аппликуха при запуске заранее каунтеры со всеми возможными комбинациями лейблов в 0 не ставит, ибо их дофига в конечном итоге, так что мы легко можем получить до этого не существовавший каунтер со значением 1. Что вызывает проблемы при использовании функции rate(). Ставить централизованный statsd не хотелось бы. Какие могут быть варианты?

В перспективе стейтфулсет станет деплойментом, поэтому скоро даже постоянных хостнеймов не будет

Научить приложеньку отдавать метрики самостоятельно

Так можно научить ее и в statsd_exporter, который сайдкаром идет, их напихивать с нулевыми значениями заранее. Только по памяти шибко жирно получается. Сомневаюсь, что использование прометеелибы решит этот вопрос. Так-то все варианты лейблов у каунтеров произвольно более-менее равномерно размазаны между репликами стейтфулсета.

statsd-exporter

Ага, его и юзаем

а стоп

а зачем в каждый под то?

поднимите один и шлите в него

Это разумно

SPoF, да и дриллдаун до конкретного пода сделать будет сложновато

spof решается и в чем проблема дриллдауна, если лейблы проставлять?

лейблы прекрасно из service discovery проставляются, самому такое костылить не хотелось бы

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

зачем костылить, добавлять же можно на любом этапе, начиная от аппы и заканчивая промом

ну, если я отказываюсь от сбора метрик с каждой реплики и перехожу на сбор с централизованного statsd_exporter, то теряю прелести kubernetes-sd и лейблы из метаданных подов