Ефективний моніторинг сучасного PHP-застосунку. Як тут працюють системи спостереження Observability?

Партнерский материал

Щоб моніторити роботу сучасних високорозподілених PHP-застосунків, знадобляться принципово нові підходи та технології. Це пов’язано із мікросервісною архітектурою програми, коли її різні частини реалізуються за допомогою незалежних модулів, розміщених на різних інстансах. І це не дає можливості відстежувати, як виконуються запити. А якщо код розміщується у хмарному середовищі, наприклад, в Azure або AWS – виявляти та локалізувати проблеми ще складніше з-за високого рівня динамічності інфраструктури.

Подолати всі ці труднощі здатні Observability системи спостереження нового покоління. Існує чимало їх реалізацій, ми в FREEhost.UA використовуємо стек Grafana/Loki/Tempo. Для партнерського матеріалу розглянемо її більш детально.

Партнерський матеріал?

Вихідні дані для Observability

Щоб зробити моніторинг високорозподіленого застосунку, знадобляться телеметричні дані про його роботу. Основними з них є логи, метрики та трейси. 

Метрики

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

Логи

Логи є записами системних журналів, котрі надають корисну інформацію про застосунок на кількох рівнях – INFO, WARN, DEBUG та інших. Вони генеруються при виникненні будь-якої події під час роботи застосунку та містять наступні дані:

  • системну інформацію про подію – час її настання, ID тощо;
  • рівень логу;
  • повідомлення;
  • контекст.

Трейси

Трасування є одним з методів для профілювання та контролю роботи застосунку. Трейси – результат цього процесу, що дозволяє:

  • зафіксувати послідовність виконання команд та модулів/мікросервісів на шляху виконання запиту;
  • визначити затримку запиту при кожному виклику або пересиланні між двома сервісами.

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

Щоб система трасування працювала, обов’язковою умовою є наявність унікального TraceID для кожного запиту. Він генерується в точці входу та запам’ятовується у його заголовку. Після цього розповсюджується по шляху «руху» запиту через всі мікросервіси, котрі залучені у його виконанні (див. Малюнок 1). Це дозволяє відстежувати поведінку та продуктивність окремого запиту. 

Малюнок 1. Шлях руху запиту із передачею по ланцюгу спанів його TraceID.

Кореляція логів та трейсів

Збільшити можливості аналізу та контролю високорозподілених систем можна за допомогою співставлення логів та трейсів для визначеного запиту через TraceID. Це, зокрема, дозволяє:

  • пропускати через застосунок «еталонні» запити для усунення проблем;
  • напряму співставляти метрики із логами;
  • автоматично збирати системні логи для визначеного запиту;
  • візуалізувати результати.

Така кореляція реалізована не для всіх Observability-систем, про що розповідаємо нижче.   

Алерти

Алерти дозволяють автоматизувати процес виявлення негараздів у коді. Якщо значення параметра не відповідають допустимим нормам, то генеруватимуться повідомлення у месенджері або системі моніторингу. Такими параметрами є зібрані метрики, і саме вони «керують» процесом генерування алертів. Можна навіть сказати, що використання метрик без алертів на 50% марне.

Профайлінг

Профілювання коду застосунку дозволяє визначити, де знаходиться недосконала ділянка коду. Його застосування для високорозподілених систем має свої особливості. Щоб можна було отримати якісний результат, повинні бути застосовані профайлери із підтримкою трейсів та технології OpenTelemetry для їх передачі. Нижче розглянемо ряд реалізацій профайлерів та їх характеристики.

Підходи до реалізації Observability

У сучасній Observability-системі опція Distributed tracing має бути реалізована за допомогою механізму кореляції логів та трейсів. Лише в цьому випадку можна отримати ефективні результати моніторингу. Більшість існуючих реалізацій лише частково задовольняють цим вимогам. До них, зокрема, відносяться Zipkins, Cloud Sleuth та DataDog APM. Інші системи, хоча і підтримують технологію, але є занадто складними та ресурсоємними, як, наприклад, відома система моніторингу Jager

Раніше у роботі ми розглянули систему, побудовану на базі стеку технологій Grafana/Loki/Tempo, який майже повністю задовольняє вказаним вимогам та може бути основою для побудови ефективної Observability-системи.

Grafana + Loki + Tempo

Grafana Tempo дозволяє реалізувати повний життєвий цикл Distributed tracing коштом підтримки наступних кейсів:

  • Інструментація застосунку;
  • Інтеграція із Loki;
  • Бекенд трейсів (Tempo);
  • Система керування метриками (Mimir);
  • Засоби аналізу та візуалізації (Grafana).

Взаємодія елементів платформи представлена на Малюнку 2.

Малюнок 2. Взаємодія елементів Grafana Tempo.

Loki є централізованим сервісом для збору та зберігання логів. На Малюнку 3 наведена конфігурація стеку Loki разом з її компонентами.

Малюнок 3. Конфігурація стеку Loki.

Замовити оренду хмарного, або фізичного сервера із конфігурацією Grafana + Loki можна на сайті хостер-провайдера FREEhost.UA.

У якості Alert-менеджера можна використовувати систему моніторингу Prometheus, котра водночас збирає та централізовано зберігає метрики, на основі котрих оповіщаються клієнти. Для довготривалого зберігання метрик доцільно під’єднати Grafana Mimir.

Реалізація профайлінгу

У Таблиці 1 наведено основні відомості про існуючі варіанти реалізації профайлінгу.

Таблиця 1. Порівняльна характеристика профайлерів.

Інструмент Вартість FPM/CLI UI та звіти Особливості
php-excimer + + Легкий, проста конфігурація, вибіркова профілізація slow-endpoints, інтеграція із CI/CD, Chrome Trace + web-UI
Xdebug + Для локального відлагодження
Tideways + + + Розширений моніторинг в продакшн, SLA і підтримка
Blackfire + + + Інтеграція із CI/CD, готові дашборди
Інші Застарілі, не оновлюються (XHProf, PHP-Profiler та інш.)

 

Вочевидь, найбільш прийнятний варіант – php-excimer.

Висновки

Отже, побудова Observability-систем повинна спиратися на метрики, логи, трейси та їх взаємну кореляцію з обов’язковим налаштуванням профайлінгу та алертингу. 

Це був скорочений огляд інструментів Observability, розширений варіант статті можна переглянути на нашому сайті.   

Партнерський матеріал?

Переглянути розширену статтю 

Останні статті

Microsoft бере на себе управління GitHub

Томас Домке оголосив про рішення піти з посади генерального директора (CEO) GitHub заради створення нового…

12.08.2025

Ілон Маск погрожує Apple судом через високу позицію ChatGPT в App Store

Ілон Маск опублікував серію твітів, в яких висловив незадоволення тим, що його додатки X та…

12.08.2025

Експерти радять уникати WinRAR: в архіваторі знову знайшли критичний баг

Популярний архіватор файлів, який має понад 500 мільйонів установок, щонайменше два тижні активно використовувався хакерами.…

12.08.2025

Microsoft тестує хмарні ПК для аварійної заміни комп’ютера через Windows 365

Microsoft почала тестування хмарного сервісу аварійного відновлення Windows 365 Reserve. Він дозволяє тимчасово замінити ПК,…

12.08.2025

Через неспроможність виправити код у Google Gemini стався «нервовий зрив»

Представник Google Deepmind підтвердив наявність помилки нескінченного циклу, яка виникає при роботі LLM-моделі Gemini. Раніше…

11.08.2025

Українські продуктові IT-компанії збільшують персонал, аутсорсингові та сервісні — зменшують

Аутсорсингові компанії EPAM Ukraine, SoftServe та GlobalLogic Ukraine очолили трійку найбільших в українській IT-галузі за…

11.08.2025