Я ищу решение, которое позволило бы мне автоматически захватывать STDOUT / STDERR процесса, запущенного на Amazon EC2, и отправлять его (удаленно) на другой сервер.
Звучит просто, за исключением:
Я рассмотрел пару идей, но у каждой есть проблема:
Возможно, есть решение "системного журнала" с удаленным ведением журнала? но потребуется ли для этого отдельный экземпляр "по запросу" для сбора информации?
Любые советы и идеи будут оценены.
Спасибо, -g
Я надеялся, что от Amazon есть сервис «только добавлять» или «в основном добавлять», который предназначен для ведения журнала.
Может быть, как Amazon Kinesis?
Amazon Kinesis позволяет производителям передавать данные непосредственно в поток Amazon Kinesis. Например, журналы системы и приложений могут быть отправлены в Amazon Kinesis и доступны для обработки в считанные секунды. Это предотвращает потерю данных журнала при выходе из строя клиентского интерфейса или сервера приложений. Amazon Kinesis обеспечивает ускоренное получение потока данных, поскольку вы не группируете данные на серверах перед их отправкой для приема ».
Я еще не пробовал этого, потому что у меня есть надзорный процесс homebrew, который использует 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 или где-то еще) для сбора и хранения ваших сообщений.
Вот что я бы порекомендовал:
Несколько дополнительных комментариев: