# Моніторинг ## Що це таке Система під моніторингом постійно звітує про себе, а щось безперервно читає ці звіти, порівнює їх із межами, які хтось провів, і вирішує, коли про це має дізнатися людина. Книга Google про Site Reliability Engineering визначає моніторинг як збирання, обробку, агрегування й відображення кількісних даних про систему в реальному часі: скільки запитів надходить і яких саме, скільки з них завершуються помилкою і якою, скільки часу вони тривають і скільки часу працює кожен сервер. Мета — певний порядок подій: система каже, що в неї біда, раніше, ніж це зробить користувач. Дані надходять із двох боків. Моніторинг «білої скриньки» (white-box) читає те, що система сама показує про свій внутрішній стан, — сторінку з метриками, довжину черги чи кількість повторних спроб, — тож бачить, як назріває проблема, ще до того, як її хтось відчує. Моніторинг «чорної скриньки» (black-box) стоїть зовні й поводиться як користувач: запитує сторінку, розв'язує доменне ім'я чи проходить вхід і повідомляє, чи це вдалося і скільки тривало. Він бачить лише те, що вже зламалося, і саме тому є надійною підставою когось розбудити. Більшість того, що зберігає система моніторингу, — це числа, виміряні з плином часу, бо їх дешево зберігати й легко порівнювати з порогом. Той самий розділ книги SRE називає чотири з них відправною точкою для всього, що обслуговує користувачів: затримка — час, який займає запит; трафік — скільки попиту надходить; помилки — частка запитів, що завершуються невдачею; і насичення — наскільки найзавантаженіший ресурс близький до вичерпання. Навколо чисел є два види виходу. Дашборд — щоб дивитися, коли хтось уже щось підозрює. Тривога — щоб перервати, коли всі зайняті чимось іншим. В екосистемі Prometheus правила обчислює сервер, а Alertmanager групує, прибирає дублікати й надсилає далі те, що спрацювало. Двох сусідів із ним легко сплутати. Журналювання записує окремі події, по рядку на кожну, і його читають уже після тривоги, щоб з'ясувати причину. Спостережуваність (observability), як її описує проєкт OpenTelemetry, — ширша здатність ставити системі нові запитання ззовні. Моніторинг — вужча й старша практика: запитання, визначені заздалегідь, які ставлять безперервно, з відповіддю, що може підняти людину. ## Чому це важливо Альтернатива — дізнаватися про проблеми від тих, кого вони зачіпають, о тій годині, коли вони їх помітять. Моніторинг переносить цей момент раніше й передає його тому, хто може діяти. Дефіцитний ресурс тут — увага, а не програмне забезпечення. Виклик чергового перериває роботу вдень і сон уночі, і книга SRE говорить прямо: коли виклики надходять надто часто, люди їх проглядають, сумніваються в них і зрештою ігнорують, іноді разом зі справжнім, захованим у шумі. Пораду проєкту Prometheus можна вмістити в одне речення: тримайте сповіщення простими, ставте тривоги на симптоми, майте добрі консолі для пошуку причин і не викликайте людину туди, де їй нема чого робити. Кожне правило, здатне розбудити людину, — це обіцянка, що коли воно спрацює, у неї буде щось термінове до виконання. Тож головне рішення стосується того, що відчувають користувачі. Диск, заповнений на 85%, — це причина; оформлення замовлення, яке зривається, — симптом. Тривоги на симптоми тримають кількість правил невеликою, бо способів зашкодити користувачам значно менше, ніж способів, якими можуть збоїти машини. Причинам усе одно місце на дашбордах і в тікетах, де вони допомагають шукати несправність, нікого не будячи. Чесний виняток — ємність: ресурс, близький до вичерпання, сьогодні нікому не шкодить, але скоро знадобиться людина. Далі постає питання: тримати моніторинг власним чи орендувати. Власний означає сховище часових рядів, маршрутизатор тривог і людину, яка стежить за справністю обох. Хмарний сервіс забирає цю роботу й виставляє рахунок за обсягом надісланих даних, тож кожен новий хост з'являється в рахунку. Книга SRE зазначає, що навіть у Google в команді з 10–12 інженерів зазвичай один, а іноді два мають моніторинг основною роботою. Так чи інакше, це система з власним обслуговуванням, і розмір її слід добирати під систему, за якою вона стежить. ## Як це виглядає на практиці Три частини роботи компанії показують ту саму ідею в дуже різних масштабах. З 2015 до 2022 року, на посаді інженера інфраструктури, завданням була [цілодобова підтримка приблизно тисячі серверів IPTV/OTT-стрімінгової платформи](/uk/portfolio/provided-round-the-clock-24-7-infrastructure-support-82/), а також чималої кількості систем, що належали клієнтам, для замовників у Китаї, США та Німеччині. Із клієнтами в трьох часових поясах тихої години не існувало, і проблема о 3-й ночі за місцевим часом була прайм-таймом для когось іншого. Значна частина роботи полягала в тому, щоб помітити відхилення до того, як воно переросте у збій, і проблеми усували ще до того, як вони досягали екрана глядача. На такому сервісі успіх виглядає як відсутність подій, а моніторинг дає команді знати це, а не сподіватися. На посаді інженера баз даних у 2022–2024 роках, на [100 базах даних у PostgreSQL, MS SQL і BigQuery](/uk/portfolio/architected-created-and-managed-100-postgresql-ms-sql-12/), автоматизований моніторинг скоротив час простою на 50%. Власний робочий хост компанії стоїть на протилежному кінці шкали. [Одна машина з 512 МБ тримає всю компанію](/uk/portfolio/ran-the-whole-company-on-one-512mb-host-109/), придатними до вжитку з них є близько 464 МБ, і пам'ять стала аргументом, що вирішує кожну суперечку про устрій хоста. Звітність там — витягування (pull), а не агент, конвеєр і дашборд: сім команд, які читають хост і формують Markdown, нічого не змінюють і запускаються лише на прохання. Чи витримає хост onion-сервіс, вирішила доба вимірюваних зразків: доступна пам'ять ніколи не опускалася нижче приблизно 310 МБ із 464, підкачування трималося на 2,6%, а процесор був вільним на 99,7%. У такому масштабі моніторинг — це вимір, зроблений саме тоді, коли він потрібен для рішення. ## Де виникають проблеми **Виклики надходять так часто, що люди перестають їх читати.** Кожен інцидент залишає по собі правило, багато з них спрацьовують на причини, що минають самі, і за кілька місяців справжній виклик проглядають разом з рештою. Викликайте людину лише через те, що помітили б користувачі, в одній точці стеку, а все інше відправляйте в чергу тікетів чи на дашборд. Потім дайте умові протриматися якийсь час, перш ніж вона спрацює, щоб збій, який минає за хвилину, нікого не будив: ```yaml groups: - name: checkout rules: - alert: CheckoutErrorsHigh expr: job:checkout_errors:ratio5m > 0.02 for: 10m labels: severity: page ``` **Моніторинг зупиняється, а його мовчання сприймають як добру новину.** Правило, яке ніколи не спрацьовує, виглядає точнісінько як система, що ніколи не ламається. Якщо падає сервер Prometheus, Alertmanager чи поштовий ретранслятор, усі тривоги зупиняються одночасно. Власна порада Prometheus — ставити тривоги на сам моніторинг, а ще краще — перевіряти весь шлях наскрізь, щоб одна перевірка доводила, що тривога може пройти від правила до поштової скриньки. У ту саму пастку потрапляють заплановані завдання: резервне копіювання, що перестало запускатися, не видає помилки, воно просто перестає залишати сліди. Викликайте людину, коли останній успіх надто давній, із запасом щонайменше на два повні запуски; для завдання, яке запускається кожні 4 години й триває годину, проєкт пропонує 10 годин: ```promql time() - backup_last_success_timestamp_seconds > 10 * 3600 ``` **Середнє каже, що все гаразд, поки частина користувачів чекає.** Середні значення легко малювати, і вони ховають хвіст. Приклад із книги SRE — сервіс із середньою затримкою 100 мс при 1 000 запитів на секунду, де 1% запитів цілком може тривати 5 секунд; коли сторінка залежить від кількох таких сервісів, 99-й перцентиль одного бекенда може стати медіаною фронтенда. Швидкі помилки погіршують картину, бо швидка відмова тягне середнє вниз. Записуйте затримку в бакети гістограми, ставте тривогу на високий перцентиль і рахуйте невдалі запити окремо від успішних. **Усі внутрішні показники зелені, а користувачі не можуть дістатися до сервісу.** Метрики білої скриньки походять зсередини системи, тож поділяють її сліпі зони: прострочений сертифікат, зламаний запис DNS чи зміна в правилах брандмауера можуть залишити кожну з них здоровою. Перевірка чорної скриньки з машини поза мережею системи ловить те, що інакше лишається невидимим, і продовжує працювати, коли внутрішній моніторинг падає разом з усім іншим. ## Що почитати далі - [Prometheus: Overview](https://prometheus.io/docs/introduction/overview/) — що збирає система моніторингу на основі метрик, з яких частин вона складається і де точність до кожної події вимагає іншого інструмента. - [Alerting](https://prometheus.io/docs/practices/alerting/) — поради проєкту Prometheus про те, через що варто викликати людину: від онлайн-сервісів і пакетних завдань до моніторингу самого моніторингу. - [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) — як тривоги очищують від дублікатів, групують, тимчасово вимикають, пригнічують і надсилають отримувачеві. - [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/) — розділ 6 книги Google про Site Reliability Engineering: симптоми й причини, чотири золоті сигнали і хвіст. - [Observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) — огляд OpenTelemetry про сигнали, SLI та SLO і про те, де спостережуваність сягає далі за моніторинг.