Селдон: Как использовать мои собственные экземпляры Grafana и Prometheus?

Question

Я хочу использовать свои уже существующие экземпляры Prometheus и Grafana в пространстве имен мониторинга, чтобы имитировать то, что делается. Я использую диаграммы управления сообщества prometheus и устанавливаю kube-prometheus-stackна k8s. Вот что я сделал до сих пор:

в values.yaml В файле конфигурации prometheus я добавил следующие аннотации:

      annotations:
  prometheus.io/scrape: "true"
  prometheus.io/path: "/prometheus

Затем я посмотрел на prometheus-config.yaml в своем репозитории Github, скопировали и вставили конфигурацию в файл configmap.

Также создал ServiceMonitor

      apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: seldon-servicemonitor-default
  labels:
    seldon-monitor: seldon-default
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/managed-by: seldon-core
  endpoints:
    - interval: 15s
      path: /metrics
      port: http
    - interval: 15s
      path: /prometheus
      port: http
  namespaceSelector:
    matchNames:
      - seldon
      - default
      - monitoring

Пока нет ошибок с вышеуказанными шагами, но не похоже, что экземпляр prometheus может очистить метрики из модели, которую я развернул в другом пространстве имен. Какая еще конфигурация мне нужна, чтобы мои собственные экземпляры Prometheus и Grafana могли собирать и визуализировать метрики из моих развернутых моделей seldon? Документация на самом деле не объясняет, как это сделать на ваших собственных экземплярах, и на том, который они предоставляют вам через seldon-core-analytics не готов к производству.

Answer 1

Конфигурация Прометея в seldon-core-analyticsвполне стандартно. Он основан на встроенном обнаружении сервисов Kubernetes и использует аннотации для поиска целей парсинга:

      annotations:
  prometheus.io/scrape: true
  prometheus.io/path: /metrics
  prometheus.io/scheme: http
  prometheus.io/port: 9100

В своем примере конфигурации prometheus будет нацеливаться на модули, службы и конечные точки с prometheus.io/scrape: trueаннотации к ним. Остальные три метки используются для переопределения параметров очистки по умолчанию для каждой цели. Таким образом, если у вас есть конфигурация, как в примере, вам нужно только поместить некоторые из этих аннотаций в модули.

Способ kube-prometheus-stackработает разное. Он использует оператор Прометей и CRD для формирования конфигурации. Этот проектный документ описывает назначение каждого CRD.

Вам необходимо создать ресурс, чтобы определить правило очистки для новых услуг. сам должен иметь метки, как определено в ресурсе prometheus (другой CRD) в разделе serviceMonitorSelectorключ. В таких обстоятельствах сложно предоставить вам рабочий пример, но этого краткого руководства должно быть достаточно, чтобы понять, что делать.

Я предлагаю вам описать один из имеющихся у вас s, а затем создать новый, изменив метки под matchLabels. Не изменяйте пространство имен в новом объекте, оператор prometheus по умолчанию не ищет s в других пространствах имен. Сделать ServiceMonitor обнаруживать цели во всех пространствах имен namespaceSelector должно быть пустым:

      spec:
  namespaceSelector:
    any: true

Answer 2

ServiceMonitors чрезвычайно сложно отлаживать. Моя стратегия отладки заключалась бы в следующем:-

1. Убедитесь, что созданный ServiceMonitor читается Prometheus :- Посмотрите URL-адрес / target. (По крайней мере, цель должна быть в состоянии 0/0). Если нет, это означает, что сам ServiceMonitor не обрабатывается Prometheus. Я предлагаю изучить следующую конфигурацию в вашей конфигурации kube-prometheus-stack.

               serviceMonitorSelectorNilUsesHelmValues: false
       serviceMonitorSelector: {}
       serviceMonitorNamespaceSelector: {} 
   

   К ServiceMonitor по умолчанию прикреплены метаданные Helm, которые используются Оператором Prometheus для фильтрации / выбора ServiceMonitors для мониторинга. Параметр serviceMonitorSelectorNilUsesHelmValues:false проигнорирует любой такой выбор.

2. Если ServiceMonitor виден в целевых объектах, но их нет. :- В этом случае проблема заключается между ServiceMonitor и модулями, которые он пытается очистить. Проверьте, доступны ли указанные вами порты и соответствуют ли модули указанным селекторам.

Я бы посоветовал запустить еще один фиктивный ServiceMonitor, следуя этому, а затем изменяя ServiceMonitor шаг за шагом, пока он не начнет отслеживать seldon-core-analytics стручки