Как собирать метрики с приложений, расположенных вне кластера?
- Сконфигурировать Service, по аналогии с сервисом для сбора метрик с вашего приложения, но без указания параметра
spec.selector
. - Создать Endpoints для этого Service, явно указав в них
IP:PORT
, по которым ваши приложения отдают метрики.Важный момент: имена портов в Endpoints должны совпадать с именами этих портов в Service.
Пример
Метрики приложения доступны без TLS, по адресу http://10.182.10.5:9114/metrics
.
apiVersion: v1
kind: Service
metadata:
name: my-app
namespace: my-namespace
labels:
prometheus.deckhouse.io/custom-target: my-app
spec:
ports:
- name: http-metrics
port: 9114
---
apiVersion: v1
kind: Endpoints
metadata:
name: my-app
namespace: my-namespace
subsets:
- addresses:
- ip: 10.182.10.5
ports:
- name: http-metrics
port: 9114
Как добавить дополнительные dashboard’ы в вашем проекте?
Добавление пользовательских dashboard’ов для Grafana в Deckhouse реализовано при помощи подхода infrastructure as a code.
Чтобы ваш dashboard появился в Grafana, необходимо создать в кластере специальный ресурс — GrafanaDashboardDefinition
.
Пример:
apiVersion: deckhouse.io/v1
kind: GrafanaDashboardDefinition
metadata:
name: my-dashboard
spec:
folder: My folder # Папка, в которой в Grafana будет отображаться ваш dashboard
definition: |
{
"annotations": {
"list": [
{
"builtIn": 1,
"datasource": "-- Grafana --",
"enable": true,
"hide": true,
"iconColor": "rgba(0, 211, 255, 1)",
"limit": 100,
...
Важно! Системные и добавленные через GrafanaDashboardDefinition dashboard нельзя изменить через интерфейс Grafana.
Как добавить алерты и/или recording правила для вашего проекта?
Для добавления алертов существует специальный ресурс — CustomPrometheusRules
.
Параметры:
groups
— единственный параметр, в котором необходимо описать группы алертов. Структура групп полностью совпадает с аналогичной в prometheus-operator.
Пример:
apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
name: my-rules
spec:
groups:
- name: cluster-state-alert.rules
rules:
- alert: CephClusterErrorState
annotations:
description: Storage cluster is in error state for more than 10m.
summary: Storage cluster is in error state
plk_markup_format: markdown
expr: |
ceph_health_status{job="rook-ceph-mgr"} > 1
Как подключить дополнительные data source для Grafana?
Для подключения дополнительных data source к Grafana существует специальный ресурс — GrafanaAdditionalDatasource
.
Параметры ресурса подробно описаны в документации к Grafana. Тип ресурса, смотрите в документации по конкретному datasource.
Пример:
apiVersion: deckhouse.io/v1
kind: GrafanaAdditionalDatasource
metadata:
name: another-prometheus
spec:
type: prometheus
access: Proxy
url: https://another-prometheus.example.com/prometheus
basicAuth: true
basicAuthUser: foo
jsonData:
timeInterval: 30s
httpMethod: POST
secureJsonData:
basicAuthPassword: bar
Как обеспечить безопасный доступ к метрикам?
Для обеспечения безопасности настоятельно рекомендуем использовать kube-rbac-proxy.
Как добавить Alertmanager?
Создайте custom resource CustomAlertmanager
с типом Internal
.
Пример:
apiVersion: deckhouse.io/v1alpha1
kind: CustomAlertmanager
metadata:
name: webhook
spec:
type: Internal
internal:
route:
groupBy: ['job']
groupWait: 30s
groupInterval: 5m
repeatInterval: 12h
receiver: 'webhook'
receivers:
- name: 'webhook'
webhookConfigs:
- url: 'http://webhookserver:8080/'
Подробно о всех параметрах можно прочитать в описании custom resource CustomAlertmanager.
Как добавить внешний дополнительный Alertmanager?
Создайте custom resource CustomAlertmanager
с типом External
, который может указывать на Alertmanager по FQDN или через сервис в Kubernetes-кластере.
Пример FQDN Alertmanager:
apiVersion: deckhouse.io/v1alpha1
kind: CustomAlertmanager
metadata:
name: my-fqdn-alertmanager
spec:
external:
address: https://alertmanager.mycompany.com/myprefix
type: External
Пример Alertmanager с Kubernetes service:
apiVersion: deckhouse.io/v1alpha1
kind: CustomAlertmanager
metadata:
name: my-service-alertmanager
spec:
external:
service:
namespace: myns
name: my-alertmanager
path: /myprefix/
type: External
Подробно о всех параметрах можно прочитать в описании Custom Resource CustomAlertmanager
Как в Alertmanager игнорировать лишние алерты?
Решение сводится к настройке маршрутизации алертов в вашем Alertmanager.
Потребуется:
- Завести получателя без параметров.
- Смаршрутизировать лишние алерты в этого получателя.
В alertmanager.yaml
это будет выглядеть так:
receivers:
- name: blackhole
# Получатель определенный без параметров будет работать как "/dev/null".
- name: some-other-receiver
# ...
route:
routes:
- match:
alertname: DeadMansSwitch
receiver: blackhole
- match_re:
service: ^(foo1|foo2|baz)$
receiver: blackhole
- receiver: some-other-receiver
С подробным описанием всех параметров можно ознакомиться в официальной документации.
Почему нельзя установить разный scrapeInterval для отдельных таргетов?
Наиболее полный ответ на этот вопрос даёт разработчик Prometheus Brian Brazil. Если коротко, то разные scrapeInterval’ы принесут следующие проблемы:
- Увеличение сложности конфигурации;
- Проблемы при написании запросов и создании графиков;
- Короткие интервалы больше похожи на профилирование приложения, и, скорее всего, Prometheus — не самый подходящий инструмент для этого.
Наиболее разумное значение для scrapeInterval находится в диапазоне 10-60 секунд.
Как ограничить потребление ресурсов Prometheus?
Чтобы избежать ситуаций, когда VPA запрашивает для Prometheus или Longterm Prometheus ресурсов больше чем есть на выделенном для этого узле, можно явно ограничить VPA с помощью параметров модуля:
vpa.longtermMaxCPU
vpa.longtermMaxMemory
vpa.maxCPU
vpa.maxMemory
Как получить доступ к метрикам Prometheus из Lens?
⛔ Внимание!!! Использование данной конфигурации создает сервис в котором метрики Prometheus доступны без авторизации.
Для обеспечения доступа Lens к метрикам Prometheus, необходимо создать в кластере ряд ресурсов.
После деплоя ресурсов, метрики Prometheus будут доступны по адресу lens-proxy/prometheus-lens-proxy:8080
.
Тип Prometheus в Lens — Prometheus Operator
.
Начиная с версии 5.2.7
, Lens требует наличия меток pod
и namespace
в метриках node-exporter’а.
В противном случае потребление ресурсов узла не будет отображаться на диаграммах Lens.
Чтобы исправить это, примените следующий ресурс:
Как настроить ServiceMonitor или PodMonitor для работы с Prometheus?
Добавьте лейбл prometheus: main
к Pod/Service Monitor.
Добавьте в namespace, в котором находится Pod/Service Monitor, лейбл prometheus.deckhouse.io/monitor-watcher-enabled: "true"
.
Пример:
---
apiVersion: v1
kind: Namespace
metadata:
name: frontend
labels:
prometheus.deckhouse.io/monitor-watcher-enabled: "true"
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: example-app
namespace: frontend
labels:
prometheus: main
spec:
selector:
matchLabels:
app: example-app
endpoints:
- port: web
Как увеличить размер диска
- Для увеличения размера отредактируйте PersistentVolumeClaim, указав новый размер в поле
spec.resources.requests.storage
.- Увеличение размера возможно если в StorageClass поле
allowVolumeExpansion
установлено вtrue
.
- Увеличение размера возможно если в StorageClass поле
- Если используемое хранилище не поддерживает изменение диска на лету, то в статусе PersistentVolumeClaim появится сообщение
Waiting for user to (re-)start a pod to finish file system resize of volume on node.
. - Перезапустите Pod для завершения изменения размера файловой системы.