Ваш інстанс EC2 перестав відповідати, а CloudWatch показує, що все гаразд? Класика. AWS «з коробки» дає метрики CPU, мережі, дискового вводу-виводу, але не показує використання пам’яті та вільного місця на диску. Ці цифри заховані всередині віртуальної машини, і поки ви їх не витягнете назовні, ви летите наосліп.

Коли пам’ять закінчується, інстанс не попереджає, він просто падає. OOM Killer вбиває процеси у випадковому порядку, і ви гадаєте: плагін відвалився? база лягла? А річ у тім, що закінчилися гігабайти RAM, які ви не моніторили. З диском та сама історія: логи, бекапи, тимчасові файли забивають сховище непомітно, і одного ранку No space left on device.

Вирішується це CloudWatch Agent, штатним агентом AWS, який збирає memory, disk, swap та ще два десятки системних метрик і надсилає їх у CloudWatch. Налаштування займає 20 хвилин і вкладається в безплатний ліміт (10 користувацьких метрик на місяць). Далі, покроково, від IAM до готового дашборда.

💡 Швидкий огляд:

• Створіть політику IAM з cloudwatch:PutMetricData та прив’яжіть її до користувача
• Завантажте та встановіть CloudWatch Agent на Ubuntu-інстанс
• Налаштуйте конфігураційний JSON: memory, disk, swap
• Запустіть агента та перевірте, що метрики надходять у CloudWatch
• Зберіть кастомний дашборд із графіками використання пам’яті та диска

Управління ідентифікацією та доступом AWS

Агенту потрібні права на надсилання метрик у CloudWatch. Для цього створимо політику IAM та прив’яжемо її до користувача з програмним доступом.

Політика IAM

Відкрийте консоль IAM, перейдіть у Політики → Створити політику та перемкніться на вкладку JSON. Вставте цей документ:

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "CloudWatchAgentMetrics",
6
            "Effect": "Allow",
7
            "Action": [
8
                "cloudwatch:PutMetricData",
9
                "ec2:DescribeTags",
10
                "cloudwatch:GetMetricStatistics",
11
                "cloudwatch:ListMetrics"
12
            ],
13
            "Resource": "*"
14
        }
15
    ]
16
}

Натисніть Перевірити політику, задайте ім’я (наприклад CloudWatchAgentPolicy) і натисніть Створити політику.

Користувач IAM

Перейдіть у Користувачі → Додати користувача. Задайте ім’я та обов’язково позначте чекбокс «Програмний доступ», він дасть Access Key ID і Secret Access Key, які агент використовуватиме для автентифікації.

На екрані дозволів оберіть Прикріпити наявні політики безпосередньо. У фільтрі за типом політики вкажіть Керовані клієнтом, так ви швидше знайдете щойно створену CloudWatchAgentPolicy.

Позначте політику галочкою та натисніть Далі → Створити користувача. AWS покаже екран із ключами доступу, збережіть Access Key ID і Secret Access Key просто зараз. Закриєте сторінку, ключі зникнуть назавжди, доведеться перестворювати.

Встановлення CloudWatch Agent

Старі Perl-скрипти моніторингу (CloudWatchMonitoringScripts-1.2.2.zip) давно позначені як deprecated. Актуальний спосіб, уніфікований CloudWatch Agent, який збирає не лише пам’ять і диск, а й swap, завантаження процесора, мережеві інтерфейси та ще два десятки метрик «з коробки».

Завантаження та встановлення

Підключіться до інстансу через SSH і завантажте пакет агента для Ubuntu:

1
wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

Встановіть пакет через dpkg:

1
sudo dpkg -i amazon-cloudwatch-agent.deb

Якщо менеджер пакетів поскаржиться на відсутні залежності, доставте їх однією командою:

1
sudo apt-get install -f

Агент встановлений, але ще не знає, які метрики збирати та з якими ключами ходити в CloudWatch. Задамо конфігурацію.

Зверніть увагу: агент також доступний через AWS Systems Manager (SSM), якщо у вас десятки інстансів, зручніше розгорнути його централізовано через Run Command, без SSH на кожну машину. Для одного-двох інстансів ручне встановлення простіше та швидше.

Конфігурація агента

Створення конфігураційного файлу

Конфігурація CloudWatch Agent — це JSON-документ, який описує, які метрики збирати та з якою періодичністю. Запустіть вбудований майстер:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Майстер поставить кілька запитань в інтерактивному режимі: на якому сервері (EC2/on-premises), куди надсилати метрики (CloudWatch), які метрики збирати. Для відстеження пам’яті та диска дайте такі відповіді:

• Operating system: Linux
• Are you using Amazon EC2?: Yes
• Which metrics to collect: Custom metrics (mem та disk_used_percent)
• Resolution: 60 секунд (Standard)
• Log files: пропустіть, якщо логи не потрібні

На виході майстер згенерує файл config.json у директорії /opt/aws/amazon-cloudwatch-agent/bin/. Ось мінімальний робочий приклад, memory used percent + disk used percent + swap:

1
{
2
    "agent": {
3
        "metrics_collection_interval": 60,
4
        "run_as_user": "root"
5
    },
6
    "metrics": {
7
        "metrics_collected": {
8
            "mem": {
9
                "measurement": [
10
                    "mem_used_percent"
11
                ]
12
            },
13
            "disk": {
14
                "measurement": [
15
                    "disk_used_percent"
16
                ],
17
                "resources": [
18
                    "/"
19
                ]
20
            },
21
            "swap": {
22
                "measurement": [
23
                    "swap_used_percent"
24
                ]
25
            }
26
        }
27
    }
28
}

Параметр resources для disk вказує точку монтування: "/", кореневий EBS-том NVMe SSD, основне сховище інстансу. Якщо у вас є додаткові томи (наприклад, /data), додайте їх до масиву.

Креди агента

Ключі доступу, збережені на етапі IAM, потрібно передати агенту. Створіть файл із креденшелами в домашній директорії користувача:

1
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml

Додайте секцію:

1
[credentials]
2
    shared_credential_profile = "AmazonCloudWatchAgent"

І пропишіть креди у стандартному AWS credentials-файлі:

1
aws configure --profile AmazonCloudWatchAgent

Система запитає Access Key ID, Secret Access Key та регіон. Після заповнення агент зможе надсилати метрики від імені створеного IAM-користувача.

Альтернативний шлях, IAM-роль, прикріплена до інстансу. Це безпечніше (ключі не лежать на диску) і простіше під час масштабування. Якщо ви запускаєте EC2 з IAM-роллю, яка має cloudwatch:PutMetricData, агент підхопить права автоматично, крок із креденшелами можна пропустити.

Тестування

Запустіть агента вручну та перевірте, що метрики надходять:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
2
  -a fetch-config \
3
  -m ec2 \
4
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
5
  -s

Прапор -s стартує агента як сервіс. За хвилину-дві перші метрики з’являться в CloudWatch. Щоб переконатися, що дані йдуть, відкрийте консоль CloudWatch, перейдіть до розділу Metrics → All metrics і знайдіть неймспейс CWAgent (агент за замовчуванням пише саме туди).

Розгорніть неймспейс, ви побачите виміри InstanceId, розбиті за метриками: mem_used_percent, disk_used_percent та swap_used_percent. Клік по будь-якому рядку будує графік, можна одразу оцінити, що дані надходять і виглядають осмислено.

Чотири базові метрики (пам’ять, диск, swap, CPU) на двох інстансах — це 8 метрик. Безплатний ліміт CloudWatch, 10 користувацьких метрик на місяць, описано на сторінці цін. Ви в нього вкладаєтеся. Якщо інстансів більше трьох, частина метрик вийде за ліміт, але цінник скромний: $0,30 за метрику на місяць (дані AWS на 2026 рік).

Налаштування розкладу

Агент за замовчуванням працює як systemd-сервіс і надсилає метрики з інтервалом, заданим у metrics_collection_interval (60 секунд у нашому конфігу). Додаткових cron-записів не потрібно, systemd сам стежить, щоб агент був живий і перезапускався в разі падіння.

Перевірте статус:

1
sudo systemctl status amazon-cloudwatch-agent

Переконайтеся, що сервіс active (running) і ввімкнений в автозавантаження (enabled). Якщо ні, запустіть і ввімкніть:

1
sudo systemctl enable amazon-cloudwatch-agent
2
sudo systemctl start amazon-cloudwatch-agent

Після перезавантаження інстансу агент запуститься автоматично.

Наочна демонстрація всього процесу, від IAM до дашборда, у цьому відео:

Збираємо кастомний дашборд

Метрики надходять, тепер їх потрібно гарно запакувати. Я покажу, як зібрати дашборд для моніторингу продакшен-інстансу: пам’ять, диск, завантаження CPU та кредитний баланс (для T-серії) на одному екрані.

Створення дашборда

У консолі CloudWatch перейдіть до Dashboards → Create dashboard. Задайте ім’я (наприклад Production-EC2) і виберіть тип віджета.

Виберіть Line для першого графіка, цей тип найкраще підходить для відображення метрик за період.

Віджет графіка

Натисніть Add widget і виберіть тип Line, простий лінійний графік, найкращий варіант для більшості метрик. У діалоговому вікні натисніть Configure і перейдіть до неймспейсу CWAgent.

Знайдіть метрику mem_used_percent для вашого інстансу (за InstanceId) і клікніть по рядку, CloudWatch одразу покаже графік.

Порада: тип Stacked area підходить, коли на одному віджеті кілька метрик (наприклад, пам’ять + swap); Number, для миттєвого зчитування поточного значення (зручно винести в кут дашборда); Text, для заголовків і нотаток між графіками.

Тонке налаштування графіка

Кілька налаштувань, які роблять графік читабельним:

• Період: якщо агент надсилає метрики щохвилини, виберіть період 1 хвилина, щоб бачити повну роздільну здатність даних.

• Назва: перейменуйте легенду графіка на щось людське, «RAM used%», а не mem_used_percent / i-1234567890abcdef0.

• Максимум по осі Y (Graph options): зафіксуйте ліміт (наприклад, 100 для відсотків або 16 для 16 ГБ RAM). Без цього CloudWatch автомасштабує вісь, і невеликий сплеск виглядає так само загрозливо, як критична ситуація. З фіксованим лімітом ви з одного погляду розумієте, наскільки близько до краю.

Натисніть Create widget, перший блок дашборда готовий. Повторіть для кожної метрики: disk_used_percent, потім swap_used_percent, потім cpu_usage (вбудована метрика EC2, не з CWAgent) і CPUCreditBalance для T-серії. Віджети можна перетягувати, змінювати розмір, редагувати. Коли все виглядає як треба, натисніть Save dashboard.

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

⁉️🤔 Часті питання

Чому стандартні метрики EC2 не включають пам’ять і диск?

AWS віртуалізує CPU і мережу на рівні гіпервізора, ці метрики доступні ззовні, без заходу в гостьову ОС. Пам’ять і диск, внутрішні ресурси віртуальної машини, гіпервізор про них не знає. Щоб їх побачити, потрібен агент всередині ОС, який зчитує /proc/meminfo і df та відправляє в CloudWatch. CloudWatch Agent саме це й робить: щохвилини опитує системні лічильники й надсилає їх у неймспейс CWAgent. Повний список із двох десятків метрик, в офіційній документації AWS.

Скільки це коштує?

Для типового сценарію «1-2 інстанси, 4 метрики на кожен», ніскільки. Безплатний ліміт CloudWatch включає 10 користувацьких метрик, 10 алармів і 3 дашборди на акаунт щомісяця, згідно зі сторінкою цін CloudWatch. Два інстанси по 4 метрики = 8 із 10 безплатних. Якщо інстансів більше трьох, перевищення ліміту коштує $0,30 за метрику на місяць. Для десятка серверів це $6-9 на місяць, ціна за відсутність сюрпризів о третій ночі.

Чим CloudWatch Agent кращий за старі Perl-скрипти?

Perl-скрипти (mon-put-instance-data.pl) офіційно deprecated з 2023 року і не отримують оновлень. CloudWatch Agent, штатний підтримуваний інструмент, який пише не тільки в CloudWatch, а й в Amazon Managed Prometheus; збирає метрики через StatsD і collectd; уміє надсилати логи й трейси. Головне, він інтегрується з Systems Manager, тобто на 50 інстансів ви розгортаєте його однією командою з консолі, без SSH. Якщо у вас досі крутяться Perl-скрипти, мігруйте: старий формат awscreds.conf із ключами у відкритому вигляді на диску — це діра в безпеці. CloudWatch Agent працює з IAM-ролями і не вимагає зберігати секрети в текстовому файлі.

Що робити, якщо метрики не з’являються в CloudWatch?

Перевірте по порядку: (1) статус сервісу через systemctl status amazon-cloudwatch-agent, має бути active; (2) логи агента в /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log, там буде конкретна помилка; (3) права IAM, у користувача або ролі має бути дозвіл cloudwatch:PutMetricData; (4) регіон, агент і консоль мають дивитися в один регіон AWS. З мого досвіду, у переважній більшості випадків проблема або в пермішенах, або в незбігу регіону.

Чи можна моніторити Windows-інстанси?

Так, CloudWatch Agent підтримує Windows Server нарівні з Linux. Встановлення, через MSI-інсталятор із того ж S3-бакета (amazon-cloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/). Конфігурація, той самий JSON, але імена метрик відрізняються: замість mem_used_percent, Memory % Committed Bytes In Use. Майстер конфігурації на Windows сам підставить правильні імена.

Що дає моніторинг пам’яті та диска на практиці

Ви запустили CloudWatch Agent на Ubuntu-інстансі, прописали збір memory, disk і swap, прикрутили дашборд із графіками. Що змінилося? Рівно одна річ: сліпа пляма зникла. Ви бачите не тільки CPU і мережу, а й двох головних убивць інстансів, витік пам’яті та забитий диск.

На практиці це означає: ви помічаєте, що пам’ять повзе вгору за три дні ДО того, як OOM Killer приб’є PHP-FPM. Ви бачите, що диск заповнився майже повністю після оновлення тем, і чистите логи ДО того, як впаде база. Без цих метрик кожен інцидент, розслідування post mortem. З ними, алерт у каналі за пів години до аварії.

Якщо у вас більше трьох інстансів, налаштуйте CloudWatch Alarms на порогові значення (скажімо, mem_used_percent > 90 протягом 5 хвилин) і підключіть сповіщення через SNS у Slack або Telegram. Агент + аларми = ви дізнаєтеся про проблему не від клієнта, а від AWS.

Налаштування агента, разова інвестиція у 20 хвилин на інстанс. Далі він працює сам.