Prometheus — практичне використання

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

image
На щастя, існує безліч розв'язків задачі моніторингу, як платних, так і безкоштовних. Я ж хочу поділитися досвідом практичного використання open source системи моніторингу Prometheus.

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

Мінімальна конфігурація системи моніторингу Prometheus складається з сервера Prometheus і відстежує програми, достатньо лише вказати за якою адресою необхідно запитувати метрики. Збір метрик виконується згідно pull-моделі по протоколу HTTP, але існує і push-gateway компонент для стеження за короткоживущими сервісами. При використанні pull-моделі Ваші програми не знають про систему моніторингу, а значить можна запускати кілька серверів Prometheus для моніторингу, тим самим застрахувавшись від можливих втрат даних. Для підготовки додатків до подальшого моніторингу пропонується використовувати клієнтські бібліотеки, реалізують необхідний інструментарій для створення та висновку метрик для різних мов. Рекомендується використовувати саме їх, але при цьому Ви можете застосувати свою реалізацію, якщо вона буде відповідати специфікації exposition formats.

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

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

Для фільтрації та перетворення метрик використовується дуже зручний мова запитів. На жаль, відсутня можливість зберегти сформований запит безпосередньо через web-інтерфейс. Для цього потрібно створювати консоль, що представляє собою html-сторінку, з можливістю використання Go-templates, і вже в ній будувати графіки, таблиці, зведення і т. д.

Хорошим рішенням буде створення узагальнених консолей. Наприклад, необхідно моніторити кілька HTTP-серверів. Кожен з них має метрику, наприклад, «http_requests_total», що показує кількість прийнятих HTTP-запитів. Створимо консоль, що відображає список таких сервісів у вигляді посилань на консолі з більш детальною інформацією:

{{ range query "sum(http_requests_total) by (instance)" | sortByLabel "instance" }}
<a href="/consoles/job-overview.html?instance={{ .Labels.instance }}">{{ .Labels.job }}</a>
{{ end }}

В результаті, ми отримаємо список з посиланнями на консоль «job-overview.html», в яку передається параметр «instance». Тепер цей параметр можна використовувати в якості фільтра для побудови графіків:

new PromConsole.Graph({
node: document.querySelector("#successGraph"),
expr: [
"sum(http_requests_success{instance='{{ .Params.instance }}' })"
],
name: http_requests_success,
})

Як джерело додаткових прикладів можна використовувати стандартний набір консолей.

Продуктивність
стверджують розробники, один сервер Prometheus може з легкістю обслуговувати мільйони time-series. Цього достатньо для збору даних з тисячі серверів з інтервалом в 10 секунд. У випадках же, коли цього недостатньо — передбачена можливість масштабування.

На практиці заявлена продуктивність підтверджується. При моніторингу 800 сервісів, близько 80 метрик в кожному, Prometheus використовує близько 6% одного ядра і 3 GB RAM, а зібрані за 15 днів метрики займають 17 GB пам'яті на диску. Не обов'язково виділяти для Prometheus окремий сервер, з таким незначним споживанням ресурсів він може бути встановлений поряд з іншими сервісами не приносячи ніяких незручностей.

Prometheus зберігає зібрані метрики в оперативній пам'яті і при досягненні ліміту за розміром, або за закінченні певного інтервалу часу, зберігає їх на диск. У випадках, коли доводиться збирати велику кількість даних (більше 100к time series, наприклад) може зрости навантаження на диск. В документації Prometheus наводяться корисні поради оптимізації в таких випадках.

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

Кастомізація
Відверто кажучи, web-інтерфейс здався мені трохи сируватим". При роботі з графіками, метриками, розділом спостережуваних сервісів (/targets) виникала необхідність додаткового функціоналу. З цим не виникло жодних проблем, і, незабаром, я додав можливість швидкого пошуку по тегах метрик, а так само змінив layout розділу консолей. Коли розділ /targets збільшився до 800 сервісів — довелося приховати эндпоинты на сторінці, об'єднавши їх в групи (інакше вони займали дуже багато місця). Коли якийсь із эндпоинтов перестає нормально працювати, то до групи додається іконка, повідомляти про помилку. Розгорнувши аркуш, можна знайти проблемний эндпоинт та дізнатися детальну інформацію про помилку:

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

Додаткове
Команда розробників Prometheus створює максимально відкритий для інтеграції проект, який можна використовувати спільно з іншими технологіями, а ком'юніті всіляко намагається допомогти у цьому. На сайті Prometheus Ви зможете знайти перелік підтримуваних exporters — пакетів, що знімають метрики з інших сервісів і технологій. Ми використовуємо тільки деякі: node_exporter, postgres_exporter і grok_exporter. Для них побудовані узагальнені консолі, графіки яких будуються щодо перегляду сервісу. Всі ново додані або виявлені (service discovery) сервіси автоматично стають доступними для перегляду в раніше створених консолях. Якщо у Вас цілий «зоопарк» технологій, то доведеться встановити масу exporters для їх моніторингу, але такого підходу є цілком логічне обгрунтування.

Дивною може здаватися ситуація з безпекою. Спочатку, сервіс Prometheus і встановлені exporters «відкриті світу». Будь-хто, що знає потрібну адресу і порт, зможе отримати дані по вашим метрик. Позиция розробників тут така — Prometheus це система моніторингу, а не безпеки. Користувачам не складе труднощів використовувати в цих цілях сторонні 3rd party продукти, давно і успішно які реалізовують такі завдання, дозволивши розробникам Prometheus сфокусуватися на задачах моніторингу. У моєму ж випадку, успішно використовується Nginx як reverse-proxy з http basic auth, настроювання якого зайняла зовсім незначний час.

Для тих, хто хоче позбавити себе сну і спокою, розробники надають можливість використання AlertManager. Він надзвичайно простий в налаштуванні і дозволяє працювати з вже згаданим мовою запитів. AlertManager може интегрироваться з HipChat, Slack, PagerDuty, а в разі необхідності інтеграції з ще не підтримуваними сервісами, рекомендую ознайомитися зі статтею інтеграції для аудіо-сповіщення.

В якості практичного прикладу наводжу правило з моєї поточної конфігурації AlertManager:

ALERT nodeexporter_available_disk_space
IF (100 - node_filesystem_free{job=~".*nodeexporter"} / node_filesystem_size{job=~".*nodeexporter"} * 100) > 70
ANNOTATIONS {description="Used disk space: {{ $value }}%. Device: {{ $labels.device }}.", summary="Running out of disk space at instance {{ $labels.instance }}"}

Це правило спрацює у разі заповнення дискового простору більш ніж на 70% на будь-якому з серверів, де запущений node_exporter, після чого буде надіслано відповідне повідомлення на пошту.

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

Корисні посилання
Джерело: Хабрахабр

0 коментарів

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