Мое приложение размещено на кластере Amazon EC2. Каждый экземпляр записывает события в файлы журнала. Мне нужно собрать (и данные мои) по этим журналам в конце каждого дня. Каков рекомендуемый способ сбора этих журналов в центральном месте? Я думал, что из нескольких вариантов, не зная, в какую сторону идти:Что такое хороший способ сбора журналов из экземпляров Amazon EC2?
Я убежище Это еще не реализовано, но я столкнулся с Facebook Scribe, и это кажется хорошей идеей. https://github.com/facebookarchive/scribe
До тех пор пока я не получу это, я делал то, что вы упоминаете для # 1 - У меня есть задание cron, которое использует sftp для вытягивания файлов. Я выбрал это, потому что, даже если я сделал # 2, у меня были экземпляры, где машина ec2 сработала, и мне все равно пришлось вытаскивать лог-файлы.
Посмотрите бесплатную версию Splunk - она будет обрабатывать коллекцию файлов удаленных журналов, а также даст вам действительно интересные инструменты для поиска и анализа.
Использовать syslog-ng, популярный инструмент, который передает сообщения журнала через TCP, опционально зашифрованные.
Я не пробовал его для этой цели, но Amazon по всей видимости, рекомендуется использовать SimpleDB:
http://aws.amazon.com/simpledb/usecases_logging/
Вот пакет, который может оказаться полезным - он говорит, что вы можете использовать это захватить стандартный вывод/STDERR в SimpleDB:
Я использую Loggly и, кажется, сделать трюк
Это позволяет мне послать все мои журналы через ТСР их службы и имеют центральное место контролировать все мои файлы журналов,
Это также позволяет мне архивировать мои файлы журнал в S3, который слишком хорошо
Мы используем Logstash на каждый хост (развернутый с помощью Puppet) для сбора и судовых события в очередь сообщений (RabbitMQ, но может быть Redis) на центральном хосте. Другой экземпляр Logstash извлекает события, обрабатывает их и заносит результат в ElasticSearch. A Kibana web-интерфейс используется для поиска через эту базу данных.
Он очень способен, легко масштабируется и очень гибкий. В Logstash имеется множество фильтров для обработки событий с различных входов и может выводиться на множество сервисов, одним из которых является ElasticSearch. В настоящее время мы отправляем около 1,2 миллиона событий журнала в день из наших экземпляров EC2, на легком оборудовании. Задержка для события журнала от события до поиска составляет около 1 секунды в нашей настройке.
Вот некоторые документы по настройке такого типа: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html и демонстрация интерфейса поиска Kibana с некоторыми живыми данными.
Чтобы добавить к этому, если вы обнаружите, что производительность logstash на вашем хосте слишком требовательна вы можете посмотреть https://github.com/elasticsearch/logstash-forwarder. Он написан в golang и имеет гораздо меньше накладных расходов, чем весь проект logstash, но имеет достаточно ресурсов для работы с журналами с вашего хоста и в вашей системе ведения журнала (где вы можете их использовать с различными входными плагинами logstash). – semi
Я бы рекомендовал отправить журналы на S3, а затем хвост журнала с s3, используя logstash + elasticsearch. (Используйте контрольную сумму для генерации идентификатора elasticsearch для записей журналов дедуплирования, вызванных повторными файлами рестайлинговой обработки логсташей). Таким образом, вам не нужно беспокоиться о потере кластера Elasticsearch и упростить и упростить перемещение вашего ES-кластера. Это также открывает вам гораздо более сложные аналитические инструменты, такие как EMR и Redshift. –
В эти дни Logstash-forwarder был заменен различными Beats (https://www.elastic.co/products/beats). Filebeat для лог-файлов, Metricbeat для показателей, Packetbeat для регистрации сетевого трафика и т. Д. Они очень легкие. Кроме того, Logstash 5.4 имеет функцию Persistent Queue, которая уменьшает необходимость в отдельной очереди сообщений, что упрощает развертывание. –
Этот вопрос старый (декабрь 2014 года), но по-прежнему высоко оценивается во время поиска Google по этой теме.
Amazon теперь предоставляет способ сделать некоторые из этого через CloudWatch. Он имеет возможность сопоставлять шаблону с сообщением журнала и запускать аварийные сигналы на основе событий, происходящих в приложении. В зависимости от характера данных, которые необходимо выполнить, может быть возможно использовать их API для получения желаемых, совокупных событий. См http://aws.amazon.com/blogs/aws/cloudwatch-log-service/
* Отказ от ответственности: Я работаю в суме:
сумо Logic Free является относительно простым вариантом, а также:
«Это также позволяет мне архивировать мои файлы журнал в S3, который тоже хорошо », означает ли это, что loggly - это ваша первая точка назначения ?, отправляются лог-файлы, а затем вы отправляете в архиве сжатые архивы на S3? Я пытаюсь получить эту установку, где у меня есть централизованный мониторинг для всех моих файлов журналов, но я все еще могу хранить архивные .gz-файлы на s3 – Donna