Пилил я как-то задачу связанную с мониторингом тестового сервера. С одной стороны ну что там сложного, воткнул везде node_exporter и вперед, пусть prometheus ходит и забирает с них метрики. Всё логично.
Но есть закон подлости: если оценить задачу в 5 минут, то обязательно вылезут подводные камни. Собственно они и вылезли. Сейчас расскажу.
Тестовый сервер представляет нечто подобное:
🤒
Уффф. Пошел смотреть в сторону pushgateway, чтобы инстансы сами метрики пушили в prometheus или сразу в VictoriaMetrics.
VictoriaMetrics — быстрая и масштабируемая СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик).
Но тут снова грабли. У prometheus тоже нет белого айпи. Это провал! Какой-то замкнутый круг получается. Забрать метрики не можем, отдать тоже не можем.
Выдавать белые айпишники ой как не хочется, по причине — лень настраивать фаерволы и прочую шляпу. Но что же делать? Правильно — достаём костыли!
Так как у тестовых серверов на [балансировщике] есть белый ip адрес, будем привлекать iptables и жёстко роутить.
На балансировщике с белым ip, выполняем:
А в prometheus говорим, иди на внешний айпишник балансировщика с портами 1001-1003 и выгребай данные с серых инстансов.
prometheus.yml
🧠
tags: #рабочиебудни #monitoring #networks
—
🟢 Подпишись: @bashdays
Но есть закон подлости: если оценить задачу в 5 минут, то обязательно вылезут подводные камни. Собственно они и вылезли. Сейчас расскажу.
Тестовый сервер представляет нечто подобное:
- балансировщик (белый айпишник)У [балансировщика] есть белый айпишник, у остальных (фронтэнд, бекэнд, база) только серые. Хм… ну и как prometheus будет ходить на серые инстансы и забирать метрики? Да никак!
- фронтэнд (192.168.0.3)
- бекэнд (192.168.0.4)
- база (192.168.0.5)
Уффф. Пошел смотреть в сторону pushgateway, чтобы инстансы сами метрики пушили в prometheus или сразу в VictoriaMetrics.
VictoriaMetrics — быстрая и масштабируемая СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик).
Но тут снова грабли. У prometheus тоже нет белого айпи. Это провал! Какой-то замкнутый круг получается. Забрать метрики не можем, отдать тоже не можем.
Выдавать белые айпишники ой как не хочется, по причине — лень настраивать фаерволы и прочую шляпу. Но что же делать? Правильно — достаём костыли!
Так как у тестовых серверов на [балансировщике] есть белый ip адрес, будем привлекать iptables и жёстко роутить.
На балансировщике с белым ip, выполняем:
-A PREROUTING -p tcp -m tcp --dport 1001 -j DNAT --to-destination 192.168.0.3:9100Идея заключается в том, что с портов 1001-1003 (на балансировщике) мы попадаем на внутренние инстансы с серыми айпишниками и забираем свои метрики с портов 9100.
-A PREROUTING -p tcp -m tcp --dport 1002 -j DNAT --to-destination 192.168.0.4:9100
-A PREROUTING -p tcp -m tcp --dport 1003 -j DNAT --to-destination 192.168.0.5:9100
-A POSTROUTING -j MASQUERADE
А в prometheus говорим, иди на внешний айпишник балансировщика с портами 1001-1003 и выгребай данные с серых инстансов.
prometheus.yml
---Красота! Кейс рабочий, костыли присутствуют, графики красивые, тестировщики довольные. Ну а что еще надо? Think different!
- targets:
- balancer:1001
labels:
env: test
role: frontend
- targets:
- balancer:1002
labels:
env: test
role: backend
tags: #рабочиебудни #monitoring #networks
—