Как стать автором
Обновить
99
0
Андрей Сидоров @Wimbo

Engineer

Отправить сообщение

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)'

Год назад мне очень помог этот репозиторий и соответствующая статья.

Судя по описанию проблему, вы спокойно можете воспроизвести ее:


  • Запустить в кластере под с dnsperf: https://github.com/guessi/docker-dnsperf (или любым другим подобным ПО)
  • Скейлить coredns/kube-dns в кластере вверх и вниз
  • Смотреть логи kube-proxy
  • Смотреть состояние 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
Я долго думал, как-бы ответить на этот вопрос, но так и не смог придумать каких-то внятных аргументов (все они довольно слабые).
Да, вы правы.
Частично такую проблему можно решить с помощью PSP: kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems, а именно AllowedHostPaths. Однако это тоже не защита от симлинков. Мы добавим данный комментарий в статью.

Спасибо.
Спасибо.
Скорее всего вы правы.
Отличный комментарий!

Да, ваш кейс понятен. Мы этой пингалкой с icmp решили 90% проблем у наших клиентов (диагностики этих проблем). Мы планируем добавить еще udp и tcp протоколы, немного позже.

Про добавление нод, тоже хорошее замечание. В нашем случае если мы в данный configmap добавим, к примеру, 8.8.8.8 адрес, то все ноды начнут его пингать и рисовать графики. Таким образом мы можем поймать проблему, когда «только интернет отвалился» на ноде.

Плюс, конечно — это автоматизировано у нас. Совсем скоро вы узнаете как, но пока это тайна :)
Да! marks уже писал об этом: habr.com/ru/post/443018
Да, мы видели это, я лукавил.
НО нам не подошло это решение из-за того, что тут HTTP мониторинг. Мы хотели именно icmp — так как он более точно покажет сетевую задержку и потери, без оверхеда на стороне HTTP и userspcae процессов.

Было бы более правильно сделать PR в goldpinger, но так было быстрее и проще. Как всегда :)

В статье есть все ямлы :) их просто сложите рядом и сгенерируйте список нод.

Информация

В рейтинге
Не участвует
Откуда
Симферополь, Республика Крым, Россия
Дата рождения
Зарегистрирован
Активность