Доброго времени суток жители Хабра!

Сегодня хочу рассказать вам, как нам очень хотелось мониторить postgres и еще пару сущностей внутри кластера OpenShift и как мы это сделали.

На входе имели:

  • Openshift
  • Helm
  • Prometheus


Для работы с java приложением все было довольно просто и прозрачно, а если быть точнее, то:

1) Добавление в build.gradle

 implementation "io.micrometer:micrometer-registry-prometheus"

2) Запуск prometheus с конфигурацией

 - job_name: 'job-name'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    kubernetes_sd_configs:
    - role: pod
      namespaces:
        names: 
          - 'name'

3) Добавление отображения в Grafana

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

Как же это работает?


Кроме пода с postgres и собственно prometheus нам необходима еще одна сущность — exporter.

Экспортер в отвлеченном понятии это агент, который собирает метрики у приложения или даже сервера. Для postgres exporter написан на Go, работает по принципу запуска внутри sql скриптов на базе и далее полученные результаты забирает prometheus. Это так же позволяет расширять собираемые метрики, добавляя свои.

Деплоим его вот таким образом ( пример deployment.yaml, ни к чему не обязывающий):


---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: postgres-exporter
  labels:
    app: {{ .Values.name }}
    monitoring: prometheus
spec:
  serviceName: {{ .Values.name }}
  replicas: 1
  revisionHistoryLimit: 5
  template:
    metadata:
      labels:
        app: postgres-exporter
        monitoring: prometheus
    spec:
      containers:
      - env:
        - name: DATA_SOURCE_URI
          value: postgresdb:5432/pstgr?sslmode=disable
        - name: DATA_SOURCE_USER
          value: postgres
        - name: DATA_SOURCE_PASS
          value: postgres
        resources:
          limits:
            cpu: 100m
            memory: 50Mi
          requests:
            cpu: 100m
            memory: 50Mi
        livenessProbe:
          tcpSocket:
            port: metrics
          initialDelaySeconds: 30
          periodSeconds: 30
        readinessProbe:
          tcpSocket:
            port: metrics
          initialDelaySeconds: 10
          periodSeconds: 30
        image: exporter
        name: postgres-exporter
        ports:
        - containerPort: 9187
          name: metrics

Так же для него понадобился сервис и имейджстрим

После деплоя нам очень хочется, чтобы все друг друга видели.

Добавляем в конфиг прометея такой кусочек:

  - job_name: 'postgres_exporter'
    metrics_path: '/metrics'
    scrape_interval: 5s
    dns_sd_configs:
    - names:
      - 'postgres-exporter'
      type: 'A'
      port: 9187

И вот тут то все заработало, осталось добавить все это добро в графану и наслаждаться результатом.

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

Аналогичным способом было сделано для:

  • Kafka
  • Elasticsearch
  • Mongo

P.S. Все данные по именам, портам и остальному взяты с потолка и не несут никакой информации.

Полезные ссылки:
Список различных экспортеров

Комментарии (4)


  1. gecube
    18.09.2019 19:27

    С почином! Какие-то сложности были? Как разбили приложение и постгрес с экспортером по неймспейсам и проектам опеншифта? Разработчики очень часто не понимают, как это сделать лучше


    1. SicYar Автор
      18.09.2019 19:47

      Сложности были в первоначальном осознании как это все подружить друг с другом )

      по поводу

      Как разбили приложение и постгрес с экспортером по неймспейсам и проектам опеншифта
      — в одном неймспейсе микросервисы, рядом постгрес и все остальное. Архитектура такая выбрана не случайно, а по ряду причин не зависищих лично от моих хотелок))


      1. gecube
        19.09.2019 10:02

        по ряду причин не зависищих лично от моих хотелок))

        В любом случае интересно почитать доводы за такое, а не другое распределение сервисов по NS.


        1. SicYar Автор
          19.09.2019 12:30

          В каждом NS полный набор всех приложений:
          — микросервисы самого приложения — к ним сайдкар jaeger
          — поды с postgres и mongo и elastic
          — рядом поды с exporters
          — далее вспомогательные поды с самим jaeger, prometheus, nginx, envoy

          разделение внутри NS по тегам, то есть BD, APP_BACKEND, APP_FRONT, OTHER

          именование конечно используется в соответсвии с именованием подов но суть такая

          а сами NS разделены по темам, то есть 2 для тестирования локального, 2 для тестирования нагрузочного, 2 препрод, прод и есть еще NS для экспериментов и нужд