ST
графана с неск датасорсами и все
Size: a a a
2020 September 15
GG
что прометеусы в каждом из кластеров могут умереть - раз
GG
два - как строить агрегации поверх нескольких хранилищ? лучше, когда хранилище ( по крайней мере точка входа в него) - одна
A
ага, как раз в этом и идея
A
а насколько криво переливать из прометея в прометей через бакет?
(пытаюсь придумать что-нибудь максимально azure native чтобы не ковырять дырку в vpc)
(пытаюсь придумать что-нибудь максимально azure native чтобы не ковырять дырку в vpc)
GG
Либо Танос какой-нибудь
wooot
A
wooot
да, подходит
A
спасибо 🙂
A
картинка из гугла с чем-то подобным
tt
And now this working 🤔🤔🤔
tt
Perfect!! Thank you so much!!
c
какая разница какой движок
Огромная. Реализация containerD сделана получше crio, по крайней мере год назад стабильнее чем crio работает со слоями.
А
добрый день, а знает кто-то тулзу чтобы быстро набрасывать тесты для постоянного тестирования сервисов, нечто среднее между healthcheck и полноценными end to end тестами. То есть например поднял сервис, набросал 10-20 запросов которые будут идти не на контейнер а снаружи на весь кластер имитируя клиента, которые некто будет гонять каждую секунду, таким образом создавая некую нагрузку по которой можно видеть что оно вообще живо и что все слои dns/firewall/ingress/service/workload не поломано, и лить статистику в prometheus чтобы алерты повесить на это дело.
A
Интеграционным тестированием называется)
A
Инструментарий зависит от интерфейса взаимодействия, от скрипта на баше до selenium-а
A
Если это речь про тестирование вашего приложения, а не кластера кубера)
А
селениум слишком жирно, а скрипт на баше вероятно будет неустойчив к разному поведению сервисов и количеству запросов. тогда проще самом программу написать небольшую на каком-нибудь go. просто если есть что-то готовое хочется не писать самому, но ничего не нашел.
речь про тестирование всей связки и кластера и приложения, и всех прослоек, чтобы отлавливать оперативно какие-то неадекватные кейсы которым вдруг не сделали нормальный мониторинг по какой-то причине. обычный набор регулярных http запросов специфичный под сервис может отловить много кейсов. плюс будет проще алерты настраивать для тестовых окружений в которых нет трафика.
речь про тестирование всей связки и кластера и приложения, и всех прослоек, чтобы отлавливать оперативно какие-то неадекватные кейсы которым вдруг не сделали нормальный мониторинг по какой-то причине. обычный набор регулярных http запросов специфичный под сервис может отловить много кейсов. плюс будет проще алерты настраивать для тестовых окружений в которых нет трафика.