Моніторинг сервісів з Prometheus

Prometheus

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


Prometheus   інструмент зовсім новий (перший публічний реліз відбувся в початку 2015 року), і на російською мовою публікацій про ньому поки що майже немає (кілька місяців тому була опублікована стаття в журналі «Хакер», але вона доступна тільки передплатникам).

Розробники SoundCloud відзначають (див. докладний доповідь тут), що новий інструмент моніторингу знадобився їм в згідно з переходом до микросервисной архітектурі. Зростання інтересу до микросервисам — одна з характерних тенденцій останніх декількох років.
З точки зору микросервисного підходу додаток пониматеся не як моноліт, а як набір сервісів. Кожен з цих сервісів працює у своєму процесі і взаємодіє з оточенням за допомогою простого механізму (як правило, через протокол HTTP).

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

Prometheus являє собою комплексне рішення, в складу якого входять і фреймворк для моніторингу, і власна темпоральна база даних. У деяких оглядах його навіть називають «системою моніторингу нового покоління».
Публікації про Prometheus нас зацікавили, і ми вирішили познайомитися з цим інструментом ближче.

Архітектура Prometheus

У склад Prometheus входять наступні компоненти:

  • сервер, який зчитує метрики і зберігає їх в темпоральних (time series) бази даних;
  • клієнтські бібліотеки для різних мов програмування (Go, Java, Python, Ruby; спільнотою також створені бібліотеки для Bash, Node.js, Haskell, .NET/C#);
  • Pushgateway   компонент для прийому метрик короткочасних процесів;
  • PROMDASH   дашборд для метрик;
  • інструменти для експорту даних з сторонніх додатків (Statsd, Ganglia, HAProxy і інших);
  • менеджер повідомлень AlertManager (на поточний момент перебуває на стадії бета-тестування);
  • клієнт командного рядка для виконання запитів до даними.


Більшість з них написані на Go, а зовсім невелика частина   на Ruby і Java.
Всі компоненти Prometheus взаємодіють між собою за HTTP:

Prometheus Architecture

Головний компонент всієї системи   сервер Prometheus. Він працює автономно і зберігає всі дані в локальній базі даних. Виявлення сервісів відбувається автоматично. Це спрощує процедуру розгортання: для спостереження за одним сервісом не потрібно розгортати розподілену систему моніторингу; достатньо лише встановити сервер і необхідні компоненти для збору та експорту метрик. Таких компонентів, «заточених» під конкретні сервіси, вже створено досить багато: для Haproxy, MySQL, PostrgreSQL та інші (повний список див. тут, а також GitHub).

Збір метрик в Prometheus здійснюється з допомогою механізму pull. Є також можливість збору метрик з допомогою механізму push (для цього використовується спеціальний компонент pushgateway, який встановлюється окремо). Це може знадобитися в ситуаціях, коли збір метрики з допомогою pull по тим чи іншим причинам неможливий: наприклад, при спостереженні за сервісами, захищеними фаерволлом. Також механізм push може виявитися корисним при спостереженні за сервісами, що підключаються до мережі періодично і на нетривалий час.

Prometheus добре підходить для збору і аналізу даних, представлених у вигляді часових рядів (time series). Всі метрики він зберігає в власної темпоральних БД (її порівняння з OpenTSDB і InfluxDB див. тут); для зберігання індексів використовується LevelDB.

Модель даних

Prometheus зберігає дані в вигляді часових рядів   наборів значень, співвіднесених з часовою міткою (timestamp).

Елемент тимчасового ряду (вимірювання) складається з імені метрики, тимчасової мітки і пари «ключ   значення. Тимчасові мітки мають точність до мілісекунд, значення представлені з 64-бітною точністю.

Ім'я метрики вказує на параметр системи, який збираються дані. Наприклад, у метрики з інформацією про кількості HTTP-запитів до якомусь API ім'я може виглядати так: api_http_requests_total. Часовий ряд у такий метриці може зберігати інформацію про про всіх GET-запити на адреса /api/tracks, які був відданий відповідь з кодом 200. Цей часовий ряд можна представити у вигляді наступної нотації:

api_http_requests_total{method="GET", endpoint="/api/tracks", status="200"}


Модель даних, яка використовується у Prometheus, нагадує ту, що використовується у OpenTSDB. У всіх метрик є ім'я, але воно може бути одним і  у кількох рядів.
При цьому кожен часовий ряд повинен бути позначений хоча б одним тегом. Вимірювання для одного тега зберігаються послідовно, що забезпечує швидку агрегацію даних.
Підтримуються наступні типи показників:

  • лічильник (counter)   зберігає значення, які збільшуються з плином часу (наприклад, кількість запитів до сервера);
  • шкала (gauge)   зберігає значення, які з плином часу можуть як збільшуватися, так і зменшуватися (наприклад, обсяг використовуваної оперативної пам'яті або кількість операцій вводу-виводу);
  • гістограма (histogram)   зберігає інформацію про зміну деякого параметра в протягом певного проміжку (наприклад, загальна кількість запитів до сервером період з 11 до 12 годин і кількість запитів до цьому ж серверів період з 11.30 до 11.40);
  • зведення результатів (summary)   гістограма, зберігає інформацію про зміни значення деякого параметра за часовий інтервал, але також дозволяє розраховувати квантили для ковзних тимчасових інтервалів.


Установка

Тепер розглянемо практичні аспекти використання Prometheus. Почнемо з опису процедури установки.
Зовсім недавно Prometheus був включений в офіційні репозиторії Debian 8 і Ubuntu 15.10.
У Ubuntu 14.04 його теж можна встановити за допомогою стандартного менеджера пакетів. Природно, для цього знадобиться підключити відповідний репозиторій:

$ echo 'deb http://deb.robustperception.io/ precise nightly' > /etc/apt/sources.list
$ wget https://s3-eu-west-1.amazonaws.com/deb.robustperception.io/41EFC99D.gpg 
$ sudo apt-key add 41EFC99D.gpg 
$ sudo apt-get update
$ sudo apt-get install prometheus node-exporter alertmanager


З допомогою наведених команд ми встановили сервер Prometheus, а також додаткові компоненти   node_exporter і alertmanager. Node_exporter збирає дані про стан сервера, а alertmanager (про ми більш докладно поговоримо нижче)   розсилає повідомлення у у разі виконання або невиконання заданих умов.

Установка завершена, але залишився ще один маленький штрих: потрібно зробити так, щоб node_exporter постійно збирав метрики в фоновому режимі. Для цього спочатку створимо символічне посилання в /usr/bin:

$ sudo ln -s ~/Prometheus/node_exporter/node_exporter /usr/bin


Потім створимо файл /etc/init/node_exporter.conf і додамо в нього наступні рядки:

# Run node_exporter

start on startup

script
/usr/bin/node_exporter
end script


Збережемо внесені зміни і виконаємо команду:

$ sudo service node_exporter start


У дистрибутивах, які перейшли на systemd (наприклад, в Ubuntu 15.10), для запуску node_exporter в фоновому режимі потрібно створити файл /etc/systemd/system/node_exporter.service додати в нього наступні рядки:

[Unit]
Description=Node Exporter

[Service]
ExecStart=/usr/sbin/node_exporter
Restart=Always

[Install]
WantedBy=default.target


Зберігши внесені зміни, потрібно виконати команди:

$ sudo systemctl enable node_exporter.service
$ sudo systemctl start node_exporter


Налаштування

Налаштувань Prometheus замовчуванням цілком достатньо, щоб стежити за всім, що відбувається на локальній машині. Додаткові налаштування у разі необхідності завжди можна прописати в конфігураційному файлі /etc/prometheus/prometheus.yml. Розглянемо його структуру більш докладно. Починається він з секції globals:

global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:


Вона включає наступні параметри:

  • scrape_interval   інтервал збору метрик (за замовчуванням — 15 секунд);
  • evaluation_interval   інтервал звірки з правилами (за замовчуванням — 15 секунд);
  • rule_files   файли правил (мова про них піде нижче).


Далі слід секція scrape_configs з базовими налаштуваннями збору метрик на сервері:

scrape_configs:
- job_name: "prometheus"
- scrape_interval: "15s"
target_groups:
- targets:
- "localhost:9090"


Вона включає наступні обов'язкові параметри:
  • job_name   ім'я завдання;
  • scrape_interval   інтервал збору метрик (в наведеному прикладі   кожні 15 секунд);
  • target_groups   сервіси і групи сервісів, для яких потрібно збирати метрики.


У цієї секції можна прописати додаткові параметри:

  • scrape_timeout   час очікування даних;
  • metrics_path   HTTP-ресурс, на який будуть передаватися метрики;
  • scheme   протокол, який буде використовуватися для передачі метрик;
  • basic_auth   реквізити для авторизації на сервері, з якого будуть збиратися метрики (username:, password:).


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

У загальному вигляді синтаксис правил можна представити так:

<ім'я тимчасового ряду>{мітки} = <параметр для запису>


Наведемо більш конкретні і зрозумілі приклади:

job:http_inprogress_requests:sum = sum(http_inprogress_requests) by (job)

new_time_series{label_to_change="new_value",label_to_drop=""} = old_time_series


Prometheus звіряється з правилами з певною періодичністю, зазначеної в конфігураційному файлі параметрі evaluation_interval). Після кожної звірки Prometheus перераховує значення параметра і зберігає його під новим ім'ям поточної тимчасовою міткою.
Отже, структуру і синтаксис конфігураційного файлу ми в загальних рисах розглянули. Щоб прописані налаштування вступили в силу, потрібно виконати наступну команду (замість path/to/prometheus.yml вказуємо шлях до конфігураційного файлу):

$ prometheus -config.file “path/to/prometheus.yml"


Веб-інтерфейс

Веб-інтерфейс Prometheus буде доступний в браузері за адресою: http://[IP-адреса сервера]:9090:

prometheus_web_interface

У полі Expression можна вибрати метрику, для якої буде відображатися графік. Спробуємо відстежити, наприклад, обсяг активної пам'яті на сервері. Вибираємо метрику node_memory_active і натискаємо на кнопку Execute:

node_memory_active
Над графіком розташовані кнопки, з допомогою яких можна вибирати період для відображення статистики.

Шаблони консолей

Основну консоль Prometheus ми тільки що розглянули. Для перегляду більш спеціалізованих графіків використовуються кастомні консолі.
На сервері зберігаються в директорії /еtc/prometheus/consoles. Кастомні консолі відображають загальну статистику сервера (node.html), статистику СPU (node-cpu.html), статистику операцій вводу-виводу на сервері (cpu-disk.html) і інші. У браузері вони доступні за адресою: http://[IP адреса сервера]:9090/consoles/<ім'я консолі>.html.
Ось так, наприклад, виглядає консоль node.html:

prometheus

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

Розробники Prometheus створили і власний інструмент для створення дашбордов під назвою Promdash (див. також репозиторій на GitHub, інтерфейсу нагадує Grafana. На наш погляд, він ще знаходиться в кілька «сирому» стані, і рекомендувати його до використання поки що рано.

Alertmanager: настройка повідомлень

Ні один інструмент моніторингу немислимий без компонента для розсилки повідомлень. У Prometheus для цієї мети використовується alertmanager. Налаштування повідомлень зберігаються в конфігураційному файлі alertmanager.conf.
Розглянемо наступний фрагмент:

notification_config {
name: "alertmanager_test"
email_config {
email: "test@example.org"
}

aggregation_rule {
notification_config_name: "alertmanager_test"
}


Його синтаксис цілком зрозумілий: ми вказали, що повідомлення при настанні певної умови потрібно надсилати електронною поштою на адреса test@example.org.

У конфігураційний файл можна додавати посилання на файли правил (за суті вони нічим не відрізняються від файлів правил для збору метрик, описаних вище). У правила прописуються умови, при яких потрібно відправляти повідомлення.

У загальному вигляді синтаксис правила виглядає так:

ALERT <ім'я перевірки>
IF <параметр і його значення>
FOR <період часу>
WITH <набір міток>>
SUMMARY "<короткий опис>"
DESCRIPTION "<зразок повідомлення>"


Розглянемо функції правил на більш конкретних прикладах.
Приклад 1:

ALERT InstanceDown
IF up == 0
FOR 5m
WITH {
severity="page"
}
SUMMARY "Instance {{$labels.instance}} down"
DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes."


Це правило вказує, що повідомлення потрібно відправляти в у разі, якщо певний інстанси недоступний в протягом 5 хвилин і більше.

Пример2:

ALERT ApiHighRequestLatency
IF api_http_request_latencies_ms{quantile="0.5"} > 1000
FOR 1m
SUMMARY "High request latency on {{$labels.instance}}"
DESCRIPTION "{{$labels.instance}} has a median request latency above 1s (current value: {{$value}})"


Згідно з цим правилом, треба посилати повідомлення, як тільки середній час відповіді на запити до API перевищить 1 мс.

Щоб прописані в конфігураційному файлі налаштування вступили в силу, потрібно зберегти його і виконати команду:

$ alertmanager -config.file alertmanager.conf


Можна створити кілька конфігураційних файлів і прописати в них налаштування сповіщень для різних випадків.

Повідомлення Prometheus відправляє в форматі JSON. Виглядають вони приблизно так:

{
"version": "1",
"status": "firing",
"alert": [
{
"summary": "summary",
"description": "description",
"labels": {
"alertname": "TestAlert"
},
"payload": {
"activeSince": "2015-06-01T12:55:47.356+01:00",
"alertingRule": "ALERT TestAlert IF absent(metric_name) FOR 0y WITH ",
"generatorURL": "http://localhost:9090/graph#%5B%7B%22expr%22%3A%22absent%28metric_name%29%22%2C%22tab%22%3A0%7D%5D",
"value": "1"
}
}
]
}


Відправка повідомлень здійснюється за електронною поштою, через веб-хук, а також з допомогою спеціалізованих сервісів: PagerDuty, HipChat та інших.
Розробники Prometheus відзначають, що поки що alertmanager знаходиться в «сирому» стані і попереджають про можливі помилки. Втім, ми ніяких аномалій у роботі цього компонента не помітили.

Висновок

Prometheus   інструмент досить цікавий і перспективний, і на нього варто звернути увагу. Серед його переваг слід в першу чергу виділити:

  • простоту розгортання;
  • широкі можливості інтеграції з сторонніми додатками і сервісами;
  • зручний графічний інтерфейс для роботи з метриками.


Якщо у вас вже є практичний досвід використання Prometheus, поділіться враженнями. Будемо вдячні за будь-які корисні зауваження і доповнення.

Для бажаючих дізнатися більше наводимо кілька корисних посилань:



Якщо ви з тих чи інших причин не можете залишати коментарі тут — запрошуємо наш блог.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.