Amazon Cloudwatch предоставляет некоторые очень полезные показатели для мониторинга моих EC2, балансировщиков нагрузки, баз данных эластичности и RDS и т. Д. И позволяет мне настраивать сигналы тревоги по целому ряду критериев; но есть ли способ настроить его для мониторинга моих S3? Или есть ли какие-либо другие инструменты мониторинга (помимо простого включения ведения журнала), которые помогут мне отслеживать количество запросов POST/GET и томов данных для моих ресурсов S3? И для обеспечения сигналов тревоги для пороговых значений активности или увеличения количества хранилищ данных?AWS Мониторинг Cloudwatch для S3
ответ
Я также не смог найти способ сделать это с помощью CloudWatch. На этот вопрос с апреля 2012 года ответил Derek @ AWS, поскольку он не имеет поддержки S3 в CloudWatch. https://forums.aws.amazon.com/message.jspa?messageID=338089
Единственное, что я мог подумать, - это импортировать журналы доступа S3 в службу журналов (например, Splunk). Затем создайте настраиваемую метку облачного просмотра, где вы публикуете данные, которые вы анализируете из журналов. Но тогда вам нужно отфильтровать опрос журналов доступа и ... И пока вы были на нем, вы могли бы просто создать аварийные сигналы в Splunk, а не в S3.
Если ваш вариант использования - просто предупредить, когда вы его слишком много используете, вы можете настроить оповещение о выставлении счетов для использования S3.
Я думаю, что это может зависеть от того, где вы хотите отслеживать доступ. То есть если вы пытаетесь измерить/наблюдать использование объектов S3 из-за внешних запросов http/https, то предложение Энтони, если разрешить регистрацию S3 и затем импортировать в splunk (или красное смещение) для анализа, может работать. Вы также можете смотреть статус биллинга по запросам каждый день.
Если пытаться Guage использования внутри ваших собственных приложений, есть некоторый AWS SDK cloudwatch метрика:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/metrics/package-summary.html
и
S3 представляет собой управляемый сервис, а это означает, что вам не нужно предпринимать действия на основе системных событий, чтобы поддерживать их работоспособность (пока вы можете позволить себе оплатить использование услуги). Дух CloudWatch заключается в том, чтобы помочь с услугами мониторинга, которые требуют от вас принятия мер, чтобы они не работали.
Например, экземпляры EC2 (которым вы управляете сами), как правило, нуждаются в мониторинге для предупреждения, когда они перегружены или когда они недоиспользуются, или когда они вылетают; в какой-то момент необходимо предпринять действия, чтобы развернуть новые экземпляры для масштабирования, открутить неиспользуемые экземпляры, чтобы снова масштабироваться или перезагрузить экземпляры, которые разбились. CloudWatch призван помочь вам более эффективно управлять этими ресурсами.
AWS S3 - это управляемое хранилище. Единственными метриками, доступными в AWS CloudWatch для S3, являются NumberOfObjects
и BucketSizeBytes
. Чтобы лучше понять ваше использование S3, вам нужно сделать дополнительную работу.
Недавно я написал функцию AWS Lambda делать именно то, что вы просите, и он доступен здесь:
https://github.com/maginetv/s3logs-cloudwatch
Он работает путем разбора файлов S3 на стороне сервера журналов и агрегатов/экспорт показателей для AWS Cloudwatch (CloudWatch позволяет публиковать специальные показатели).
Пример графики, которые вы получите в AWS CloudWatch после развертывания этой функции на вашем счете AWS являются:
RestGetObject_RequestCount
RestPutObject_RequestCount
RestHeadObject_RequestCount
BatchDeleteObject_RequestCount
RestPostMultiObjectDelete_RequestCount
RestGetObject_HTTP_2XX_RequestCount
RestGetObject_HTTP_4XX_RequestCount
RestGetObject_HTTP_5XX_RequestCount
+ many others
Поскольку метрики экспортируются в CloudWatch, вы можете легко настроить сигналы тревоги для них. Шаблон CloudFormation включен в репозиторий GitHub, и вы можете быстро развернуть эту функцию, чтобы получить видимость в использовании вашего ведра S3.
EDIT 2016-12-10:
В ноябре 2016 АМС добавил в дополнительные метрики запроса S3 в CloudWatch, которые могут быть включены при необходимости. Сюда относятся такие показатели, как AllRequests
, GetRequests
, PutRequests
, DeleteRequests
, HeadRequests
и т. Д. Более подробную информацию об этой функции см. В документации Monitoring Metrics with Amazon CloudWatch.
- 1. Перемещение журналов CloudWatch на S3 в AWS
- 2. AWS ElasticBeanstalk и AWS CloudWatch
- 3. Специальное действие AWS Cloudwatch
- 4. AWS Cloudwatch метрическая фильтрация
- 5. AWS Lambda functions + CloudWatch
- 6. AWS CloudWatch - Подпись expired
- 7. Ruby AWS SDK CloudWatch
- 8. Цена для пользовательских показателей CloudWatch
- 9. AWS Cloudwatch setup WebHook
- 10. AWS Cloudwatch Heartbeat Alarm
- 11. AWS Cloudwatch Monitoring
- 12. AWS-CloudWatch: InvalidSequenceTokenException
- 13. Служба журнала AWS Cloudwatch
- 14. Аварийные сигналы AWS RDS cloudwatch
- 15. AWS CloudWatch для запуска/остановки экземпляров EC2
- 16. AWS CloudWatch Alarms для нескольких экземпляров EC2
- 17. Использование AWS cloudwatch для мониторинга nginx ngx_http_stub_status_module
- 18. aws cloudwatch metric overwrite/override
- 19. AWS CloudWatch Оценка веб-сервера
- 20. Где я могу экспортировать журналы AWS Cloudwatch (для Loggly)?
- 21. Где aws cloudwatch Logs state_file?
- 22. AWS EC2 интерпретация метрик CloudWatch
- 23. Понимание AWS Lambda CloudWatch журналы
- 24. Фильтр AWS Cloudwatch Lambda's Log
- 25. AWS Cloudwatch получить имена тревог
- 26. Мониторинг всех кластеров AWS
- 27. Мониторинг состояния экземпляра aws
- 28. Анализировать Cloudwatch Вход Уже вывезенным в S3
- 29. Настройка аварийных сигналов на AWS Cloudwatch
- 30. Как настраивать метрики CloudWatch с AWS Lambda
Существует множество инвариантов, которые могут понадобиться службе, которая может быть получена из S3. Например, система может иметь инвариант, чтобы каждый объект добавлялся в ведро S3 каждый час, или необходимо предпринять действия для восстановления службы. Мониторинг этого с использованием отдельной службы является хрупким. – user239558