blackbox_exporter не парсит whois информацию, он делает только пробы (взаимодействует с доменом по какому-то протоколу). По вашей ссылке информация о SSL сертификатах, а не о истечении самого домена.
Снимаете ли вы метрики с WildFly и метрики самого Keycloak?
Есть опыт снятия метрик с Infinispan? Честно у меня так и не завелось.
Бывали ли у вас проблемы с таймаутами у infinispan? У меня были странные развалы кластера infinispan и пока проблема решилась только переключением на TCP с UDP.
livenessProbe/readinessProbe специально отсутствуют у Infinispan?
Бывали ли у вас проблемы с replicated cache у Infinispan? С режимом работы sync/async? Я пока перешел на sync из-за развала replicated cache.
А что это за IP-адреса в JAVA_OPTS ? -Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106
Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?
Проводили ли вы нагрузочное тестирование? Возможно есть какие-то утилиты для проведения таких тестов?
А точно ли это лучший способ? Может стоит заменить на корректный shutdown: jboss-cli.sh --connect command=':shutdown(timeout=30)'
Год назад мне очень помог этот репозиторий и соответствующая статья.
Смотреть состояние conntrack: conntrack -L на машинах фильтруя по адресам подов dns и dnsperf
Данный способ будет корректным, так как в conntrack будет минимальное количество записей связанных с данным подов dnsperf'а, так как src и sport будет один и тот же, при этом в качестве dst будут поды dns.
Ну и на тестовом сетапе вы сможете разобраться более глубоко в проблеме и решить первопричину.
Тут в диагностике не сильно поможет какой-нибудь while true; do host test.com <DNS_POD_IP>, так как в этом случае с большой вероятностью наплодится большое количество записей в conntrack и отдебажить будет куда сложнее.
Если имеется ввиду, что допущенная ошибка в инструменте может привести к проблемам во всех кластерах, то мы минимизируем риски с помощью простых вещей:
— Покрываем все, что возможно тестами
— Ручное тестирование
— У нас есть 5 каналов обновлений, между которыми разделены все кластера: alpha, beta, early-access, stable, rock-solid и мы поэтапно выкатываем на каждый канал обновлений, на каждом из каналов изменения «отстаиваются» определенное время.
На самом деле мы практикуем любые схемы в зависимости от финаносв и специфики клиентов.
Однако более удобен для нас вариант с большим количеством меньших кластеров. Для нас управление большим количеством кластеров не является проблемой, так как у нас есть свой инструмент, который позволяет автоматически устанавливать, настраивать и обновлять все компоненты кластера с помощью конфигов, версий и CustomResource. При этом сохраняет единообразие всего ПО в кластере, будь то кластер в AWS, Azure, OpenStack или bare metal.
Совсем скоро мы планируем выпустить данный инструмент в Open Source.
Да, есть довольно странные или спорные моменты, но куда без них? :)
По вашему примеру с live-restore. Предполагаю, что да — эта проблема имеет место быть, НО! в реальности часто ли вам приходится менять те же storage driver? Почему нельзя мигрировать контейнеры на новые ноды с новым storage driver и потом на старых нодах провести работы. Если вы собираетесь делать такие вещи и знаете, что вы выставили live-restore.
Python у нас используется для разработки proof of concept. Т.е. что-то быстро написать, проверить, что оно работает как надо и получить 80% результата потратив 20% усилий. Так как много у кого из команды есть нужный background в нем. Сделали сбор метрик с помощью node-exporter тоже только из-за того, что так было быстрее, чем еще использовать библиотеки для экспорта метрик prometheus'у.
Если мы видим, что сделали то, что нам надо и оно работает, как надо и есть с ним какие-то проблемы перфоманса или мало фич, то мы уже переписываем его на go.
Я согласен, что тащить еще и Python это лишнее, если есть возможность сразу сделать на go. Но просто не всегда есть свободные ресурсы для «сделать сразу хорошо».
На самом деле я был не прав слишком много времени прошло с поста и успел забыть :)
Есть 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
Да, ваш кейс понятен. Мы этой пингалкой с icmp решили 90% проблем у наших клиентов (диагностики этих проблем). Мы планируем добавить еще udp и tcp протоколы, немного позже.
Про добавление нод, тоже хорошее замечание. В нашем случае если мы в данный configmap добавим, к примеру, 8.8.8.8 адрес, то все ноды начнут его пингать и рисовать графики. Таким образом мы можем поймать проблему, когда «только интернет отвалился» на ноде.
Плюс, конечно — это автоматизировано у нас. Совсем скоро вы узнаете как, но пока это тайна :)
Да, мы видели это, я лукавил.
НО нам не подошло это решение из-за того, что тут HTTP мониторинг. Мы хотели именно icmp — так как он более точно покажет сетевую задержку и потери, без оверхеда на стороне HTTP и userspcae процессов.
Было бы более правильно сделать PR в goldpinger, но так было быстрее и проще. Как всегда :)
blackbox_exporter не парсит whois информацию, он делает только пробы (взаимодействует с доменом по какому-то протоколу). По вашей ссылке информация о SSL сертификатах, а не о истечении самого домена.
Обработка whois является out of scope для blackbox_exporter: https://github.com/prometheus/blackbox_exporter/issues/759#issuecomment-799254166
Спасибо большое за доклад!
Подскажи, пожалуйста, я же верно понимаю, что с указанием
automountServiceAccountToken
mTLS в Istio работать не будет?У вас нет никакой информации о потреблении ресурсов istio-proxy во время нагрузочных тестов.
Хорошо, а почему именно эти IP-адреса? Они во всех кластерах везде будут одинаковые? Если я захочу 2 Keycloak в кластер, они тоже будут одинаковые?
Спасибо большое за статью и за примеры использования.
Я бы хотел задать пару вопросов:
А почему выбрали метод DNS_PING, а не KUBE_PING
Снимаете ли вы метрики с WildFly и метрики самого Keycloak?
Есть опыт снятия метрик с Infinispan? Честно у меня так и не завелось.
Бывали ли у вас проблемы с таймаутами у infinispan? У меня были странные развалы кластера infinispan и пока проблема решилась только переключением на TCP с UDP.
livenessProbe/readinessProbe специально отсутствуют у Infinispan?
Бывали ли у вас проблемы с replicated cache у Infinispan? С режимом работы sync/async? Я пока перешел на sync из-за развала replicated cache.
А что это за IP-адреса в JAVA_OPTS ?
-Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106
Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?
Проводили ли вы нагрузочное тестирование? Возможно есть какие-то утилиты для проведения таких тестов?
А точно ли это лучший способ? Может стоит заменить на корректный shutdown:
jboss-cli.sh --connect command=':shutdown(timeout=30)'
Год назад мне очень помог этот репозиторий и соответствующая статья.
Судя по описанию проблему, вы спокойно можете воспроизвести ее:
conntrack -L
на машинах фильтруя по адресам подов dns и dnsperfДанный способ будет корректным, так как в conntrack будет минимальное количество записей связанных с данным подов dnsperf'а, так как src и sport будет один и тот же, при этом в качестве dst будут поды dns.
Ну и на тестовом сетапе вы сможете разобраться более глубоко в проблеме и решить первопричину.
Тут в диагностике не сильно поможет какой-нибудь
while true; do host test.com <DNS_POD_IP>
, так как в этом случае с большой вероятностью наплодится большое количество записей в conntrack и отдебажить будет куда сложнее.Каналы обновлений у нас существуют практически с начала разработки нашего продукта.
— Покрываем все, что возможно тестами
— Ручное тестирование
— У нас есть 5 каналов обновлений, между которыми разделены все кластера: alpha, beta, early-access, stable, rock-solid и мы поэтапно выкатываем на каждый канал обновлений, на каждом из каналов изменения «отстаиваются» определенное время.
На самом деле мы практикуем любые схемы в зависимости от финаносв и специфики клиентов.
Однако более удобен для нас вариант с большим количеством меньших кластеров. Для нас управление большим количеством кластеров не является проблемой, так как у нас есть свой инструмент, который позволяет автоматически устанавливать, настраивать и обновлять все компоненты кластера с помощью конфигов, версий и CustomResource. При этом сохраняет единообразие всего ПО в кластере, будь то кластер в AWS, Azure, OpenStack или bare metal.
Совсем скоро мы планируем выпустить данный инструмент в Open Source.
По вашему примеру с live-restore. Предполагаю, что да — эта проблема имеет место быть, НО! в реальности часто ли вам приходится менять те же storage driver? Почему нельзя мигрировать контейнеры на новые ноды с новым storage driver и потом на старых нодах провести работы. Если вы собираетесь делать такие вещи и знаете, что вы выставили live-restore.
Если мы видим, что сделали то, что нам надо и оно работает, как надо и есть с ним какие-то проблемы перфоманса или мало фич, то мы уже переписываем его на go.
Я согласен, что тащить еще и Python это лишнее, если есть возможность сразу сделать на go. Но просто не всегда есть свободные ресурсы для «сделать сразу хорошо».
Есть 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
Частично такую проблему можно решить с помощью PSP: kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems, а именно AllowedHostPaths. Однако это тоже не защита от симлинков. Мы добавим данный комментарий в статью.
Спасибо.
Скорее всего вы правы.
Да, ваш кейс понятен. Мы этой пингалкой с icmp решили 90% проблем у наших клиентов (диагностики этих проблем). Мы планируем добавить еще udp и tcp протоколы, немного позже.
Про добавление нод, тоже хорошее замечание. В нашем случае если мы в данный configmap добавим, к примеру, 8.8.8.8 адрес, то все ноды начнут его пингать и рисовать графики. Таким образом мы можем поймать проблему, когда «только интернет отвалился» на ноде.
Плюс, конечно — это автоматизировано у нас. Совсем скоро вы узнаете как, но пока это тайна :)
НО нам не подошло это решение из-за того, что тут HTTP мониторинг. Мы хотели именно icmp — так как он более точно покажет сетевую задержку и потери, без оверхеда на стороне HTTP и userspcae процессов.
Было бы более правильно сделать PR в goldpinger, но так было быстрее и проще. Как всегда :)
В статье есть все ямлы :) их просто сложите рядом и сгенерируйте список нод.