Ограничение AWS CloudWatchLog

Я пытаюсь найти централизованное решение для переноса журнала моего приложения из базы данных (RDS).

Я думал использовать CloudWatchLog, но заметил, что есть ограничение на запросы PutLogEvents:

Максимальная скорость запроса PutLogEvents составляет 5 запросов в секунду на поток журнала.

Даже если я разбиваю свои журналы на множество потоков (на основе EC2, тип журнала - ошибка, информация, предупреждение, отладка), ограничение в 5 треб. в секунду по-прежнему очень ограничен для активного приложения.

Другое решение - каким-то образом накапливать журналы и отправлять PutLogEvents с пакетом записей журнала, но это означает, что тогда я вынужден использовать базу данных для накопления этих записей.

Итак, вопрос:

  1. Может я ошибаюсь и ограничение в 5 треб. в секунду не так уж и ограничительно?
  2. Есть ли какое-нибудь другое решение, которое я должен рассмотреть, например DynamoDB?

person Observer    schedule 15.04.2016    source источник


Ответы (3)


PutLogEvents предназначен для размещения нескольких событий по определению (согласно его имени: PutLogEvent "S") :) Агент журналов Cloudwatch делает это самостоятельно, и вам не о чем беспокоиться.

Однако обратите внимание: я не рекомендую вам создавать слишком много журналов (например, не запускать режим отладки в производстве), так как журналы облачных наблюдений могут стать довольно дорогими по мере роста вашего объема журналов.

person Tom    schedule 15.04.2016
comment
Спасибо за ответ Том, не могли бы вы уточнить: агент журналов Cloudwatch делает это самостоятельно, и вам не о чем беспокоиться. Я вызываю PutLogEvents прямо из своего приложения, есть ли другой способ отправить журналы моего приложения в CloudWatchLog? - person Observer; 15.04.2016
comment
Да, вы можете установить агент журналов cloudwatch и указать, какие файлы вы хотите отправить в AWS. См. Документацию здесь docs.aws.amazon.com/fr_fr/Watchon / latest / - person Tom; 15.04.2016
comment
Понятно, это означает, что я должен войти в файл (файловую систему). В настоящее время я ищу решение (сервис) на основе вызовов API. Спасибо за ваш вклад. - person Observer; 15.04.2016
comment
да, это действительно файл, но кажется довольно простым использовать файл вместе с агентом, вместо того, чтобы отправлять напрямую в cloudwatch. Какие преимущества вы получите от использования PutLogEvents вместо этого? у вас есть конкретный вариант использования, требующий этого? в этом случае вам придется буферизовать журналы, чтобы соблюсти ограничение в 5 запросов в секунду. - person Tom; 15.04.2016
comment
Другое решение, о котором я только что подумал: отправьте свои события в очередь sqs вместо журналов cloudwatch и используйте либо лямбда-функцию, либо рабочие, опрашивающие эту очередь, чтобы помещать события в журналы cloudwatch, не превышая лимит - person Tom; 15.04.2016
comment
Спасибо, Том, идея с SQS хороша и заслуживает изучения. - person Observer; 15.04.2016

Я бы посоветовал использовать решение Logstash на экземпляре AWS.

В качестве альтернативы вы можете запустить logstash на другом существующем экземпляре или контейнере.

https://www.elastic.co/products/logstash

Он разработан для этого прицела и прекрасно с этим справляется.

Cloudwatch не предназначен в основном для ваших нужд.

Надеюсь, это как-то поможет.

person Maurizio Benedetti    schedule 15.04.2016
comment
Спасибо, Маурицио, конечно, это помогает, но я бы предпочел решение, которое не требует управления с моей стороны. Еще раз спасибо - person Observer; 15.04.2016
comment
Я понимаю что ты имеешь ввиду. Вы пробовали взглянуть на эту официальную запись в блоге Amazon? aws.amazon.com/blogs/aws/cloudwatch-log-service - person Maurizio Benedetti; 15.04.2016

Если вы вызываете этот API непосредственно из своего приложения: краткий ответ заключается в том, что вам необходимо пакетировать события журнала (это 5 для PutLogEvent s).

Если вы записываете журналы на диск и после этого отправляете их, уже существует агент, который знает, как отправлять журналы (http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/QuickStartEC2Instance.html)

Мета: Я бы посоветовал вам создать прототип и убедиться, что он работает с тем объемом журнала, который у вас есть. Кроме того, имейте в виду, что из-за того, как работает api cloudwatch, только одно приложение / пользователь может одновременно отправлять поток журнала (см. Токен, который вы должны передать) - так что вам, вероятно, потребуется использовать несколько потоков, по одному на пользователя /, возможно, на тип журнала, чтобы ваши приложения не конкурировали за журнал.

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

person Mircea    schedule 15.04.2016