Как масштабировать прометея в среде кубернетов

Я дошел до того момента, когда мне нужно разбить мой Прометей на более мелкие. Я читал об этом здесь, но он ничего не говорит о масштабировании в кубернетах. Ниже моя установка:

и существует около 50 пространств имен, которые производят тысячи метрик, и одной текущей настройки с одним прометеем недостаточно. Поэтому я решил разделить его на три экземпляра, например:

Но через какое-то время я понял, что эти показатели обрабатываются kubernetes_sd_config и нет способ узнать, какие метрики я хочу очистить, с помощью какого экземпляра prometheus или я ошибаюсь. Одним из решений было бы разделить кластер Kubernetes на меньший, но пока это слишком много.

Итак, мой вопрос: есть ли возможность сообщить Прометею, что я хочу очищать только показатели состояния куба, экспортер узлов или собственные метрики кубернетов?


kubernetes prometheus metrics
person widget    schedule 22.12.2016    source источник
comment
Одно из решений, о котором я думаю, - не добавлять аннотации к службам экспортеров для prometheus и настраивать для них статическую конфигурацию.   -  person widget    schedule 22.12.2016

Ответы (3)


arrow_upward
2
arrow_downward

Другой вариант - горизонтально масштабируемая распределенная реализация Prometheus: https://github.com/weaveworks/cortex (NB это я написал.)

Он еще не готов к использованию в прайм-тайм, но мы используем его внутри компании и получаем довольно хорошие результаты. Его установка и работа потребуют больше усилий, чем исходный Prometheus, но он должен масштабироваться практически бесконечно - и, более того, мы запускаем его на Kubernetes, так что он действительно здесь как дома.

Дайте мне знать, если вы заинтересованы, и я могу провести вас, хотя настраиваю его.

person tom.wilkie    schedule 10.02.2017

arrow_upward
1
arrow_downward

Масштабирование в Kubernetes такое же, как и везде. Это вопрос использования обнаружения сервисов и перемаркировки, чтобы выбрать то, что отслеживается.

Например, конфигурация для экспортеров узлов уже должна быть отдельной scrape_config, поэтому разделение ее на отдельный Prometheus должно быть простым путем разделения файла конфигурации.

person brian-brazil    schedule 22.12.2016
comment
какой scrape_config я должен создать? статический? - person widget; 22.12.2016
comment
Сейчас я использую kubernetes_sd_config с аннотациями в сервисах. кстати, позволяет ли перемаркировка фильтровать метрики или просто метки из метрик? - person widget; 22.12.2016
comment
Итак, как этот отдельный scrape_config должен выглядеть для экспортера узлов? Прямо сейчас я использую, скажем, kubernetes_sd_config по умолчанию, а экспортер узлов развернут как демон с сервисом, который аннотирован для prometheus. - person widget; 22.12.2016
comment
разве это не похоже на github.com/prometheus/prometheus/issues/2280? - person widget; 22.12.2016
comment
Проблема в другом, это обсуждение того, чтобы не выполнять запросы API к определенным пространствам имен Kubernetes API, поэтому мы говорим о пространствах имен объектов Kubernetes, которые не имеют ничего общего с Prometheus как таковым. Брайан говорит о том, что у вас есть отдельные экземпляры Prometheus для каждого из них. 1 для очистки узлов-экспортеров, 1 для показателей состояния куба, 1 для всех остальных показателей. Это называется функциональным сегментированием. Как только вы достигнете предела функционального обмена, вы можете начать сегментирование целей, как описано в сообщении в блоге, чтобы иметь более одного экземпляра Prometheus для каждой из них. - person brancz; 22.12.2016
comment
У меня есть, но я не знаю, как сделать этот функциональный шардинг с помощью kubernetes_sd_config. Есть ли возможность указать цели в kubernetes_sd_config? Я мог бы сделать это с static_config, но это не лучшее решение в кубернетах. - person widget; 22.12.2016
comment
Может мне стоит попробовать оператора прометея от coreos - person widget; 22.12.2016

arrow_upward
0
arrow_downward

У меня была аналогичная задача для федерации. Вот как я это сделал после ответа @brian-brazil:

  • настроить master prometheus с конфигурацией:

scrape_configs: - job_name: dc_prometheus honor_labels: true metrics_path: /federate params: match[]: - '{job="my-kubernetes-job"}' static_configs: - targets: - prometheus-slaveA:9090 - prometheus-slaveB:9090 Посмотрите, как здесь объявлены рабы. Это точно статично. Кроме того, параметр match[] здесь указывает, что нужно получить все ведомые метрики. Вы, конечно, должны быть умнее этого.

  • настройте slaves с этим конкретным перемаркированием:

relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_slave] action: keep regex: slaveA

и аналогично для slaveB и тд.

Теперь для каждого модуля вместо хорошо известной аннотации prometheus.io/scrape: true|false у вас будет prometheus.io/slave: slaveA|slaveB.

Я описал это более подробно здесь: http://devlog.qaraywa.net/?p=176 < / а>

person Joel    schedule 07.12.2017