Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

08.09.2022

Оповіщення AWS СloudWatch для сервісів ECS

🌡️🎛️⚠️ Продовжив сьогодні налаштовувати оповіщення Cloudwatch. Облаштував сервіси ECS (тобто, аплікації.)

Два оповіщення тривіальні — на високий рівень утилізації процесора та памʼяті. Ці дві метрики повідомляє сам ECS.

- Памʼять — на 80%. Сервіси на Ruby дуже полюбляють памʼять, але 20% треба тримати в резерві.
- Процесор — на 50%. Якщо у вебсервісу постійне навантаження до 50%, скоріш за все щось відбувається не так. Зазвичай більшість часу вебсервіси чекають або на базу, або на клієнта, тобто процесор простоює.

Третє трошки цікавіше — це монітор несподівано завершених задач. На щастя, ECS добре підтримує сервіси на плаву, навіть якщо задачі інколи падають. Та навіть якщо задеплоїти вкрай поламаний код, то ECS не дасть сервісу впасти, бо буде тримати старі задачі аж допоки нові не підтвердять свою стабільність. Це чудово. Але погано, що помітити задачі, що падають, майже неможливо — треба сидіти та дивитись.

Це створює дві категорії проблем. Першу досить легко побачити — це зіпсований деплой. Задеплоїли, не завелося, все нібито працює, але на тлі нескінченно стартують та зупиняються поламані задачі.

Друга підступніша — це вихід за нестачею памʼяті. Можна жити та не помічати, як вони трапляються. (Я знаю, бо так і було.)

Отже, хитрим поєднанням AWS EventBridge, Cloudwatch Logs, Log Metric Filter, та потім власне Metric Alarm, можна зробити так, щоб події зупинки задач ECS потрапляли до журналу, фільтрувалися за причиною (бо є ще очікувані зупинки) та підраховувались метрикою.

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