Создание тревоги CloudWatch для S3 (метрика NumberOfObjects)

Введение

Amazon CloudWatch предоставляет метрики для S3-бакетов двух типов: Storage Metrics (ежедневно, без дополнительной платы) и Request Metrics (каждую минуту, платно). В статье показано, как создать тревогу типа Storage Metric для метрики NumberOfObjects — числа объектов в бакете — и как управлять её состояниями и уведомлениями через SNS.

Основные понятия в одну строку

• Storage Metric: ежедневное значение, отражающее объём/число объектов в бакете.
• Request Metric: метрики по операциям чтения/записи, доступны каждую минуту и платны.
• Alarm (тревога): правило в CloudWatch, которое меняет состояние и может отправлять уведомления через SNS.

Предварительные требования

1. AWS аккаунт.
2. S3-бакет.
3. SNS Topic с подпиской (email/SMS/Lambda/http) для получения уведомлений.

Важно: убедитесь, что у вашей учетной записи есть права на CloudWatch, S3 и SNS.

Что будем делать

1. Войти в AWS Management Console.
2. Перейти в CloudWatch и создать тревогу для S3 по метрике NumberOfObjects.
3. Настроить SNS-уведомления.
4. Протестировать срабатывание и откатить порог.
5. Удалить тревогу при необходимости.

Вход в AWS

Перейдите на страницу входа в AWS и выполните аутентификацию под учётной записью с нужными правами.

После входа откроется консоль управления AWS.

Шаги: создание тревоги для S3

1. В строке поиска консоли введите “CloudWatch” и откройте сервис CloudWatch.

2. В левой панели выберите “Alarms” (Тревоги).

3. Нажмите “Create alarm”.

4. Нажмите “Select metric” и в окне выбора метрик отфильтруйте по S3.

5. Выберите «Storage Metrics» для S3.

6. Выберите нужный бакет и метрику NumberOfObjects. Можно выбрать только одну метрику для отдельной тревоги.

7. Под Conditions задайте порог, сравнение и период. Для Storage Metrics период данных — 1 день по умолчанию; это значит, что тревога будет вычисляться на основе суточных значений.

Примечание: для метрик Request (если вы их включили) доступен период 1 минута, но такие метрики платны.

8. На экране действий (Actions) выберите SNS Topic для уведомлений: можно создать новый топик или выбрать существующий.

9. Укажите имя тревоги и описание.

10. Просмотрите конфигурацию и нажмите “Create alarm”.

Состояния тревоги и тестирование

После создания тревога часто появляется в состоянии “Insufficient data” — CloudWatch анализирует доступные точки данных и затем обновляет состояние.

Когда условие выполняется (например, число объектов больше порога), тревога перейдёт в состояние “In alarm” и отправит уведомление в SNS.

Если в SNS есть подписка на email, вы получите письмо с уведомлением.

Чтобы проверить поведение в обратную сторону, увеличьте порог выше текущего числа объектов и обновите тревогу — она должна перейти в состояние “OK”.

Удаление тревоги

Если тревога больше не нужна, её можно удалить: выберите её в списке, нажмите Actions → Delete и подтвердите удаление.

Подтвердите удаление в диалоге. Удалённую тревогу нельзя восстановить — сохраняйте осторожность.

Практические советы и лучшие практики

• Валидация периодов: для Storage Metrics учитывайте, что значение обновляется один раз в день — тревоги будут основываться на суточных данных.
• Стоимость: Request Metrics (1-минутный интервал) — платные. Включайте их только если действительно нужна высокая частота оповещений.
• Тестирование уведомлений: перед продом создайте тестовый SNS-топик и подпишитесь на него, чтобы проверить формат и доставку сообщений.
• Разделение прав: используйте IAM роли/политики, ограничивающие возможность удаления критичных тревог.
• Наименование: давайте тревогам понятные имена, включающие имя бакета и цель (например: s3-prod-logs-number-of-objects-warning).

Важно: не полагайтесь на Storage Metrics для оперативного мониторинга — они предназначены для учета, а не для слежения в реальном времени.

Когда это не подходит

• Нужен оперативный мониторинг операций (PUT/GET/Delete): используйте Request Metrics или включите S3 Server Access Logging + анализ через Athena.
• Если требуется сложная логика (например, тренды, прогнозы) — интегрируйте данные с CloudWatch Metrics Insights или другим SIEM.

Альтернативные подходы

• Использовать CloudWatch Request Metrics (1 мин) — дороже, но быстрее.
• Включить S3 Inventory и анализировать отчёты — полезно для больших бакетов и периодической проверки целостности.
• Настроить Lambda-функцию, которая периодически подсчитывает объекты и отправляет кастомную метрику в CloudWatch (подходит при специфических требованиях).

Мини-методология: как безопасно добавить тревогу в прод

1. Создайте тревогу в тестовой учетной записи или в нерабочем окружении.
2. Настройте SNS с тестовой подпиской и проверьте доставку.
3. Проведите нагрузочное/функциональное тестирование (увеличьте объём объектов или имитируйте событие).
4. Перенесите конфигурацию в прод, назначьте владельца и контакт для оповещений.
5. Документируйте SOP удаления и контакты на случай ложных срабатываний.

Чек-лист по ролям

• DevOps/инженер:

  • Создать тревогу и протестировать срабатывание.
  • Настроить SNS и подписки.
  • Проверить IAM-права для тревоги.

• Владелец приложения:

  • Утвердить пороги и политику оповещений.
  • Назначить контактное лицо для инцидентов.

• Безопасность/Compliance:

  • Проверить, что уведомления не раскрывают конфиденциальные данные.

Критерии приёмки

• Тревога создана и видна в консоли CloudWatch.
• При достижении условия тревога переходит в состояние “In alarm” и отправляет уведомление в SNS.
• При отмене условия тревога переходит в состояние “OK”.
• Документация и владельцы назначены.

Диаграмма принятия решения

flowchart TD
  A[Нужен мониторинг числа объектов?] -->|Да| B{Требуется уведомление в реальном времени?}
  B -->|Да| C[Использовать Request Metrics или Lambda -> Custom Metric]
  B -->|Нет| D[Использовать Storage Metrics 'ежедневно' и создать CloudWatch Alarm]
  A -->|Нет| E[Рассмотреть S3 Inventory или логирование]

Примеры сценариев и случаи, когда это ломается

• Большие бакеты с миллиардами объектов: Storage Metric покажет агрегированное число, но задержка в обновлении может скрыть резкие изменения.
• Если у аккаунта нет прав на просмотр метрик S3, метрика не будет доступна для выбора.
• Если SNS-подписка не подтверждена (email), уведомления не будут доставлены.

Заключение

Мы прошли полный цикл: создание тревоги CloudWatch для S3 по NumberOfObjects, тестирование её переходов между состояниями, настройка уведомлений через SNS и удаление тревоги. Помните, что Storage Metrics удобны для учёта и периодического контроля, а для оперативных оповещений лучше рассмотреть Request Metrics или кастомные решения.

Краткая сводка приведена ниже.

Сводка:

• Storage Metrics обновляются раз в день и бесплатны.
• Request Metrics доступны каждую минуту, но платны.
• Настройте SNS и подтвердите подписки перед эксплуатацией.
• Документируйте и назначайте владельцев тревог.

Примечание: перед удалением тревоги убедитесь, что больше нет процессов, зависящих от её уведомлений.