Skip to content

Всё для WordPress, веб-разработки — и не только

🧠 Мониторинг памяти и диска EC2 через CloudWatch Agent: пошаговая настройка
РазноеХостинг и серверы
9 мин1,733 слов1 613

🧠 Мониторинг памяти и диска EC2 через CloudWatch Agent: пошаговая настройка

Ваш инстанс 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, которые агент будет использовать для аутентификации.

Создание пользователя IAM с программным доступом

На экране разрешений выберите Прикрепить существующие политики напрямую. В фильтре по типу политики укажите Управляемые клиентом, так вы быстрее найдёте только что созданную CloudWatchAgentPolicy.

Прикрепление политики CloudWatch к пользователю IAM

Отметьте политику галочкой и нажмите Далее → Создать пользователя. AWS покажет экран с ключами доступа, сохраните Access Key ID и Secret Access Key прямо сейчас. Закроете страницу, ключи исчезнут навсегда, придётся пересоздавать.

Ключи доступа IAM после создания пользователя

Установка CloudWatch Agent

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

Загрузка и установка

Подключитесь к инстансу по SSH и скачайте пакет агента для Ubuntu:

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

Установите пакет через dpkg:

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

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

1sudo apt-get install -f

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

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

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

Создание конфигурационного файла

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

1sudo /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, нужно передать агенту. Создайте файл с креденшелами в домашней директории пользователя:

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

Добавьте секцию:

1[credentials]
2    shared_credential_profile = "AmazonCloudWatchAgent"

И пропишите креды в стандартном AWS credentials-файле:

1aws configure --profile AmazonCloudWatchAgent

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

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

Тестирование

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

1sudo /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 (агент по умолчанию пишет именно туда).

Навигация по метрикам в консоли CloudWatch

Разверните неймспейс, вы увидите измерения 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 сам следит, чтобы агент был жив и перезапускался при падении.

Проверьте статус:

1sudo systemctl status amazon-cloudwatch-agent

Убедитесь, что сервис active (running) и включён в автозагрузку (enabled). Если нет, запустите и включите:

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

После перезагрузки инстанса агент поднимется автоматически.

Наглядная демонстрация всего процесса, от IAM до дашборда, в этом видео:

Собираем кастомный дашборд

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

Создание дашборда

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

Создание нового дашборда в CloudWatch

Выберите 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 автомасштабирует ось, и небольшой всплеск выглядит так же угрожающе, как критическая ситуация. С фиксированным лимитом вы с одного взгляда понимаете, насколько близко к краю.

Вкладка параметров графика с настройкой максимума оси Y

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

Сохранение собранного дашборда в CloudWatch

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

⁉️🤔 Частые вопросы

Почему стандартные метрики 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 минут на инстанс. Дальше он работает сам.

Редакция
РедакцияРедакционная команда→ Все публикации

Профессиональная команда авторов и редакторов, специализирующихся на создании качественного контента.