Модуль 2.10: GCP Cloud Operations (Моніторинг та Логування)

Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Модуль 2.3 (Compute Engine), Модуль 2.7 (Cloud Run)

Чому цей модуль важливий

У листопаді 2022 року платіжний сервіс однієї фінтех-компанії почав працювати з перебоями. Клієнти скаржилися, що близько 5% транзакцій відхиляються з помилкою “server error”. Інженер перевірив дашборд Cloud Run і побачив, що CPU та пам’ять у нормі, кількість запитів стабільна. Все виглядало ідеально з боку інфраструктури. Проблема тривала 4 години, поки старший інженер не помітив у логах, що сторонній банківський шлюз повертає помилку 429 (забагато запитів). Цей сигнал загубився серед мільйонів рядків логів, бо у команди не було налаштовано сповіщень про помилки в коді. Затримка коштувала компанії $340 000.

Цей інцидент доводить істину: метрики кажуть вам, ЩО щось не так, а логи пояснюють ЧОМУ. Вам потрібно і те, і інше. Cloud Operations (раніше Stackdriver) — це вбудований у GCP набір інструментів для збору логів, метрик та налаштування алертингу. Він не просто додається зверху, він глибоко інтегрований у кожен сервіс Google Cloud.

У цьому модулі ви навчитеся працювати з Cloud Logging, створювати метрики на основі тексту логів, будувати дашборди в Cloud Monitoring та налаштовувати перевірки доступності (uptime checks), щоб дізнаватися про проблеми раніше за користувачів.

Cloud Logging: Де живуть ваші логи

Кожен запис у GCP проходить через Log Router. Він вирішує, куди відправити лог: у сховище для швидкого пошуку, в архів на довгі роки або в аналітику BigQuery.

Основні типи логів:

Admin Activity: Хто створив ВМ або змінив права? (Завжди ввімкнено, безкоштовно).
Data Access: Хто читав файли з бакета? (Треба вмикати окремо, платно).
Application Logs: Вивід вашого коду (stdout/stderr).

Порада щодо економії:

Логи в GCP можуть бути дорогими. Використовуйте Exclusion Filters, щоб відкидати непотрібні логи (наприклад, логи успішних перевірок здоров’я сервісу), за які ви не хочете платити.

Cloud Monitoring: Дашборди та Метрики

GCP автоматично збирає сотні метрик: завантаження CPU, кількість запитів до API, затримки (latency).

Що ви можете робити:

Dashboards: Створювати візуальні панелі з графіками.
PromQL: Використовувати стандартну мову запитів Prometheus для аналізу даних.
Uptime Checks: Google буде кожні 60 секунд заходити на ваш сайт із 6 різних точок світу, щоб перевірити, чи він працює.

Alerting: Як не проспати збій

Метрики марні, якщо ніхто на них не дивиться. Ви можете налаштувати Alerting Policies:

“Надішли імейл та сповіщення в Slack, якщо помилок > 5% протягом 5 хвилин”.
“Подзвони мені (через PagerDuty), якщо сайт перестав відповідати на Uptime Check”.

Золоте правило: Налаштовуйте алерти на симптоми, які бачить юзер (помилки, затримки), а не на причини (високий CPU). Сервер із 90% CPU — це не завжди проблема, якщо сайт працює швидко.

Структуроване логування (JSON)

Замість того, щоб писати логи як звичайний текст, пишіть їх у форматі JSON. Google автоматично розбере їх на поля. Це дозволить вам робити запити типу: jsonPayload.user_id = "123" AND jsonPayload.latency > 500.

Типові помилки

Помилка	Чому це стається	Як виправити
Логування всього на рівні DEBUG	Залишилося після розробки	Використовуйте рівень INFO для продакшну; DEBUG — тільки за потреби
Відсутність терміну зберігання (Retention)	Логи зберігаються вічно і коштують грошей	Встановіть Retention Policy (напр. 30 днів) для Log Buckets
Моніторинг тільки CPU	Це не показує реальний досвід користувача	Моніторте “Золоті сигнали”: Latency, Traffic, Errors, Saturation
Занадто чутливі алерти	Призводять до втоми від сповіщень	Використовуйте вікна оцінки (напр. “стабільно вище порогу протягом 10 хв”)

Тест

1. У чому різниця між Cloud Logging та Cloud Monitoring?

Cloud Logging фокусується на подіях (текстові записи про те, що сталося в конкретний момент). Cloud Monitoring фокусується на числових показниках у часі (графіки використання ресурсів, швидкість запитів).

2. Як можна заощадити на логах у великому проєкті?

Використовуйте Log Sinks з фільтрами виключення (Exclusions), щоб не зберігати в Cloud Logging менш важливі логи, або спрямовуйте їх у дешеве сховище Cloud Storage для довготривалого архівування.

Практична вправа: Створення дашборда

Розгорніть будь-який сервіс у Cloud Run.
Зайдіть у Cloud Monitoring -> Dashboards.
Створіть віджет, який показує кількість запитів (Request Count) за останні 15 хвилин.
Додайте другий віджет, який показує 95-й процентиль затримки (P95 Latency).
Налаштуйте Uptime Check для вашого Cloud Run URL.

Наступний модуль

Переходьте до Модуля 2.11: Cloud Build та CI/CD — ви навчитеся автоматизувати збірку та деплой ваших додатків за допомогою конвеєрів Google.