Translate

понеділок, 15 жовтня 2018 р.

Prometheus. From Metrics To Insight

Prometheus  - моніторингова система з відкритим вихідним кодом,  була створена та розроблялась в компанії Soundcloud з 2012, а в 2015 році представлена публічно і наразі розвивається незалежно.

Переважно написана на мові Go колишніми співробітниками компанії Google. Прототипом Prometheus виступала моніторингова система Borgmon. Ця моніторингова система має наступні переваги/недоліки/особливості:

  • багатовимірну модель даних, з часовими рядами, що ідентифікуються назвою метрики та парою ключ/значення;
  • гнучку мову запитів, що використовує цю модель;
  • pull-модель роботи серверу, збирання даних відбувається опитуванням вузлів, що моніторяться, по протоколу HTTP (хоча існує також Pushgateway, що працює по push-моделі і призначений для збирання метрик з недовговічних вузлів);
  • відсутність залежності від розподілених віддалених сховищ; кожен вузол Prometheus є автономним;
  • об'єкти моніторингу можуть додаватись вручну до основного конфігураційного файлу Prometheus чи автоматично через service discovery (Consul, API/теги AWS, GCP, Kubernetes, Openstack та інші).

Як вже було згадано, Prometheus - це моніторингова система, що працює за pull-моделлю. Тобто сервер опитує власноруч кожен вузол, що потребує моніторингу. На думку авторів проекту, така модель дещо краща за push-модель (коли метрики відправляються самостійно на сервер моніторингу без жодних запитів). Чудовим прикладом останньої є Sensu, про яку я вже писав декілька років тому.

Prometheus - модульна моніторингова система, її підсистеми за потреби можуть бути замінені на альтернативні. Проте основні елементи Prometheus наступні:

  • Prometheus server (Web UI/API, TSDB) - основний сервер моніторингу, запитує та зберігає всі метрики від клієнтів, надає базову веб-панель запитів та API
  • Exporters - компоненти, що виступають джерелом даних для Prometheus сервера. Зазвичай працюють на стороні клієнта, але є і вийнятки, наприклад, Blackbox exporter. Є купа готових як офіційних, так і сторонніх рішень для збирання метрик з MySQL, RabbitMQ та ін.
  • Alertmanager - підсистема, що забезпечує групування, стримування, дедуплікацію, маршрутизацію повідомлень від систем на зразок серверу Prometheus. Також має базову веб-панель, де можна відфільтрувати повідомлення, призупинити їх надсилання при певних умовах та ін.
  • Pushgateway - служба-посередник, що на відміну від Prometheus server, отримує метрики від вузлів і вже потім пересилає їх на основний сервер. Не обов'язковий компонент, але може бути корисний у разі моніторингу сервісів із коротким життєвим циклом чи програм, що не надають відкритий порт для отримання метрик основним сервером.
  • Grafana - веб-панель на Go/NodeJS для побудови та відображення метрик. Вміє працювати з Prometheus "із коробки".


Окрім цього Prometheus може напряму моніторити Kubernetes кластери.

Замість власної бази для метрик Prometheus може використовувати сторонні: деякі лише на запис (тобто ретрансляцію даних до сторонньої бази) чи одночасно на запис і читання (наприклад, InfluxDB).

Всі пакети Prometheus можна знайти в офіційних репозиторіях Ubuntu починаючи з версії 16.04, для попередніх LTS версій можна скористатись сторонніми неофіційними, наприклад цими https://github.com/jtyr/prometheus-deb чи цими http://deb.robustperception.io/. Проте тут можуть бути не останні релізи, тому ми будемо запускати бінарні файли з репозиторіїв проекту на Github. Список останніх версіх усіх офіційних компонентів Prometheus можна знайти на офіційному сайті.

У цій статті буде розглянута інсталяція всіх компонентів Prometheus на один хост, але вони можуть бути з легкістю рознесені на групу серверів. У якості операційної системи було обрано Ubuntu 16.04.


1. INSTALLATION OF PROMETHEUS SERVER


Завантажуємо та розпакуємо архів із останнім релізом сервера:

# wget https://github.com/prometheus/prometheus/releases/download/v2.4.3/prometheus-2.4.3.linux-amd64.tar.gz
# tar xvzf prometheus-2.4.3.linux-amd64.tar.gz

Створимо користувача від імені якого буде працювати сервіс:

# adduser --no-create-home --disabled-login --shell /bin/false --gecos "Prometheus Monitoring User" prometheus

Та необхідні директорії для розміщення файлів програми:

# mkdir /etc/prometheus /var/lib/prometheus

Скопіюємо вже розпаковані файли архіву:

# cp prometheus-2.4.3.linux-amd64/prometheus prometheus-2.4.3.linux-amd64/promtool /usr/local/bin/
# cp -r prometheus-2.4.2.linux-amd64/consoles prometheus-2.4.2.linux-amd64/console_libraries /etc/prometheus

І нарешті виставимо коректні права:

# chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

Опишемо конфігураційний файл серверу Prometheus:

# vim /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']

Було вказано глобальний інтервал збору метрик кожні 15 секунд у разі, якщо інший не задекларовано нижче для кожної конкретної задачі. У секції scrape_configs поки лише додана задача моніторингу самого себе (job_name: 'prometheus'), де інтервал було знижено до 5 секунд.

Створимо файл запуску програми systemd, додамо Prometheus до автозавантаження та запустимо:

# vim /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
    --config.file /etc/prometheus/prometheus.yml \
    --storage.tsdb.path /var/lib/prometheus/ \
    --web.console.templates=/etc/prometheus/consoles \
    --web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable prometheus
# systemctl start prometheus
# systemctl status prometheus

Після чого на порту 9090 буде запущено Web UI Prometheus:


Перевіримо список вузлів, що вже моніторятся (targets в термінології Prometheus). Тут поки має бути описаний лише один сервер:


Одразу після установки в сервера можна запросити деякі дані, наприклад, кількість відкритих файлових дескрипторів:



Хорошим тоном є завжди вказувати ім'я задачі ({job="prometheus"}), що безпосередньо стосується запиту. Він збігається із job_name зі scrape_configs секції основного файлу конфігурації Prometheus.

Як я вже говорив, однією із переваг Prometheus над іншими системами моніторингу є гнучка мова запитів, що дозволяє не лише демонструвати дані часових серій, а й виконувати логічні функції над ними. Це дуже зручно для правильної інтерпретації даних, що саме відбувається із системами. Для більшого розуміння можливостей логічних функцій рекомендую переглянути наступні статті одного із основних розробників Prometheus:

How To Query Prometheus on Ubuntu 14.04 Part 1
How To Query Prometheus on Ubuntu 14.04 Part 2

та отримати нормальну математичну освіту.


2. INSTALLATION OF NODE EXPORTER


Node Exporter - це сервер надання та збору базових метрик операційної системи, серед яких, наприклад, детальна статистика роботи процесора, пам'яті, дисків, мережевої системи і купа всього іншого. Всі перевірки діляться на ті, що увімкнені по замовчуванню та котрі необхідно активувати за потреби.

Аналогічно завантажимо останній реліз Node Exporter з офіційного Github-у проекту, розпакуємо архів, створимо окремого користувача, скопіюємо необхідні файли та виставимо коректні права для роботи:

# adduser --no-create-home --disabled-login --shell /bin/false --gecos "Node Exporter User" node_exporter
# wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-0.16.0.linux-amd64.tar.gz
# tar xvzf node_exporter-0.16.0.linux-amd64.tar.gz
# cp node_exporter-0.16.0.linux-amd64/node_exporter /usr/local/bin/
# chown node_exporter:node_exporter /usr/local/bin/node_exporter

Створимо systemd файл запуску для Node Exporter:

# vim /etc/systemd/system/node_exporter.service

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Якщо кількість перевірок за замовчуванням здається надлишковою, ExecStart параметр можна відредагувати на наступний:

ExecStart=/usr/local/bin/node_exporter --collectors.enabled meminfo,loadavg,filesystem

У такому разі будуть активовані лише збори метрик по пам'яті, завантаженню та файловій системі. Тут є повний список можливих опцій.

Додамо новий сервіс в автозавантаження та запустимо:

# systemctl daemon-reload
# systemctl enable node_exporter
# systemctl start node_exporter
# systemctl status node_exporter

Щоб статистика, котру надає Node Exporter, збиралась Prometheus-ом, його потрібно додати до секції scrape_config у якості нового задачі:

# vim /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9100']

Після змін конфігураційних файлів Prometheus, його необхідно перевантажувати. Тепер у web-панелі Prometheus має з'явитись новий target та нові метрики:



Статистику, що надає Node Exporter також можна побачити в браузері на 9100 порту вузла, де його було запущено (і це стосується не лише Node Exporter-а):


Цей Exporter надає базові метрики роботи операційної системи, тому логічно буде проінсталювати його на кожен сервер. Із появою нових вузлів секція задачі node_exporter серверу Prometheus має бути доповнена:

# vim /etc/prometheus/prometheus.yml
...
  - job_name: 'node_exporter'
    scrape_interval: 5s
    static_configs:
      - targets:
        - localhost:9100
        - second-server:9100
        - third-server:9100

Або ж для цього може бути використаний discovery сервіс Consul.


3. INSTALLATION OF BLACKBOX EXPORTER


Blackbox exporter дозволяє генерувати метрики роботи HTTP(S), DNS, TCP та ICMP серверів/сервісів. Цей експортер можна встановити як на окремому сервері, так і на тому ж головному сервері Prometheus (так ми і зробимо), адже перевіряє він віддалені, зазвичай доступні всім вузлам мережі, ресурси.

Спершу завантажимо останній реліз експортеру, розпакуємо його та скопіюємо бінарний файл до /usr/local/bin/:

# wget https://github.com/prometheus/blackbox_exporter/releases/download/v0.12.0/blackbox_exporter-0.12.0.linux-amd64.tar.gz
# tar xvzf blackbox_exporter-0.12.0.linux-amd64.tar.gz
# cp blackbox_exporter-0.12.0.linux-amd64/blackbox_exporter /usr/local/bin/

Створимо окремого користувача blackbox_exporter, без можливості логінитись на сервер і домашньої директорії:

# adduser --no-create-home --disabled-login --shell /bin/false --gecos "Blackbox Exporter User" blackbox_exporter

Створимо директорію для збереження конфігурації Blackbox exporter та опишемо конфігурацію для нього:

# mkdir /etc/blackbox
# vim /etc/blackbox/blackbox.yml

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [] # Defaults to 2xx
      method: GET
      preferred_ip_protocol: ip4

Отже ми створили новий модуль http_2xx, що по http-протоколу (prober у термінології експортера) буде опитувати вузли, котрі ми опишемо пізніше в основному конфігураційному файлі prometheus.yml. Він вважатиме, що вузли працюють коректно, якщо у разі GET-запиту вузол віддаватиме 200-ті коди повернення. Це досить примітивний приклад використання даного експортеру, проте для прикладу згодиться. У разі ж додаткової зацікавленості пропоную ознайомитись із цим прикладом конфігурації.

Установимо коректні права на новостворені директорії для Blackbox Exporter:

# chown -R blackbox_exporter:blackbox_exporter /etc/blackbox
# chown blackbox_exporter:blackbox_exporter /usr/local/bin/blackbox_exporter

Щоб сервіс було зручно запускати/зупиняти опишемо для нього systemd конфігурацію:

# vim /etc/systemd/system/blackbox_exporter.service

[Unit]
Description=Prometheus blackbox exporter
After=network.target auditd.service

[Service]
User=blackbox_exporter
Group=blackbox_exporter
Type=simple
ExecStart=/usr/local/bin/blackbox_exporter --config.file=/etc/blackbox/blackbox.yml
Restart=on-failure

[Install]
WantedBy=default.target

І додамо в автозапуск та завантажимо:

# systemctl daemon-reload
# systemctl enable blackbox_exporter
# systemctl start blackbox_exporter
# systemctl status blackbox_exporter

Створимо нову задачу на сервері Prometheus:

# vim /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://prometheus.io/
        - http://localhost:8080

    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115 # The blackbox exporter's real hostname:port.

На порту 8080 серверу localhost має бути запущено веб-сервер, який можна встановити та налаштувати використовуючи будь яку з наступних утиліт https://gist.github.com/willurd/5720255, наприклад:

$ echo "<h1>Say hello to Prometheus</h1>" > index.html
$ nohup busybox httpd -f -p 8080 &

Після перевантаження серверу Prometheus зможемо спостерігати нові target-и та метрики опитування перелічених вище веб-ресурсів:




4. ALERTING


4.1. Installation Of Alertmanager


Alertmanager - компонент оповіщення моніторингової системи Prometheus. Інсталяція аналогічна іншим компонентам:

# wget https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz
# tar xvzf alertmanager-0.15.2.linux-amd64.tar.gz

Скопіюємо щойно розархівовані бінарні файли:

# cp alertmanager-0.15.2.linux-amd64/alertmanager /usr/local/bin/
# cp alertmanager-0.15.2.linux-amd64/amtool /usr/local/bin/

Створимо однойменного користувача для нового компоненту:

# adduser --no-create-home --disabled-login --shell /bin/false --gecos "Alertmanager User" alertmanager

Та створимо директорії для майбутніх конфігураційних файлів:

# mkdir -p /etc/alertmanager/{data,template}

Виставимо нового власника файлів:

# chown alertmanager:alertmanager /usr/local/bin/alertmanager /usr/local/bin/amtool
# chown -R alertmanager:alertmanager /etc/alertmanager

Створимо базову конфігурацію Alertmanager, що відправлятиме повідомлення на пошту (у даному випадку приведена конфігурація відправлень через поштовий сервіс Gmail) у разі появи проблем:

# vim /etc/alertmanager/alertmanager.yml

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'somebody@gmail.com'
  smtp_auth_identity: 'somebody@gmail.com'
  smtp_auth_username: 'somebody@gmail.com'
  smtp_auth_password: 'my_hard_password'

route:
  group_by: ['instance', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: team-1

receivers:
  - name: 'team-1'
    email_configs:
    - to: 'my_company_email@company.team'

Отже, нові повідомлення будуть групуватись на протязі 30 секунд (параметр group_wait) по полям instance та severity і будуть відправлятись одним листом команді team-1 з поштою my_company_email@company.team використовуючи smtp параметри, що приведені в секції global. При появі нових повідомлень в тій же групі Alertmanager через 5 хв (group_interval) відправить нове повідомлення.

Надалі, якщо нові повідомлення в групі з'являтись не будуть і проблеми будуть не вирішені, попередні повідомлення будуть дублюватись із частотою раз в 3 години (параметр repeat_interval). Із однієї сторони це буде вносити затримки в швидкість інформування про наявні проблеми, а з іншої це зменшить головний біль від неймовірної кількості повідомлень у разі падіння якогось із вузлів/сервісів. Гарний приклад конфігурації з купою можливих опцій як завжди можна знайти в офіційному репозиторії та документації.

Окрім повідомлень на пошту, Alertmanager підтримує і інші варіанти сповіщень, серед яких Slack, Hipchat, PagerDuty та інші.

Нарешті створимо systemd скрипт для запуску Alertmanager та запустимо та додамо його в автозавантаження:

# vim /etc/systemd/system/alertmanager.service

[Unit]
Description=Prometheus Alert Manager service
Wants=network-online.target
After=network.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --storage.path /etc/alertmanager/data
Restart=always

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable alertmanager
# systemctl start alertmanager
# systemctl status alertmanager


4.2. Connecting Alertmanager to Prometheus and creating new alerting rule 


Створимо перше правило перевірки роботи вузлів:

# vim /etc/prometheus/alert.rules.yml

groups:
- name: alert.rules
  rules:
  - alert: EndpointDown
    expr: probe_success == 0
    for: 10s
    labels:
      severity: "critical"
    annotations:
      summary: "Endpoint {{ $labels.instance }} down"

Якщо змінна probe_success, що потрапить до Prometheus сервера, буде рівна 0 (перевірка вузла не зможе бути виконана) на протязі 10 секунд, буде створено оповіщення, що буде направлено до сервером моніторингу до Alertmanager.

Кожні нові правила перед застосовуванням, завдяки утиліти promtool, можна перевірити в командному рядку:

# promtool check rules /etc/prometheus/alert.rules.yml
Checking /etc/prometheus/alert.rules.yml
  SUCCESS: 1 rules found

Цей список правил та адреса Alertmanager-а має бути описана в основному конфігураційному файлі Prometheus, після чого зміни будуть застосовані після перезавантаження серверу моніторингу:

# vim /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s

rule_files:
  - alert.rules.yml

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']
...

# systemctl restart prometheus

Для отримання нового сповіщення, зупинимо раніше запушений веб-сервер:

# killall busybox

З часом Prometheus помітить проблему:


І надішле її сервісу Alertmanager:


Останній, використовуючи описані в alertmanager.yml правила маршрутизації повідомлень, надішле необхідні оповіщення. У нашому випадку на пошту:


Для перегляду усіх активних сповіщень Alertmanager можна скористуватись консольною утилітою amtool:

$ amtool alert query --alertmanager.url http://localhost:9093

Alertname     Starts At                Summary                           
EndpointDown  2018-10-14 17:44:46 EDT  Endpoint http://localhost:8080 down

Окрім того з її допомогою можна призупинити отримання повідомлень, фільтрувати оповіщення в залежності від проблемного вузла, додавати коментарі до власних дій і т.п., наприклад:

$ amtool silence add instance=http://localhost:8080 --duration 3h  --author "John Doe" --comment "Investigating the progress" --alertmanager.url http://localhost:9093

Звісно, це ж саме можна зробити і у веб-панелі Alertmanager, що працює на 9093 порту.


4.3. Installing Karma (alerting panel)


Опціонально можна спробувати панель Karma, вона більш наочно демонструє всі доступні сповіщення Alertmanager, має деякі додаткові функції і може чудово підійти для демонстрації на великих моніторах.

# wget https://github.com/prymitive/karma/releases/download/v0.14/karma-linux-amd64.tar.gz
# tar xvfz karma-linux-amd64.tar.gz
# cp karma-linux-amd64 /usr/local/bin/karma

# adduser --no-create-home --disabled-login --shell /bin/false --gecos "Karma for Alertmanager" karma

# chown karma:karma /usr/local/bin/karma

Ну і як завжди опишемо сервіс в systemd та додамо його в автозавантаження:

# vim /etc/systemd/system/karma.service

[Unit]
Description=Karma Panel for Alertmanager
After=network.target auditd.service

[Service]
User=karma
Group=karma
Type=simple
ExecStart=/usr/local/bin/karma --alertmanager.uri http://localhost:9093
Restart=on-failure

[Install]
WantedBy=default.target

# systemctl daemon-reload
# systemctl enable karma
# systemctl start karma
# systemctl status karma

Онлайн демо можна знайти за посиланням https://karma-demo.herokuapp.com/



5. INSTALLATION OF GRAFANA


Grafana - чудова веб-панель для демонстрації графічних даних. Досить давно я писав про неї у якості фронтенда до Graphite. Наразі вона стала ще більш універсальною і навчилась напряму працювати з Promtheus. Установимо її і додамо до автозавантаження:

# echo 'deb https://packagecloud.io/grafana/stable/debian/ stretch main' > /etc/apt/sources.list.d/grafana.list
# curl https://packagecloud.io/gpg.key | apt-key add -
# apt update
# apt install grafana -y

# systemctl daemon-reload
# systemctl enable grafana-server
# systemctl start grafana-server

Логінимось в Grafana за 3000 портом та додаємо нове джерело даних для time series:





6. SENDING DATA TO GRAPHITE (WRITE REMOTE STORAGE)


Загалом в цій моніторинговій системі є мінус - вона, як і багато інших, не призначена для дійсно тривалого зберігання метрик (мається на увазі роки). У базі даних Prometheus немає вбудованого rollup/storage aggregation, тобто він не може зменшувати точність для старіших даних. Чим більше даних - тим більш неповоротким ставатиме Prometheus і тим більше розпухатиме диск.

Власне нічого критичного в цьому немає і з цим можна жити. Як обхідний шлях можна скористатись можливістю ретранслювати дані Prometheus в віддалений інстанс Graphite. Для цього необхідно скомпілювати remote_storage_adapter:

# add-apt-repository ppa:gophers/archive
# apt update
# apt install golang-1.10-go

# export PATH=$PATH:/usr/lib/go-1.10/bin
# go version
go version go1.10 linux/amd64

# mkdir -p github.com/prometheus
# git clone https://github.com/prometheus/prometheus.git github.com/prometheus/prometheus
# go get -d -v github.com/prometheus/prometheus/documentation/examples/remote_storage/remote_storage_adapter
# go build github.com/prometheus/prometheus/documentation/examples/remote_storage/remote_storage_adapter

remote_storage_adapter після запуску стане доступним для підключень по 9201 порту:

# chmod +x remote_storage_adapter
$ nohup ./remote_storage_adapter -graphite-address=graphite-carbon-host:2003 &

Звісно також не завадить описати цей процес в systemd. Додамо опцію в prometheus.yml для записів в remote_storage_adapter:

# vim /etc/prometheus/prometheus.yml
...
remote_write:
  - url: "http://localhost:9201/write"
...

Після чого необхідно перевантажити Prometheus.
Якщо ж в Graphite стеку у якості демона збору метрик працює carbon-clickhouse (тобто стек із ClickHouse OLAP базою всередині), то метрики Prometheus можна одразу пересилати на його віддалений 2006 порт. Відповідно remote_storage_adapter не буде потрібний.

Стороння реалізація remote_storage_adapter підтримує як читання так і запис із Graphite, і має підтримку тегів.

Окрім Graphite, у якості віддаленого місця зберігання (а іноді і читання) метрик можна звісно використовувати і інші рішення, на зразок того ж InfluxDB, PostgreSQL, Kafka та інші.


Посилання:
https://gist.github.com/petarGitNik/18ae938aaef4c4ff58189df8a4fc7de9
https://www.digitalocean.com/community/tutorials/how-to-install-prometheus-on-ubuntu-16-04
https://www.digitalocean.com/community/tutorials/how-to-use-alertmanager-and-blackbox-exporter-to-monitor-your-web-server-on-ubuntu-16-04
https://rahulwa.com/post/monitoring-using-prometheus/
https://www.digitalocean.com/community/tutorials/how-to-query-prometheus-on-ubuntu-14-04-part-1
https://www.digitalocean.com/community/tutorials/how-to-query-prometheus-on-ubuntu-14-04-part-2
https://habr.com/post/308610/
https://github.com/line/promgen
https://habr.com/company/selectel/blog/275803/
https://github.com/prometheus/alertmanager/blob/master/doc/examples/simple.yml
https://www.robustperception.io/sending-email-with-the-alertmanager-via-gmail
https://prometheus.io/docs/alerting/configuration/
https://www.slideshare.net/brianbrazil/prometheus-overview
https://www.slideshare.net/brianbrazil/prometheus-and-docker-docker-galway-november-2015
https://www.percona.com/live/e17/sessions/using-prometheus-with-influxdb-for-metrics-storage

Немає коментарів:

Дописати коментар