Возможно ли иметь централизованное ведение журнала для приложений Docker для ElasticBeanstalk?

У нас есть пользовательское веб-приложение Docker, работающее в контейнерной среде Elastic Beanstalk Docker. Хотелось бы иметь журналы приложений для просмотра снаружи. Без загрузки через экземпляры или консоль AWS.

До сих пор ни один из решений не был приемлемым. Может быть, кто-то достиг централизованного ведения журналов для приложений Elastic Benastalk Dockerized?

Решение 1: загрузка журнала консоли AWS

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

Решение 2: S3 + Elasticsearch + Fluentd

У fluentd нет плагина для извлечения журналов из S3 Там отличный плагин S3, но он только для выхода журнала на S3. не для входных журналов из S3.

Решение 3: S3 + Elasticsearch + Logstash

минусы: Можно вытащить все журналы всего цеха или ничего.

Проблема заключается в структуре хранилища Elastic Beanstalk S3. Вы не можете указать шаблон имени файла. Это либо все журналы, либо ничего. ElasticBeanstalk сохраняет журналы на S3 в пути, содержащем случайные экземпляры и идентификаторы среды:

s3.bucket/resources/environments/logs/publish/e-<random environment id>/i-<random instance id>/[email protected]

Плагин Logstash s3 можно указать только на ресурсы/среды/журналы/публикацию/. Когда вы пытаетесь указать его в средах /logs/publish/ */my.log, это не сработает. что означает, что вы не можете вытащить определенный журнал и тег/тип, чтобы он мог найти в Elasticsearch. Поскольку AWS сохраняет журналы из всех ваших сред и экземпляров в одной структуре папок, вы не можете выбрать даже экземпляр.

Решение 4: просмотр журнала событий в CloudWatch для AWS

Можно пересылать свои собственные журналы в консоль CloudWatch. Удалите это, поместите файлы конфигурации в путь .ebextensions вашего пакета приложений: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.cloudwatchlogs.html

Есть файл cwl-webrequest-metrics.config, который позволяет вам указывать файлы журналов вместе с предупреждениями и т.д. Большой!? за исключением того, что формат файла конфигурации не является ни yaml, xml, ни Json, и он не документирован. Существует абсолютно нулевое упоминание этого файла, оно отформатировано либо на сайте документации AWS, либо в любом месте в сети. И чтобы получить один файл журнала, появляющийся в CloudWatch, это не просто добавление строки конфигурации. Единственный возможный способ получить эту работу - это проб и ошибок. Большой!? за исключением каждой попытки повторного развертывания вашей среды.

Есть только одна ссылка на то, как заставить эту работу работать с настраиваемым журналом: http://qiita.com/kozayupapa/items/2bb7a6b1f17f4e799a22 Я понятия не имею, как этот человек обратил проектирование формат файла.

минусы:

  • Cloudwatch, похоже, не может разделить журналы на столбцы при отображении, поэтому вы не можете легко фильтровать по приоритету и т.д.
  • В программе просмотра журнала AWS Console нет автоматического обновления для ведения журналов.
  • Недопустимый формат файла конфигурации Nightmare, без возможности тестирования. Для проб и ошибок требуется повторное развертывание всего экземпляра.

ОТВЕТЫ

Ответ 1

Возможно, применима функция AWMS лямбда?

Напишите некоторый javascript, который сбрасывает все уведомления, а затем посмотрите, что вы можете с ними сделать.

После записи объекта вы можете переименовать его в пределах одного и того же ведра?

Или уведомить собственную службу управления журналом о создании нового объекта?

Здесь много возможностей...

Ответ 2

Я начал использовать Sumologic на данный момент. Там бесплатная пробная версия, а затем бесплатный уровень (500 мб/день, 7 дней хранения). Я еще не вышел из пробного периода, и мое приложение EB практически ничего не делает (это всего лишь несколько HTML-страниц, которые обслуживает Nginx в контейнере докеров. Похоже, что он может стать дорогим, если вы нажмете сколько-нибудь серьезное количество журналов.

Он работает нормально до сих пор. Вам нужно создать пользователя IAM, у которого есть доступ к ведерке S3, которую вы хотите прочитать, а затем он засасывает журналы на сумологические серверы и выполняет всю обработку и поиск там. Немного сложно настроить, но я не вижу, как это может быть проще и достаточно хорошо документировано.

Он позволяет вам предоставлять разные выражения пути с помощью подстановочных знаков, а затем назначать "sourceCategory" для этих разных путей. Затем вы используете эти sourceCategories для фильтрации поиска в журнале для определенного типа ведения журнала.

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

Ответ 3

Вы можете использовать среду Multicontainer, обмениваясь папкой журнала с другим контейнером докеров, используя инструмент, который вы предпочитаете централизовать журналы, в нашем случае мы подключили Apache Flume для перемещения файлов в HDFS. Надеюсь, это поможет вам в этом.

Ответ 4

Самый простой метод, который я нашел для этого, заключался в использовании papertrail через rsyslog и .ebextensions, однако это очень дорого для регистрации всего.

Хорошая часть с rsyslog вы можете по существу отправлять свои журналы в любом месте, и вы не привязаны к papertrail.

пример ebextension

Ответ 5

Я нашел loggly, чтобы быть наиболее удобным.
Это размещенная служба, которая может быть не такой, какой вы хотите. Однако, если вы просмотрите страницу , вы можете увидеть несколько способов поддержки вашей ситуации (специальные решения для докеров, а также, например, 10 амазонских опций). Даже если loggly не соответствует вашему вкусу, вы можете посмотреть на эти решения и легко увидеть, как некоторые из них могут быть применены к большинству централизованных решений для ведения журналов, которые вы можете использовать или писать.