Агрегированные метрики от конечной точки прометея - PullRequest
Новая
       26

Агрегированные метрики от конечной точки прометея

0 голосов
/ 18 апреля 2020

У меня есть служба, работающая в кластере k8s, которую я хочу отслеживать с помощью Prometheus Operator. Служба имеет конечную точку /metrics, которая возвращает простые данные, такие как: 

myapp_first_queue_length 12
myapp_first_queue_processing 2
myapp_first_queue_pending 10
myapp_second_queue_length 4
myapp_second_queue_processing 4
myapp_second_queue_pending 0

API работает в нескольких модулях за базовым c Service объектом: 

apiVersion: v1
kind: Service
metadata:
  name: myapp-api
  labels:
    app: myapp-api
spec:
  ports:
  - port: 80
    name: myapp-api
    targetPort: 80
  selector:
    app: myapp-api

Я установил Prometheus, используя kube-prometheus, и добавил объект ServiceMonitor: 

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-api
  labels:
    app: myapp-api
spec:
  selector:
    matchLabels:
      app: myapp-api
  endpoints:
  - port: myapp-api
    path: /api/metrics
    interval: 10s

Prometheus обнаруживает все модули, на которых запущены экземпляры API, и я могу запрашивать эти метрики из графа Prometheus. Пока все хорошо.

Проблема в том, что эти показатели агрегированы - каждый экземпляр / модуль API не имеет своей собственной очереди, поэтому нет причин собирать эти значения из каждого экземпляра. На самом деле, кажется, что это вызывает путаницу - если Прометей собирает одно и то же значение из 10 пакетов, похоже, что общее значение в 10 раз больше, чем оно есть на самом деле, если только вы не знаете, применить что-то вроде avg.

Есть ли способ сообщить Prometheus «это значение уже агрегировано и всегда должно быть представлено как таковое», или, что еще лучше, попросить Prometheus просто один раз очистить значения через внутренний балансировщик нагрузки для этой службы, а не поразить каждый модуль?

edit

Фактический API - это просто Deployment объект: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-api
  labels:
    app: myapp-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp-api
  template:
    metadata:
      labels:
        app: myapp-api
    spec:
      imagePullSecrets:
      - name: mysecret
      containers:
      - name: myapp-api
        image: myregistry/myapp:2.0
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config
          mountPath: "app/config.yaml"
          subPath: config.yaml
      volumes:
      - name: config
        configMap:
          name: myapp-api-config

1 Ответ

1 голос
/ 30 апреля 2020

В вашем случае, чтобы избежать агрегирования метрик, вы можете использовать, как уже упоминалось в вашем посте, оператор avg() для или PodMonitor вместо ServiceMonitor.

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

Таким образом, метрика будет очищаться только от указанного модуля.

...