Регистрация / захват STDERR/STDOUT на Amazon EC2
Я ищу решение, которое позволило бы мне автоматически захватывать STDOUT/STDERR процесса, выполняющегося в Amazon EC2, и отправлять его (удаленно) на другой сервер.
Звучит просто, кроме:
- Я буду использовать точечные экземпляры, что означает, что я не контролирую точно, когда они запускаются, и они могут завершиться в любую минуту (без надлежащего выключения)
- Поскольку нет остановки, я не могу записать в локальный файл и передать его (например, на s3), когда процесс завершен.
- Выходные данные плохо структурированы (например, нет табличных полей в файле журнала), поэтому "Стандартные" решения для ведения журнала в облаке не являются тривиальными, и использование одной из облачных баз данных не является идеальным.
Пара идей, которые я рассмотрел, но у каждого есть проблема:
- Добавление к файлу на "s3" невозможно, а перезапись файлов выполняется слишком медленно для ведения журнала.
- Насколько мне известно, совместное использование томов EBS (в качестве дисков) невозможно.
- Использование "simple_db" звучит слишком медленно (а "simple_db" был в бета-версии уже много лет, поэтому я не уверен, что его можно использовать).
- Использование SQS (например, одно сообщение на строку вывода?) Очень медленное.
- Перенаправление на сетевой сокет не удастся, если соединение разорвется на секунду (например, "myprogram 2>&1 | nc my.log.server 7070"
Возможно, есть решение "syslog" с удаленной регистрацией? но потребуется ли для этого отдельный экземпляр "по требованию" для сбора информации?
Любые советы и идеи будут оценены.
Спасибо -g
2 ответа
Я надеялся, что есть какой-то сервис "только добавление" или "в основном добавление" от amazon, который предназначен для регистрации.
Может, как Amazon Kinesis?
С помощью Amazon Kinesis вы можете заставить производителей отправлять данные непосредственно в поток Amazon Kinesis. Например, системные журналы и журналы приложений могут быть отправлены в Amazon Kinesis и доступны для обработки в считанные секунды. Это предотвращает потерю данных журнала при сбое внешнего сервера или сервера приложений. Amazon Kinesis обеспечивает ускоренный прием данных, поскольку вы не собираете данные на серверах до того, как отправите их на прием ".
Я еще не пробовал, потому что у меня есть процесс доморощенного супервизора, который использует S3 и SQS... в начале потока он создает уникальные имена для временных файлов (в экземпляре), которые будут захватывать журналы и отправлять сообщение через SQS, в результате которого информация о процессе и его местоположениях файла журнала сохраняется в базе данных; когда процесс останавливается (это запланированные или управляемые событиями, а не постоянно выполняющиеся задания), отправляется другое сообщение SQS, которое содержит избыточную информацию о том, где находились временные файлы, и дает мне статус завершения процесса; затем оба журнала (выход и ошибка) сжимаются и загружаются в S3, при этом каждый из этих процессов генерирует дополнительные сообщения SQS, сообщающие о состоянии загрузки S3...
Сообщения SQS, как вы могли заметить, в значительной степени избыточны, но они предназначены для того, чтобы практически исключить вероятность того, что я ничего не узнаю о существовании процесса, поскольку все 4 сообщения (start, stop, stdout-upload-info, stderr-upload-info) содержит достаточно информации, чтобы идентифицировать хост, процесс, аргументы и то, куда будут или должны уйти или должны были уйти файлы журнала, на этапе S3. Конечно, вся эта избыточность была почти полностью ненужной, поскольку процесс и SQS/S3 очень стабильны, но избыточность существует, если это необходимо.
Мне не нужна регистрация в реальном времени для этих заданий, но если бы я это сделал, другой вариант мог бы изменить сборщик журналов, чтобы вместо сохранения журналов и последующей отправки их в блок на S3, я мог бы для каждого "x"собранных байтов журнала или каждые"y"секунд выполнения - в зависимости от того, что произошло раньше - " сбросить "накопленные данные в сообщение SQS... не было бы необходимости отправлять сообщение SQS для каждой строки.
Во-первых, нет ничего особенного в том, что вы работаете на EC2. С любой инфраструктурой централизованного ведения журналов вы хотите минимизировать вероятность потери журналов и, следовательно, должны получать журналы как можно скорее.
Во-вторых, не ожидайте здесь магии. Вам нужно где-то сохранять свои сообщения журнала, поэтому вам, вероятно, понадобится запустить долго работающий экземпляр (либо внутри EC2, либо в другом месте) для сбора и хранения ваших сообщений.
Вот что я бы порекомендовал:
- Запустите ваше приложение, используя http://supervisord.org/. Это не только даст вам некоторые элементарные возможности мониторинга / перезапуска процессов, но, что более важно, supervisord будет обрабатывать сбор ваших выходных потоков и запись в лог-файлы.
- На каждом сервере приложений используйте logstash forwarder, чтобы прочитать файлы журнала, которые записывает supervisord, и отправить их в...
- Сервер logstash/ asticsearch, на котором logstash получает журналы от ваших узлов, организует их (при необходимости) и отправляет их в asticsearch для долгосрочного хранения и поиска.
Несколько дополнительных комментариев:
- Экспедитор Logstash может зашифровать свои сообщения с помощью Logstash, так что вы можете при необходимости отправлять свои журналы через публичные сети, не беспокоясь о утечке информации.
- Elasticsearch довольно прост в реализации и прекрасно справляется с индексацией ваших сообщений.
- Elasticsearch предоставляет интерфейс REST, который вы можете использовать для выдачи запросов, но если вам нужен веб-интерфейс, Kibana3 - отличный вариант.
- Если вам нужно отслеживать свои журналы и предупреждать / уведомлять о некоторых шаблонах, logstash может быть настроен для этого