Comments 19
UFO just landed and posted this here
Конечно! Вот gist.
Там нужны минимальные правки для того чтобы оно стало рабочим (поменять datasource, исправить interval_rv на interval, возможно что-то еще)
Там нужны минимальные правки для того чтобы оно стало рабочим (поменять datasource, исправить interval_rv на interval, возможно что-то еще)
Или можете наложить патч для grafana с добавлением interval_rv
Спасибо. А вы не планировали выкладывать проект на github: с блекджеком и хельм чартами?
Немного поискав в интернете уже готовые инструменты для поставленной задачи, мы ничего подходящего не нашли.
github.com/bloomberg/goldpinger
Да, мы видели это, я лукавил.
НО нам не подошло это решение из-за того, что тут HTTP мониторинг. Мы хотели именно icmp — так как он более точно покажет сетевую задержку и потери, без оверхеда на стороне HTTP и userspcae процессов.
Было бы более правильно сделать PR в goldpinger, но так было быстрее и проще. Как всегда :)
НО нам не подошло это решение из-за того, что тут HTTP мониторинг. Мы хотели именно icmp — так как он более точно покажет сетевую задержку и потери, без оверхеда на стороне HTTP и userspcae процессов.
Было бы более правильно сделать PR в goldpinger, но так было быстрее и проще. Как всегда :)
Извините за некромментинг, но тем не менее.
У меня однажды была задачка отследить латенси между площадками (по факту — нодами) по принципу «все ко всем», чтобы понять действительные проблемы связи между ними, так как связь ощутимо мигала.
Так вот, icmp не особо показательная штука. После экспериментов был выбран UDP (так как протокол, задержки которого интерсовали, был UDP) со своим примитивным протоколом, потому что было замечено что icmp трафик может ходить как с повышенным, так и с пониженным приоритетом и реальной картины не отражает.
Если хочется достоверной картины — лучше использовать именно тот протокол, который использует само приложение, если это конечно не полностью своя инфраструктура до последнего коммутатора, что в современных реалиях встречается мягко говоря нечасто.
И еще по поводу скрипта, пишущего конфигмап и вообще необходимости его писать.
При работе внутри кластера можно же 3 строчками без какой либо настройки прямо из K8s API прочитать каждым воркером список узлов, зачем еще одна сущность:
У меня однажды была задачка отследить латенси между площадками (по факту — нодами) по принципу «все ко всем», чтобы понять действительные проблемы связи между ними, так как связь ощутимо мигала.
Так вот, icmp не особо показательная штука. После экспериментов был выбран UDP (так как протокол, задержки которого интерсовали, был UDP) со своим примитивным протоколом, потому что было замечено что icmp трафик может ходить как с повышенным, так и с пониженным приоритетом и реальной картины не отражает.
Если хочется достоверной картины — лучше использовать именно тот протокол, который использует само приложение, если это конечно не полностью своя инфраструктура до последнего коммутатора, что в современных реалиях встречается мягко говоря нечасто.
И еще по поводу скрипта, пишущего конфигмап и вообще необходимости его писать.
При работе внутри кластера можно же 3 строчками без какой либо настройки прямо из K8s API прочитать каждым воркером список узлов, зачем еще одна сущность:
#!/usr/bin/env python
from kubernetes import client, config
def main():
# Get in-cluster config
config.load_incluster_config()
v1 = client.CoreV1Api()
nodes = v1.list_node.to_dict()
if __name__ == '__main__':
main()
Отличный комментарий!
Да, ваш кейс понятен. Мы этой пингалкой с icmp решили 90% проблем у наших клиентов (диагностики этих проблем). Мы планируем добавить еще udp и tcp протоколы, немного позже.
Про добавление нод, тоже хорошее замечание. В нашем случае если мы в данный configmap добавим, к примеру, 8.8.8.8 адрес, то все ноды начнут его пингать и рисовать графики. Таким образом мы можем поймать проблему, когда «только интернет отвалился» на ноде.
Плюс, конечно — это автоматизировано у нас. Совсем скоро вы узнаете как, но пока это тайна :)
Да, ваш кейс понятен. Мы этой пингалкой с icmp решили 90% проблем у наших клиентов (диагностики этих проблем). Мы планируем добавить еще udp и tcp протоколы, немного позже.
Про добавление нод, тоже хорошее замечание. В нашем случае если мы в данный configmap добавим, к примеру, 8.8.8.8 адрес, то все ноды начнут его пингать и рисовать графики. Таким образом мы можем поймать проблему, когда «только интернет отвалился» на ноде.
Плюс, конечно — это автоматизировано у нас. Совсем скоро вы узнаете как, но пока это тайна :)
Подскажите, пожалуйста, почему не взяли blackbox_exporter? Он же вроде умеет в icmp.
Я долго думал, как-бы ответить на этот вопрос, но так и не смог придумать каких-то внятных аргументов (все они довольно слабые).
На самом деле я был не прав слишком много времени прошло с поста и успел забыть :)
Есть 2 вещи, очень критичные, из-за которых мы сделали такое решение:
1) Если вы посмотрите команду пинга:
То увидите, что тут происходит 30 пингов и получаем значения за 30 пингов, как раз дефолтный prometheus scrape interval.
В случае использования blackbox_exporter пинг происходит только 1 раз, когда prometheus приходит за метриками, т.е. мы получаем статистику только за 1 раз в 30 секунд, этого уж точно мало, для детальной диагностики и понимания проблем.
2) У blackbox_exporter на сколько я знаю есть проблема, как у statsd_exporter
Есть 2 вещи, очень критичные, из-за которых мы сделали такое решение:
1) Если вы посмотрите команду пинга:
FPING_CMDLINE = "/usr/sbin/fping -p 1000 -A -C 30 -B 1 -q -r 1".split(" ")
То увидите, что тут происходит 30 пингов и получаем значения за 30 пингов, как раз дефолтный prometheus scrape interval.
В случае использования blackbox_exporter пинг происходит только 1 раз, когда prometheus приходит за метриками, т.е. мы получаем статистику только за 1 раз в 30 секунд, этого уж точно мало, для детальной диагностики и понимания проблем.
2) У blackbox_exporter на сколько я знаю есть проблема, как у statsd_exporter
Спасибо за развернутый ответ. В принципе, использование fping — ok, мне нравится. Я ещё погуглил есть ещё 100500 разных ping_exporter разной степени готовности к работе, но fping в них тоже используется. Интересно — можно ли оптимизировать экспортер? Как и сделать его из минимального количества компонентов? Так и может быть переписать на голанг? Всё-таки тащить полноценный питон для такой простой задачи… Не знаю даже. Зато явно разработали относительно быстро )
Ну, и что меня оттолкнуло — зачем эта возня с вольюмами? Почему нельзя было сразу заэкспоузить метрики с пинг экспортёра по сети? Поясню, что зачастую не хочется плодить лишние сущности и/или менять конфигурацию ноде экспортёра (например, если его приносит ранчер на самые базовые метрики)
Python у нас используется для разработки proof of concept. Т.е. что-то быстро написать, проверить, что оно работает как надо и получить 80% результата потратив 20% усилий. Так как много у кого из команды есть нужный background в нем. Сделали сбор метрик с помощью node-exporter тоже только из-за того, что так было быстрее, чем еще использовать библиотеки для экспорта метрик prometheus'у.
Если мы видим, что сделали то, что нам надо и оно работает, как надо и есть с ним какие-то проблемы перфоманса или мало фич, то мы уже переписываем его на go.
Я согласен, что тащить еще и Python это лишнее, если есть возможность сразу сделать на go. Но просто не всегда есть свободные ресурсы для «сделать сразу хорошо».
Если мы видим, что сделали то, что нам надо и оно работает, как надо и есть с ним какие-то проблемы перфоманса или мало фич, то мы уже переписываем его на go.
Я согласен, что тащить еще и Python это лишнее, если есть возможность сразу сделать на go. Но просто не всегда есть свободные ресурсы для «сделать сразу хорошо».
Время хельм чарта не пришло случайно?
Спасибо за пост. Планируется ли создать хельм чарт?
Sign up to leave a comment.
Мониторинг ping'ов между узлами Kubernetes — наш рецепт