Доброго времени суток жители Хабра!
Сегодня хочу рассказать вам, как нам очень хотелось мониторить postgres и еще пару сущностей внутри кластера OpenShift и как мы это сделали.
На входе имели:
Для работы с java приложением все было довольно просто и прозрачно, а если быть точнее, то:
1) Добавление в build.gradle
2) Запуск prometheus с конфигурацией
3) Добавление отображения в Grafana
Все довольно просто и прозаично было до тех пор, пока не наступил момент мониторить базы, которые находятся у нас рядом в неймспейсе ( да, это плохо, никто так не делает, но бывает разное).
Кроме пода с postgres и собственно prometheus нам необходима еще одна сущность — exporter.
Экспортер в отвлеченном понятии это агент, который собирает метрики у приложения или даже сервера. Для postgres exporter написан на Go, работает по принципу запуска внутри sql скриптов на базе и далее полученные результаты забирает prometheus. Это так же позволяет расширять собираемые метрики, добавляя свои.
Деплоим его вот таким образом ( пример deployment.yaml, ни к чему не обязывающий):
Так же для него понадобился сервис и имейджстрим
После деплоя нам очень хочется, чтобы все друг друга видели.
Добавляем в конфиг прометея такой кусочек:
И вот тут то все заработало, осталось добавить все это добро в графану и наслаждаться результатом.
Кроме возможности добавлять свои запросы, в prometheus можно изменять настройку, собирая более таргетированно необходимые метрики.
Аналогичным способом было сделано для:
P.S. Все данные по именам, портам и остальному взяты с потолка и не несут никакой информации.
Полезные ссылки:
Список различных экспортеров
Сегодня хочу рассказать вам, как нам очень хотелось мониторить 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. Все данные по именам, портам и остальному взяты с потолка и не несут никакой информации.
Полезные ссылки:
Список различных экспортеров
gecube
С почином! Какие-то сложности были? Как разбили приложение и постгрес с экспортером по неймспейсам и проектам опеншифта? Разработчики очень часто не понимают, как это сделать лучше
SicYar Автор
Сложности были в первоначальном осознании как это все подружить друг с другом )
— в одном неймспейсе микросервисы, рядом постгрес и все остальное. Архитектура такая выбрана не случайно, а по ряду причин не зависищих лично от моих хотелок))по поводу
gecube
В любом случае интересно почитать доводы за такое, а не другое распределение сервисов по NS.
SicYar Автор
В каждом NS полный набор всех приложений:
— микросервисы самого приложения — к ним сайдкар jaeger
— поды с postgres и mongo и elastic
— рядом поды с exporters
— далее вспомогательные поды с самим jaeger, prometheus, nginx, envoy
разделение внутри NS по тегам, то есть BD, APP_BACKEND, APP_FRONT, OTHER
именование конечно используется в соответсвии с именованием подов но суть такая
а сами NS разделены по темам, то есть 2 для тестирования локального, 2 для тестирования нагрузочного, 2 препрод, прод и есть еще NS для экспериментов и нужд