в факе есть. в целом всё плохо

а как бы мне замониторить рабочий процесс резолва доменов с vps, и так умно алерт отправить, если днс лег в нат сети?

странного хочу

спс

Здравствуйте. Не уверен что это прям подходящая для моего вопроса група, но все же рискну.
Есть кубер №1, там сидит база, управляется и создается с помощью Crunchy Operator. Подрубил мониторинг, все работает отлично.
Но интересует такой вопрос. Хотелось б мониторинг в другой кластер перенести. Создал в кластере №2 стэк мониторинга ( prometheus, grafana, alertmanager). Поправил конфиг прома, добавил api_server с значением api эндпоинта кубера №1, все перезагрузил. После этого пром в кубере №2 начал видит кластер postgres-а с кубера №1, но данных с экспортера получить не может, ибо стучится на айпи адрес контейнера в кубере №1. Естественно что он не может этого сделать, ибо достучатся можна только с кластера №1. Так вот, можно ли заставить prometheus стучатся на айпи через api кубера, типо как прокси? Я с кубером да и промом только знакомлюсь, так что возможно есть гораздо лучшее решение

А а чем проблема собирать метрики с Прометея в кластере 1

Федерация все дела

Я бы кластер без прометеуса не оставлял

timberio/vector tagged: v0.14.0: Typo
Link: https://github.com/timberio/vector/releases/tag/v0.14.0
Release notes:

Signed-off-by: Jesse Szwedko [jesse@szwedko.me](mailto:jesse@szwedko.me)

timberio/vector tagged: v0.14.0
Link: https://github.com/timberio/vector/releases/tag/v0.14.0
Release notes:

[View release notes](https://vector.dev/releases/0.14.0/)

Приветсы! У меня небольшой вопрос, но для контекста:
Есть коллектор потоков с сетевого оборудования, он достаёт из него инфу, от куда куда и какой объём, складывает такую запись в кафку
Экспортер достаёт из кафки эти  сообщения и отдаёт как метрики для прометеуса.

Сам именно с метриками не так давно работаю, но сейчас приходится немного доработать старый экспортер и есть одна вещь, которую я не могу понять.
В оригинале экспортер добавлет лейблы recevived_at и round, который является голанговским итератором по сути [0...9]
Мне почему-то кажется, что каждая запись не должна быть уникальной, потому что даже когда я выбираю сумму по лейблам by (src, dst) и чутка увеличиваю диапазон, то у меня намертво повисает прометеус.
Я думал убрать эти лейблы, но тогда я пропущу часть измерений, потому что метрика с теми же лейблами может успеть сброситься до того, как произойдёт скрапинг.

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

это counter или gauge? да она может сброситься, но прометеус и не обещает прям точных значений, а каунтеры обрабатывают сбросы. с уникальными значениями лейблов типа таймстампов конечно получите большой cardinality

вернее не сами каунтеры, а rate

Это gauge, да, и как я понял автор экспортера использует таймштамп чтоб не потерять часть инфы.
Но тогда такой вопрос, есть ли способ без таймштампов не потерять сумму данных хотяб?
криво описал, например вот экспортер достаёт два сообщения
bytes{src=1, dst=2, time=13:37} 5000
bytes{src=1, dst=2, time=13:40} 4000
И если я уберу таймштамп, у меня второй семпл со значением 4000 перетрёт первй, и я когда буду суммировать по (src, dst) получу неверную сумму

мне кажется что автор экспортера не верно выбрал тип метрики

Или даже если я сделаю два раза подряд Set(value) на метрику с одними и теми же лейблами, они не затрутся, а будут рядом и суммирование пройдёт правильно?

Но тут я ещё погуглю сам за библиотеку, если что

A gauge is a metric that represents a single numerical value that can arbitrarily go up and down.