вход/получение STDERR/STDOUT на Amazon EC2
Почему передача по каналу является огромными издержками? Из-за ввода?
Просто поместите свою команду в маленький сценарий/функцию/псевдоним и создайте ssh ключ без пароля и добавьте общедоступную часть к удаленному ~/.ssh/authorized_keys, и это станет, вероятно, намного легче.
Вы могли также использовать ssh ключ с паролем и кэшировать использование пароля
ssh-add ~/.ssh/your_private_key
Таким образом, Вы имеете безопасность ключа с паролем, но не должны вводить его каждый раз.
Иначе должен был бы создать туннели ssh к правильным портам. ssh-L... сделал бы это, считать человека ssh. Можно также добавить, что это туннелирует к ~/.ssh/config использование LocalForward, таким образом, Вы создаете соединение с этим портом туннели, уже определенные.
Я надеялся, что есть служба Amazon Kinesis «только добавлять» или «в основном добавлять», которая предназначена для ведения журнала.
Может быть, как 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 "секунды выполнения - в зависимости от того, что произойдет раньше -" flush "
Во-первых, в том, что вы работаете на EC2, нет ничего слишком особенного. При любой централизованной инфраструктуре ведения логов, вы хотите минимизировать шансы потери логов и, как следствие, получать логи как можно быстрее.
Во-вторых, не ждите здесь магии. Вам нужно сохранять сообщения логов где-нибудь , так что вам, скорее всего, придется запустить долго работающий экземпляр (либо внутри EC2, либо где-нибудь еще) для сбора и хранения сообщений.
Вот что я бы порекомендовал:
- Запустите ваше приложение, используя supervisord. Это не только даст вам некоторые рудиментарные возможности мониторинга/перезапуска процессов, но и, что более важно, супервизор будет обрабатывать сбор ваших выходных потоков и записывать их в лог-файлы.
- На каждом сервере приложений используйте logstash forwarder для чтения лог-файлов, которые записывает супервизор, и отправки их....
- A logstash/elasticsearch сервер, на котором logstash получает лог-файлы с ваших узлов, организует их (при необходимости) и отправляет на эластичный поиск для долговременного хранения и поиска.
Несколько дополнительных комментариев:
- Logstash forwarder способен шифровать свои соединения с logstash, поэтому при необходимости вы можете отправлять лог-файлы по общественным сетям, не беспокоясь об утечке информации.
- Elasticsearch достаточно прост в реализации и выполняет удивительную работу по индексации ваших сообщений
- Elasticsearch предоставляет REST-интерфейс, который вы можете использовать для отправки запросов, но если вам нужен веб-интерфейс, Kibana3 является отличным вариантом.
- Если вам нужно следить за логами и предупреждать/уведомлять об определенных шаблонах, лог-файл можно настроить на