/opt/bridge/bin/bridge -h
-thanos-public-url string
Public URL of the cluster's Thanos server.
-prometheus-public-url string
Public URL of the cluster's Prometheus server.
По идее консоль смотрит в метрики именно по url ключа thanos-public-url, смотреть надо в ту сторону.
// Well-known location of the tenant aware Thanos service for OpenShift exposing the query and query_range endpoints. This is only accessible in-cluster.
// Thanos proxies requests to both cluster monitoring and user workload monitoring prometheus instances.
openshiftThanosTenancyHost = "thanos-querier.openshift-monitoring.svc:9092"
// Well-known location of the tenant aware Thanos service for OpenShift exposing the rules endpoint. This is only accessible in-cluster.
// Thanos proxies requests to the cluster monitoring and user workload monitoring prometheus instances as well as Thanos ruler instances.
openshiftThanosTenancyForRulesHost = "thanos-querier.openshift-monitoring.svc:9093"
// Well-known location of the Thanos service for OpenShift. This is only accessible in-cluster.
// This is used for non-tenant global query requests
// proxying to both cluster monitoring and user workload monitoring prometheus instances.
openshiftThanosHost = "thanos-querier.openshift-monitoring.svc:9091"
Интересно еще как вы своей платформой с финансовой и организационной стороной интегрировались? весело, когда любая команда может заказать сервис. невесело, когда на это накладывается орг структура и финансы отдельных команд и проектов.
И сколько это все отъедает ресурсов? хотя бы верхнеуровнево. Может вместо огромного paas дешевле было б просто нанять 100500 админов для обработки всех тасок?)
Хорошая утилита грейлог...была. в сожалению все больше фич переводят в платную версию. Например, поддержку групп ldap. При этом 3я версия как то быстро стала EOL
создавал третью вм и мерял поочередно.
при этом было подозрение на сеть, так что на самом деле для заландо делал два измерения:
через VIP (keepalive operator, прямо на сервис шифта вешал IP) — вышло 154 tps
через NodePort — вышло 145 tps
виртуальные диски располагались физически на одном ssd, полагаю, можно считать, что они были идентичны.
повторюсь, я не сильно шибко разбираюсь в постгре, вероятно я просто не умею его настраивать.
я постарался упростить насколько мог —
и там и там по одной ноде
диск выдавал локальный.
ресурсы тоже одинаковые(в заландо реквестами выставлял)
по различиям:
zalano ставил внутри кластера openshift, соотвественно ОС — fcos, вместо докера — cri-o.
обычный инстанс был на centos7.
в итоге вышло
ВМ: 402 tps
zalando: 154 tps
есть мнение что проблема на самом деле как раз в лимитах куба, где то на хабре была статья, что лимит может вызывать тротлинг цпу даже когда до планки еще далеко. но в заландо я на тот момент не нашел как это отключить.
другой вариант — локальный диск отдавал контейнеру через local storage operator, и че он с ним там делает — большой вопрос. есть шанс, что была двойная запись.
А есть сравнение производительности такого кластера в кубернетес с аналогичным на голой виртуалке?
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри. Вероятно я просто не смог нормально приготовить оператор...
Задача была автоматизировать добавление новых экспортеров, хранится же все в консуле как в kv хранилище.
Централизованное решение:
метрики все равно выпуливает прометей, так что отправная точка где то рядом с ним. У нас это кластер кубернетес, рядом в том же неймспейсе и этот сервис.
Вынесение функционала в 3 место:
А где должна быть логика? Статик конфиг в Прометее? Автодисковери для обычных вм у него нет.
Предварительное добавление сервиса для сканирования сети вручную:
Не совсем так. Я добавляю подсеть. Дальше он сам ищет экспортеры в подсети и сам добавляет их в kv консула.
Приостановка и удаление вручную:
Останавливать ничего не требуется. Удаляешь сервис из консула — удаляется ендпоинт в Прометее.
Тоже смотрел в свое время на автодисковери Прометея в связке с консулом.
Сам Прометей с консулом работают в кубере, оттуда же же идёт скан портов на предмет экспортеров.
Не идеально но с задачей справляется, а главное без баш скриптов https://github.com/nevidanniu/promenad
Зачем Харбор и женкинс?
В гитее есть хранилище артефактов.
И есть своя реализация cicd runner
Лично я не настраивал, мы сразу сливаем во внешний мониторинг, однако можно воспользоваться опытом Вадима Рутковского (статья по переводу окд с прома на victoriametrics).
Можно еще посмотреть на ключи самой консоли:
По идее консоль смотрит в метрики именно по url ключа thanos-public-url, смотреть надо в ту сторону.
Еще есть референс от разработчиков RedHat (судя по всему Вадим на эти урлы и опирается):
Очень интересно, спасибо!
Интересно еще как вы своей платформой с финансовой и организационной стороной интегрировались?
весело, когда любая команда может заказать сервис. невесело, когда на это накладывается орг структура и финансы отдельных команд и проектов.
И сколько это все отъедает ресурсов? хотя бы верхнеуровнево. Может вместо огромного paas дешевле было б просто нанять 100500 админов для обработки всех тасок?)
Хорошая утилита грейлог...была. в сожалению все больше фич переводят в платную версию. Например, поддержку групп ldap. При этом 3я версия как то быстро стала EOL
при этом было подозрение на сеть, так что на самом деле для заландо делал два измерения:
через VIP (keepalive operator, прямо на сервис шифта вешал IP) — вышло 154 tps
через NodePort — вышло 145 tps
виртуальные диски располагались физически на одном ssd, полагаю, можно считать, что они были идентичны.
повторюсь, я не сильно шибко разбираюсь в постгре, вероятно я просто не умею его настраивать.
по keepalive operator у редхата: www.openshift.com/blog/self-hosted-load-balancer-for-openshift-an-operator-based-approach
и там и там по одной ноде
диск выдавал локальный.
ресурсы тоже одинаковые(в заландо реквестами выставлял)
по различиям:
zalano ставил внутри кластера openshift, соотвественно ОС — fcos, вместо докера — cri-o.
обычный инстанс был на centos7.
в итоге вышло
ВМ: 402 tps
zalando: 154 tps
есть мнение что проблема на самом деле как раз в лимитах куба, где то на хабре была статья, что лимит может вызывать тротлинг цпу даже когда до планки еще далеко. но в заландо я на тот момент не нашел как это отключить.
другой вариант — локальный диск отдавал контейнеру через local storage operator, и че он с ним там делает — большой вопрос. есть шанс, что была двойная запись.
А есть сравнение производительности такого кластера в кубернетес с аналогичным на голой виртуалке?
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри. Вероятно я просто не смог нормально приготовить оператор...
Задача была автоматизировать добавление новых экспортеров, хранится же все в консуле как в kv хранилище.
Централизованное решение:
метрики все равно выпуливает прометей, так что отправная точка где то рядом с ним. У нас это кластер кубернетес, рядом в том же неймспейсе и этот сервис.
Вынесение функционала в 3 место:
А где должна быть логика? Статик конфиг в Прометее? Автодисковери для обычных вм у него нет.
Предварительное добавление сервиса для сканирования сети вручную:
Не совсем так. Я добавляю подсеть. Дальше он сам ищет экспортеры в подсети и сам добавляет их в kv консула.
Приостановка и удаление вручную:
Останавливать ничего не требуется. Удаляешь сервис из консула — удаляется ендпоинт в Прометее.
Тоже смотрел в свое время на автодисковери Прометея в связке с консулом.
Сам Прометей с консулом работают в кубере, оттуда же же идёт скан портов на предмет экспортеров.
Не идеально но с задачей справляется, а главное без баш скриптов
https://github.com/nevidanniu/promenad