1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/AliyunContainerService-prometheus-operator

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
design.md 7.7 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 02.12.2024 10:20 d2c5128

Дизайн

В этом документе описывается дизайн и взаимодействие между определениями пользовательских ресурсов, которые вводит оператор Prometheus.

Пользовательские ресурсы, которые вводит оператор Prometheus:

  • Prometheus;
  • ServiceMonitor;
  • Alertmanager;
  • PrometheusRule.

Prometheus

Определение пользовательского ресурса (CRD) Prometheus декларативно определяет желаемую настройку Prometheus для запуска в кластере Kubernetes. Оно предоставляет опции для настройки репликации, постоянного хранилища и Alertmanagers, которым развёрнутые экземпляры Prometheus отправляют оповещения.

Для каждого ресурса Prometheus оператор развёртывает правильно настроенный StatefulSet в том же пространстве имён. Модули Prometheus настроены на монтирование секрета с именем , содержащего конфигурацию для Prometheus.

CRD указывает, какие ServiceMonitor должны быть охвачены развёрнутыми экземплярами Prometheus на основе выбора метки. Затем оператор генерирует конфигурацию на основе включённых ServiceMonitor и обновляет её в секрете, содержащем конфигурацию. Он постоянно делает это для всех изменений, которые вносятся в ServiceMonitor или в сам ресурс Prometheus.

Если выбор ServiceMonitor не предоставлен, оператор оставляет управление секретом пользователю, что позволяет предоставлять пользовательские конфигурации, при этом всё ещё используя возможности оператора по управлению настройками Prometheus.

ServiceMonitor

Определение пользовательского ресурса (CRD) ServiceMonitor позволяет декларативно определить, как должен отслеживаться динамический набор служб. Какие службы выбраны для мониторинга с желаемой конфигурацией, определяется с помощью выбора меток. Это позволяет организации ввести соглашения о том, как предоставляются метрики, а затем, следуя этим соглашениям, новые службы автоматически обнаруживаются без необходимости перенастройки системы.

Чтобы Prometheus мог отслеживать любое приложение в Kubernetes, должен существовать объект Endpoints. Объекты Endpoints — это, по сути, списки IP-адресов. Обычно объект Endpoints заполняется объектом Service. Объект Service обнаруживает модули с помощью селектора меток и добавляет их в объект Endpoints.

Служба может предоставлять один или несколько сервисных портов, которые поддерживаются списком из нескольких конечных точек, указывающих на модуль в общем случае. Это также отражается в соответствующем объекте Endpoints.

Объект ServiceMonitor, введённый оператором Prometheus, обнаруживает эти объекты Endpoints и настраивает Prometheus для отслеживания этих модулей.

Раздел endpoints спецификации ServiceMonitorSpec используется для настройки того, какие порты этих конечных точек будут очищены для получения метрик и с какими параметрами. Для сложных случаев использования можно захотеть отслеживать порты резервных модулей, которые напрямую не являются частью конечных точек службы. Поэтому при указании конечной точки в разделе endpoints они используются строго.

Примечание: endpoints (в нижнем регистре) — это поле в CRD ServiceMonitor, а Endpoints (с заглавной буквы) — тип объекта Kubernetes.

И ServiceMonitors, и обнаруженные цели могут происходить из любого пространства имён. Это важно для обеспечения межпространственного мониторинга, например, для метамониторинга. Используя ServiceMonitorNamespaceSelector спецификации PrometheusSpec, можно ограничить пространства имён, из которых выбираются ServiceMonitors соответствующим сервером Prometheus. Используя namespaceSelector спецификации ServiceMonitorSpec, можно ограничить пространства имён, откуда разрешено обнаруживать объекты Endpoints. Чтобы обнаружить цели во всех пространствах имён, namespaceSelector должен быть пустым:

spec:
  namespaceSelector:
    any: true

Alertmanager

Определение пользовательского ресурса (CRD) Alertmanager декларативно определяет желаемую установку Alertmanager для запуска в... Кластер Kubernetes. Он предоставляет опции для настройки репликации и постоянного хранилища.

Для каждого ресурса Alertmanager оператор развёртывает должным образом настроенный StatefulSet в том же пространстве имён. Конфигурируются модули Alertmanager таким образом, чтобы включать Secret под названием <alertmanager-name>, который содержит используемый файл конфигурации с ключом alertmanager.yaml.

Когда есть две или более настроенных реплики, оператор запускает экземпляры Alertmanager в режиме высокой доступности.

PrometheusRule

CRD PrometheusRule декларативно определяет желаемое правило Prometheus, которое будет использоваться одним или несколькими экземплярами Prometheus.

Правила оповещений и записи могут быть сохранены и применены в виде файлов YAML и динамически загружены без необходимости перезапуска.

Опубликовать ( 0 )

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

1
https://api.gitlife.ru/oschina-mirror/AliyunContainerService-prometheus-operator.git
git@api.gitlife.ru:oschina-mirror/AliyunContainerService-prometheus-operator.git
oschina-mirror
AliyunContainerService-prometheus-operator
AliyunContainerService-prometheus-operator
master