On 2017-06-22, Tim Sattarov wrote: > я, чтобы избежать тормозов logstash, на всех источниках логов, где мог, > включил/настоял на JSON вывод. > теперь он только занимается складированием логов плюс небольшая логика > по развёртыванию geoip и user-agent информации.
Есть подозрение что конечным пунктом у Вас Elasticsearch. В общем я не в восторге от Logstash - требования по памяти нереальные и реализован на JRuby. Для "низкоуровневых" сервисов типа сбора/роутинга/доставки событий крайне печально выглядит. В основном то пользуються что бы обогатить события геотегом и определить тип девайсика на кофейной гуще. Если я ошибаюсь - поправьте! Даже сама компания-производитель для обогащения данных в Elasticsearch в момент инсерта придумала Ingest Nodes, почитайте: https://www.elastic.co/blog/new-way-to-ingest-part-1 What are Ingest Nodes? Ingest Nodes are a new type of Elasticsearch node you can use to perform common data transformation and enrichments. Легковесными сборшиками / мониторилками событий (серия *Beat от elastic.co) они впихивают данные уже напрямую в Ingest Nodes, минуя logstash. Ведь сама Elasticsearch - маштабируемая, работает в кластере с протоколами резервированния / балансировки данных. Я API не раскопал для доступа к этой ноде. Пока эксперементировал с REST/Json PUSH запросом на порт 9200. По 9300 можно типа как то эфективней вбрасывать, это порт общения между нодами в кластере, но протокол тоже не особо документирован. > По поводу потерь логов и буферизации - рекоммендуют использовать redis > или что то подобное. Я пока не заморачивался, но придётся. > Поток и размер логов стремительно растёт. > Я смотрю на https://redis.io/topics/introduction и не понимаю как применить на практике... Пока рассматривал такую идею логгера. Собирать события в очереди и по обьему / времени отправлять пачки по сети в рамках самого процеса. Если сервис не доступен или очередь переполнилась - писать на диск. Затем записанное отправить в более удачное время. Ключевым вижу (а Java позволяет) запустить отдельный поток отправляющий данные, выбрать неблокирующую очередь для сбора событий и сериализовать избыточные события в файлы. И все в рамках одного PID. Пока не ясно как эфективно сериализовать в файл и как помечать записаное / прочитаное, что бы файлы были в консистентном состонии, если само приложение упадет. Самым надежным местом записи есть файл. Всевозможные колекторы событий, слушащие порт рано или позно перегружаються и не будут недоступны. Потому доставкой события разумно повесить на само приложение, исключая пропажу сообщений, если колектор логов слишком долго в даунтайме. -- http://defun.work/
