Size: a a a

Церковь метрик

2020 April 08

VS

Vitaly Savosin in Церковь метрик
Vitaly Savosin
Доброго дня!
Коллеги, есть такая задача.
Развёрнут Prometheus в инфраструктуре GCP.
Недавно подняли кластер Kubernetes aka GKE.
Нужно собирать метрики из кластера K8s в существующего Прометея.
Недавно спрашивал о возможных вариантах решения данной задачи в соседнем канале о кубере.
Мне посоветовали воспользоваться prometheus operator + remote write.
Я откладывал данную задачу из-за смены приоритетов. А сейчас вновь к ней вернулся.
Но, что-то не могу найти внятного описания данного решения.
Может плохо ищу.
Может кто-то поделиться ссылками по этой теме?
Коллеги, из предложенных решений я понял, на мой взгляд, что оптимальным решением будет настроить remote_write на стороне prometheus в кубере.
Настраивается это довольно просто. В документации об этом написано.
Но вот чего я не понял, так это как настраивать основной prometheus для того, что бы он принимал эти метрики.
Как я понял, remote_read для этого не подходит, так как это другая технология и предназначена для самостоятельного сбора метрик Прометеем с других систем. То есть как обычный скрепинг по pull методу.
В случае remote_write Прометей из кубера будет выполнять push в основной Прометей.
Объясните мне, тупому, как это настроить.
источник

VS

Vitaly Savosin in Церковь метрик
В документации Прометея я не нашёл информации именно как настроить связку Прометей -> Прометей.
Только варианты с Прометем и другими системами.
источник

IM

Ivan Moiseev in Церковь метрик
Vitaly Savosin
В документации Прометея я не нашёл информации именно как настроить связку Прометей -> Прометей.
Только варианты с Прометем и другими системами.
источник

VS

Vitaly Savosin in Церковь метрик
Да, я читал про федерацию.
Но вчера в обсуждении в этом канале было сказано, что для такой схемы федерация не лучшее решение из-за вероятных высоких таймингов
источник

SC

Smoked Cheese in Церковь метрик
Vitaly Savosin
Коллеги, из предложенных решений я понял, на мой взгляд, что оптимальным решением будет настроить remote_write на стороне prometheus в кубере.
Настраивается это довольно просто. В документации об этом написано.
Но вот чего я не понял, так это как настраивать основной prometheus для того, что бы он принимал эти метрики.
Как я понял, remote_read для этого не подходит, так как это другая технология и предназначена для самостоятельного сбора метрик Прометеем с других систем. То есть как обычный скрепинг по pull методу.
В случае remote_write Прометей из кубера будет выполнять push в основной Прометей.
Объясните мне, тупому, как это настроить.
Сам прометей не поддерживает remote_write в себя.
источник

VS

Vitaly Savosin in Церковь метрик
Вот и я так понял. Однако это решение предлагали и здесь и в канале про кубер.
И это ввело меня в тупик.
То есть либо использовать какое-то промежуточное хранилище типа TSDB или федерация?
источник

SC

Smoked Cheese in Церковь метрик
Vitaly Savosin
Вот и я так понял. Однако это решение предлагали и здесь и в канале про кубер.
И это ввело меня в тупик.
То есть либо использовать какое-то промежуточное хранилище типа TSDB или федерация?
Да
источник

VS

Vitaly Savosin in Церковь метрик
Ясно. Благодарю.
источник

VS

Vasilyev Sergey in Церковь метрик
Dmitry K.
Хуже полагаю может быть только cloudwatch 🙂 Мне очень не нравится эта идея, но у меня нет времени разбираться почему 😄 Я полагаю, что он будет плохо работать в случае высокой кардинальности (что у нас точно будет), что компрессия там будет плохо работать (потому что это в первую очередь инструмент для индексации текста, и очень много можно сделать для оптимизации цифровых значений). С другой стороны есть clickhouse, который в метрики умеет. По-этому сомневаюсь.
То вы просто не только в еластик, а еще и в клаудвотч не умеете 🙂
источник

SB

Sergey Bukharov in Церковь метрик
У кого-нибудь есть опыт написания тестов на алерты в Prometheus?
источник

N

Nklya in Церковь метрик
Пару недель назад такой вопрос был, все печально пока что
источник

SB

Sergey Bukharov in Церковь метрик
Никак не возьму в толк, что значит interval - https://github.com/prometheus/prometheus/blob/master/docs/configuration/unit_testing_rules.md
источник

YZ

Yerzhan Zhiyentayev in Церковь метрик
Vitaly Savosin
Да, я читал про федерацию.
Но вчера в обсуждении в этом канале было сказано, что для такой схемы федерация не лучшее решение из-за вероятных высоких таймингов
у меня работает федерация. проблем нет.
касательно таймингов. ну не успеют прийти метрики пару раз - ничего страшного не случится 😕
источник

VS

Vitaly Savosin in Церковь метрик
👍
источник

YC

Yegor Chumakov in Церковь метрик
Сел разбираться с метриками, читаю вот статью https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085

Смотрю, а автор-то знакомый @valyala :) Спасибо за статейку, а то прометеевские доки какие-то убогие, без бутылки не разобраться.
источник

AV

Aliaksandr Valialkin in Церковь метрик
Dmitry K.
Ага, спасибо, почитаю это. Просто если кто-то в компании будет пушить эластик — я буду сопротивляться. Хочется иметь лучшие аргументы против, но нет много времени изучить проблему. :( Сейчас вообще метрики пишутся в логи, отправляются в сумолоджик и там агрегируются. Какого хера вообще — кто это придумал))
лучшее решение - попробовать одновременно записывать данные из прома в эластик и вм и потом выбрать более подходящее решение. Пром поддерживает одновременную запись данных в несколько ремоут стореджей, так что этот вариант несложен в реализации
источник

НА

Наталья Александровна in Церковь метрик
Всем доброго дня. Не подскажите про плагин [[inputs.postgresql_extensible]] для телеграфа, к сожалению запрос который я написала в графану метрики не пишет
источник

НА

Наталья Александровна in Церковь метрик
причем даже если упростить запрос ничего в графану не попадает
источник

НА

Наталья Александровна in Церковь метрик
никто не сталкивался с этим плагином?
источник

ДУ

Денис Устинов in Церковь метрик
а он не тестируется, как системный, да?
источник