Модуль 1.10: CloudWatch та спостережуваність

Складність: [MEDIUM] | Час на виконання: 2 години | Трек: Основи AWS DevOps

Передумови

Перед початком цього модуля переконайтеся, що ви:

Завершили Модуль 1.3: Основи EC2 та обчислень
Маєте акаунт AWS з правами адміністратора
Встановили та налаштували AWS CLI v2
Маєте базове розуміння метрик, логів та концепцій алертингу

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

У липні 2019 року велика фінансова компанія пережила 14-годинний збій, який коштував їм $12 мільйонів втраченого доходу. Причиною став витік пам’яті (memory leak) у Java-мікросервісі на EC2. Операційна команда помітила проблему занадто пізно, бо моніторила лише використання CPU — стандартну метрику CloudWatch для EC2. Використання пам’яті, помилки рівня додатка та паузи збирання сміття були для них невидимими.

Якби вони встановили CloudWatch Agent для збору метрик пам’яті та диска, вони б отримали сповіщення за 6 годин до збою. Вартість такого запобігання — близько $3 на місяць.

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

Чи знали ви?

CloudWatch обробляє понад 1 трильйон метрик на день. Це один із найстаріших сервісів AWS, запущений ще у 2009 році.
Стандартні метрики EC2 мають інтервал 5 хвилин і вони безкоштовні. “Детальний моніторинг” (1-хвилинний інтервал) коштує грошей, але він критично важливий для продакшну, щоб бачити короткі сплески навантаження.
CloudWatch Logs Insights дозволяє шукати по терабайтах логів за секунди за допомогою мови запитів, схожої на SQL. Це майже повністю замінило потребу тримати окремий кластер Elasticsearch тільки для пошуку логів.

Стандартні метрики: Що ви отримуєте безкоштовно

Кожен сервіс AWS автоматично відправляє метрики в CloudWatch безкоштовно.

EC2 Standard Metrics:

CPUUtilization: Використання процесора.
NetworkIn / NetworkOut: Мережевий трафік.
DiskReadBytes / DiskWriteBytes: Тільки для Instance Store дисків.
StatusCheckFailed: Перевірка здоров’я віртуальної машини.

Чого НЕМАЄ в стандарті для EC2? AWS не бачить “всередину” вашої ОС, тому Memory Utilization (пам’ять) та Disk Space (місце на диску EBS) потребують встановлення агента.

CloudWatch Logs: Централізоване управління логами

CloudWatch Logs — це місце, де зберігаються всі ваші системні та прикладні логи.

Важливі поради щодо витрат:

Retention (Зберігання): За замовчуванням логи зберігаються вічно. Завжди встановлюйте термін (напр., 30 днів для продакшну, 7 днів для dev), щоб не платити за непотрібне зберігання.
Log Groups: Групуйте логи за додатками та середовищами (/myapp/prod/api).

CloudWatch Alarms: Реагування на проблеми

Метрики марні, якщо ніхто не дивиться на графіки о 3 годині ночі. Алярми (Alarms) автоматизують реагування.

Три стани алярму:

OK: Все в нормі.
ALARM: Поріг перевищено (напр., CPU > 80% протягом 5 хв).
INSUFFICIENT_DATA: Немає даних для оцінки.

Ви можете налаштувати алярм так, щоб він надсилав лист через SNS або автоматично перезавантажував “завислий” сервер EC2.

CloudWatch Agent

Це програма (daemon), яку ви встановлюєте на сервер. Вона дозволяє:

Відправляти метрики пам’яті та диска в CloudWatch.
Читати файли логів (напр., /var/log/nginx/access.log) і відправляти їх у CloudWatch Logs.

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

Помилка	Чому це стається	Як виправити
Немає терміну зберігання логів	Сміття накопичується роками	Встановлюйте Retention Policy (напр. 30 днів) при створенні Log Group
Моніторинг тільки CPU на EC2	Це єдина видима метрика за замовчуванням	Встановіть CloudWatch Agent; пам’ять — важливіший показник для багатьох додатків
Занадто багато кастомних метрик	Кожна комбінація міток (dimensions) коштує грошей	Не використовуйте унікальні ID користувачів або IP як мітки для метрик
Занадто часті алерти (Alert Fatigue)	Поріг встановлено занадто низько або період занадто короткий	Використовуйте 3-5 послідовних періодів для оцінки алярму, щоб ігнорувати короткі сплески

Тест

1. Чому використання пам'яті (Memory) не входить у стандартні безкоштовні метрики EC2?

Тому що AWS моніторить ваші сервери ззовні (через гіпервізор). Гіпервізор бачить, скільки ресурсів процесора споживає віртуалка, але не має доступу до того, як операційна система всередині розподіляє свою пам’ять. Для цього потрібен агент, що працює всередині ОС.

2. У вас є алярм на CPU з періодом 5 хвилин та оцінкою (evaluation periods) 3. Скільки часу CPU має бути вище порогу, щоб алярм спрацював?

Мінімум 15 хвилин (3 періоди по 5 хвилин кожен). Це допомагає уникнути помилкових спрацювань через короткочасні стрибки навантаження.

Практична вправа: Створення алярму

Запустіть екземпляр EC2.
Створіть алярм через консоль або CLI, який відправляє вам Email (через SNS), якщо CPUUtilization перевищує 70% протягом 5 хвилин.
Навантажте процесор на сервері (наприклад, командою stress або просто запустіть важкий скрипт) і дочекайтеся сповіщення.

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

Переходьте до Модуля 1.11: CI/CD в AWS — де ви побудуєте автоматизовані конвеєри розгортання коду. Тепер, коли ви вмієте моніторити інфраструктуру, час автоматизувати те, як код туди потрапляє.