Prometheus + kubernetes

Полезный набор дашбордов в графану по мониторингу ресурсов в кубе
https://github.com/camilb/prometheus-kubernetes

#grafana #prometheus #kubernetes #monitoring

Настраиваем jmx exporter для kafka в prometheus

исходные данные - есть докер с запущенной кафкой.

1) задаем конфиг /etc/jmx_exporter/config.yaml

---
startDelaySeconds: 3
hostPort: KAFKA_HOST:KAFKA_PORT
username:
password:
ssl: false
whitelistObjectNames: ["kafka.server:type=BrokerTopicMetrics,*"]
rules:
  - pattern: ".*"

2) запуск экспортера, либо в компоуз, либо отдельно, например так:

$ cat /etc/systemd/system/jmx_exporter.service
[Unit]
Description=jmx exporter
Requires=docker.service
After=docker.service

[Service]
Restart=always
RestartSec=3
ExecStartPre=/bin/sh -c "/usr/bin/docker rm -f jmx_exporter 2> /dev/null || /bin/true"
ExecStart=/usr/bin/docker run --rm -a STDIN -a STDOUT -a STDERR -v "/etc/jmx_exporter/config.yaml:/opt/jmx_exporter/config.yml" --name jmx_exporter -p "8081:5556" sscaling/jmx-prometheus-exporter
ExecStop=/usr/bin/docker stop jmx_exporter

[Install]
WantedBy=multi-user.target

3) в самой кафке, например в компоузе, нужно указать jmx endpoint
порты:

    ports:
      - "0.0.0.0:${KAFKA_ADVERTISED_PORT}:${KAFKA_ADVERTISED_PORT}"
      - "0.0.0.0:${KAFKA_JMX_PORT}:${KAFKA_JMX_PORT}"

и опцию JMX

      KAFKA_JMX_PORT: ${KAFKA_JMX_PORT}
      KAFKA_JMX_OPTS: -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=${KAFKA_ADVERTISED_HOST_NAME} -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=${KAFKA_JMX_PORT} -Dcom.sun.management.jmxremote.rmi.port=${KAFKA_JMX_PORT}

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

+ статья-пример, что можно взять для мониторинга из такого экспортёра: https://sematext.com/blog/kafka-metrics-to-monitor/#toc-network-request-rate-2

#kafka #prometheus

обоснование покупки PagerDuty (Может кому пригодится)

Для осуществления своевременной реакции на происходящие в инфраструктуре события и обеспечения SLA в клиентских сервисах предлагается осуществить покупку подписки на сервис PagerDuty. PagerDuty — это платформа для обработки инцидентов, которая умеет обрабатывать приходящие инциденты через различные интеграции, настраивать порядок дежурств и далее осуществлять уведомления дежурному инженеру в зависимости от уровня инцидента (при высоком уровне — звонок, при низком — push от приложения/смс). Решение от PagerDuty хорошо интегрируется с существующей системой мониторинга и обладает достаточным функционалом, отвечающим требованиям к подобным системам – надежность и точность доставки уведомлений до клиента.

Данный сервис позволит назначать по расписанию ответственных за сервисы компании, которые будут уведомляться о событиях несколькими способами – в том числе телефонным звонком для особо критичных ситуаций. В случае отсутствия реакции от ответственного лица будет происходить эскалация и уведомление дополнительного сотрудника. Такой способ позволит узнавать и решать проблемы с сервисами своевременно и всегда понимать какой сотрудник должен был работать над проблемой.

По каждой проблеме будет заводиться postmortem – отчет о происшествии, где будет описано что произошло, и что будет сделано чтобы избежать повторения инцидента. При этом поля отчета подкрепляются задачами в JIRA, с помощью которых в последствии можно будет контролировать насколько качественно команда реагирует на происшествия и как быстро их исправляет.

Наличие типовых событий позволяет описать список необходимых действий в confluence и прикреплять к событию ссылку на wiki и на связанные графики в Grafana, таким образом инженерам первой линии позволит быстрее погружаться в событие, анализировать и решать проблему.

Резюмируя вышесказанное, этот сервис позволяет своевременно реагировать на события, которые могут быть критичны для обеспечения работы бизнеса, собирать и хранить историю инцидентов для разбора произошедших событий с выводом их на timeline, и точно знать кто в данный момент должен заниматься проблемой.

#pagerduty #monitoring #alerting #prometheus

Очень полезный пост про то как мониторить аномалии

https://about.gitlab.com/blog/2019/07/23/anomaly-detection-using-prometheus/

#grafana #prometheus

Promql, как возвращать 0, если нет данных

Допустим вы складываете значения разных метрик, и в какой-то момент некоторая метрика не имеет данных. Тогда выражение no data + int = no data и испортит вам всю картину. чтобы такого избежать можно в выражению добавлять такую конструкцию: OR on() vector(0). Тогда no data -> 0 и сумма не портит ваши графички в графане

источник: https://medium.com/@Nklya/promql-how-to-return-0-instead-of-no-data-9e49f7ccb80d

#grafana #prometheus

Fortigate prometheus snmp config

Написал конфиг для prometheus snmp exporter для fortigate, fortianalyzer. Может кому пригодится. Конфиг включает в себя то что есть в заббиксовых темлпейтах под фортинет и еще сверху то что нам было интересно.

З.Ы. в стандартном чарте экспортера используется образ 2-летней давности в котором этот конфиг работать не будет. Обязатьно изменяйте в values версию до более современной. Протестировано на 18-й.

https://github.com/bykvaadm/prometheus_snmp_exporter/blob/master/Fortinet.yml

#prometheus #snmp #fortinet

snippet erb-скрипта подсчета числа обновлений для prometheus.

### MANAGED BY PUPPET
#!/bin/sh

prom_file="/var/prometheus/textfile_exporter/available_upgrades.prom"
current_id="$$"
updates="0"
echo '# HELP available_upgrades Number of available upgrades' >> "${prom_file}${current_id}"
echo '# TYPE available_upgrades gauge' >> "${prom_file}${current_id}"

<% if @facts['os']['name'] == "Debian" or @facts['os']['name'] == "Ubuntu" -%>
updates=$(apt list --upgradeable | grep -v 'Listing' | wc -l)
<% elsif @facts['os']['name'] == "CentOS" or @facts['os']['name'] == "RedHat" -%>
fuck_centos=$(yum list updates)
if echo ${fuck_centos}|grep -q 'Available Upgrades'; then
  updates=$($fuck_centos | awk '/Available Upgrades/{x=NR};{y=NR} END{printf y-x}')
fi
<% end -%>
echo "available_upgrades ${updates}" >> "${prom_file}${current_id}"
mv "${prom_file}${current_id}" "${prom_file}"

#puppet #prometheus

З.Ы. если кто ткнет носом как сделать поиск для центоси проще - тому большой лайк.

Конфиг prometheus сервера с хостами из consul шаблонизированный в jinja

global:
  scrape_interval: 10s
  scrape_timeout: 10s
remote_write:
  - queue_config:
      max_samples_per_send: 10000
      max_shards: 30
    url: {{ remote_write_url }}

rule_files:
{% for rulefile in (lookup('fileglob', '*.rules')).split(',') %}
- /etc/prometheus/{{ rulefile | basename }}
{% endfor %}

alerting:
 alertmanagers:
   - static_configs:
     - targets:
{% for host in groups[alertmanager_group] %}
       - {{ hostvars[host]['ansible_default_ipv4']['address'] }}:9093
{% endfor %}

{% set service_list=[] %}
{%- for k,v in consul_services.json.items() %}
{{ service_list.append(v.Service) }}
{%- endfor %}
scrape_configs:
{% for service in service_list | unique %}
- job_name: {{ service }}
  consul_sd_configs:
{% for tag in ['env1','env2','env3'] %}
  - server: {{ consul_url | replace("http://", "") }}
    tags: [ {{ tag }} ]
    services: [ {{ service }} ]
{% endfor %}
{% endfor %}

consul_services - переменная получаемая таском:

- name: Fetch consul services
  uri:
    url: "{{ consul_url }}/v1/agent/services?filter=prometheus+in+Tags"
    body: json
  register: consul_services
  changed_when: false
  check_mode: no

#consul #ansible #prometheus #jinja

Настройка Heartbeat для проверки работы системы мониторинга

Расскажу на примере prometheus, alertmanager, opsgenie.

opsgenie:
0) создаем команду
1) по адресу https://app.opsgenie.com/settings/heartbeat создаем хартбит по нужным вам параметрам (severity, на кого повесить, описание). Запоминаем имя (далее ${name})
2) идем в интеграции, создаем для prometheus - именуем, назначаем команду, получаем api ключ.
https://app.opsgenie.com/settings/integration/integration-list (далее ${opsgenie_api_key})

alertmanager.yml:

receivers:
- name: deadmansswitch
  webhook_configs:
  - url: https://api.opsgenie.com/v2/heartbeats/${name}/ping
    send_resolved: true
    http_config:
      basic_auth:
        password: ${opsgenie_api_key}
route:
  group_by:
  - job
  group_interval: 5m
  group_wait: 10s
  receiver: default
  repeat_interval: 1m
  routes:
  - receiver: deadmansswitch
    match:
      severity: DeadMansSwitch
    repeat_interval: 1m

prometheus.yml -> далее если у вас правила вынесены в отдельный файл, если нет, ну, сами поправите)

...
rule_files:
- /etc/prometheus/prometheus.rules 
...

prometheus.rules:

groups:
- name: prometheus.alerts.rules
  rules: 
  - alert: PrometheusAlertmanagerE2eDeadManSwitch
    expr: vector(1)
    for: 5m
    labels:
      severity: DeadMansSwitch
    annotations:
      summary: "Prometheus AlertManager E2E dead man switch (instance {{ $labels.instance }})"
      description: "Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"

Как это работает:
1) в течение 5 минут прометей проверяет выражение vector(1), которое всегда будет отдавать 1, а значит фейлиться.
2) через 5 минут (а затем еще каждую минуту) он будет пиннать алертменеджер и говорить что есть проблема.
3) Алертменеджер будет долбиться раз в минуту на специальный урл opsgenie.
4) В настройках хартбита вы выставляете время которое считаете нормальным для того чтобы система оповещения лежала. и далее ход конём:
5) если у вас погиб прометей (или сеть до алертменеджера), он не будет долбить алертменеджер и рефрешить гарантированный алерт. в таком случае автоматически происходит разрезолв алерта (по-умолчанию 5 минут) и перестают посылаться сообщения на урл из п.3. Тогда по истечению таймаута из п4. на вашу команду упадет алерт о том что хартбит просрочен.
6) если у вас умер алертменеджер (или связность до апи opsgenie), то по истечению таймаута из п4. на вашу команду упадет алерт о том что хартбит просрочен.

т.о. такая связка гарантирует что вся цепочка от мониторинга до алертменеджера и апишки opsgenie находится в работоспособном состоянии

Источник знаний:
- https://t.me/metrics_ru
- https://docs.opsgenie.com/docs/heartbeat-api
- https://github.com/prometheus/alertmanager/pull/444#issuecomment-428493861

#prometheus #opsgenie #alertmanager

Мониторим kubernetes

Часть1: The Node Metrics

Часть2: The USE Method and node_exporter Metrics

Часть3: Container Resource Metrics

Часть4: The Kubernetes API Server

Часть5: etcd metrics

Часть6: kube-state-metrics

#prometheus #kubernetes

Делаем резервные копии postgres на s3 (minio)

В гисте приложен кусочек плейбука ansible который настраивает резервное копирование через mc клиент. скрипт умеет выгружать в bucket по-отдельности каждую базу из списка, оценивать размер и время совершения последнего копирования каждой базы и отдавать эту информацию в формате prometheus, а также подчищать из s3 устаревшие копии.

https://gist.github.com/bykvaadm/434a4eef5392528c9c0e4788937301bc

#postgres
#docker
#patroni
#ansible
#minio
#prometheus

Мониторинг postgres

Зацепил тут взглядом недавно прикольный экспортёр для postgresql/patroni/pgbouncer/os-metrics

в общем не экспортёр, а целый комбаин. Понравился тем что умеет по полочкам разложить какой пользователь сколько проводит временив запросах, какие конкретно запросы вызывают наибольшее время, а какие самые частые, в какую таблицу с какой частотой выполняются селекты-инсерты и многое другое. Попутно написал для этой штуки маленькую ансибловую роль. Попробуйте и обязательно поставьте автору звёздочку на гитхабе =)

ansible role:
https://github.com/bykvaadm/ansible-pgscv

pgscv github repo:
https://github.com/weaponry/pgscv

grafana dashboard
https://grafana.com/grafana/dashboards/14540

wiki
https://github.com/weaponry/pgscv/wiki

habr
https://habr.com/ru/post/559550/

#postgresql #prometheus