On 22/06/17 06:42 PM, Oleksandr Gavenko wrote: > Есть подозрение что конечным пунктом у Вас Elasticsearch. Да, он самый ( и да, можно просто на "ты" ) > В общем я не в восторге от Logstash - требования по памяти нереальные и > реализован на JRuby. Для "низкоуровневых" сервисов типа > сбора/роутинга/доставки > событий крайне печально выглядит. > > В основном то пользуються что бы обогатить события геотегом и определить > тип девайсика на кофейной гуще. Если я ошибаюсь - поправьте! Это то чем я в основном пользуюсь, про кофейную гущу, это конечно сильно, вполне себе база расшифровки user-agent, по конкретным полям Но может он больше, просто на моих объёмах я не хочу перегружать его лишней логикой.
https://www.elastic.co/guide/en/logstash/current/filter-plugins.html > Даже сама компания-производитель для обогащения данных в 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. Ingest node нужна для прямолинейного ввода данных, примерно так же как в моём сценарии, когда данные идут уже в готовом виде и никакой обработки в процессе не нужно. Если нужны нестандартные пути ввода, вывода и фильтрация - без logstash в этом решении не обойтись. Я как раз был на ElasticON, когда они объявили версию 5 и все эти новые типы нод. Кстати, тогда же они объявили, что переписали часть logstash на чистой Java. и продолжают переписывать и отказываться от JRuby > > Я API не раскопал для доступа к этой ноде. Пока эксперементировал с REST/Json > PUSH запросом на порт 9200. По 9300 можно типа как то эфективней вбрасывать, > это порт общения между нодами в кластере, но протокол тоже не особо > документирован. весь ingest node API это pipelines и HTTP PUT в эти пайпы. https://www.elastic.co/guide/en/elasticsearch/reference/5.4/ingest.html я сам не пользуюсь пока новыми нодами, потому что пока остался на версии 2.x транспортный протокол (порт 9300) удобнее в каких то случаях, но я пользовался только REST (9200) клиенты расписаны здесь https://www.elastic.co/blog/found-java-clients-for-elasticsearch https://www.elastic.co/guide/en/elasticsearch/client/index.html я думаю, при желании можно разобраться в протоколе или просто использовать библиотеки доступа. > Я смотрю на https://redis.io/topics/introduction и не понимаю как применить на > практике... Пример расписан здесь: http://www.rsyslog.com/coupling-with-logstash-via-redis/ Другой вариант, о котором все говорят для буферизации это Apache Kafka (тоже Java) небольшой оффтопик: Кстати, мне интересно, что все катят бочку на systemd, и никто не жалуется на rsyslog. Если посмотреть, как они меняют формат конфига, шифруются с документацией и предлагают свои платные сервисы по настройке всего, тут явный шкурный интерес. и это один из основных сервисов в системе, ставится тоже по умолчанию и имеет кучу обратных зависимостей. > Пока не ясно как эфективно сериализовать в файл и как помечать записаное / > прочитаное, что бы файлы были в консистентном состонии, если само приложение > упадет. Можно писать в файл и скормить этот файл rsyslog, он будет отслеживать последнюю позицию, до которой все события отправлены. он же может отсылать данные, пока не получит подтверждения о приёме. примеры на том же rsyslog.com. > Потому доставкой события разумно повесить на само приложение, исключая > пропажу сообщений, если колектор логов слишком долго в даунтайме. я у себя отдаю всё действия связанные с логами специализированной программе - (r)syslog. Тот самый доморощенный Unix-way, о котором все говорят: программа делает одно и делает это хорошо. rsyslog может собирать события с клиентов, протокол общения выверен годами, специализированных клиентов обычно не нужно. Формат выдачи можно настроить по желанию (я перевожу в JSON, то, что ещё не переведено клиентом, на стороне rsyslog) rsyslog стоит везде, ставить отдельный сборщик типа filebeats я не хотел, лишнее звено. а потом уже rsyslog может переслать всё по сети в центральное хранилище, можно по JSON поверх TCP, можно по протоколу syslog, как будет удобнее. Если сервера долго живущие, и на них можно заходить и смотреть локальные логи - то, конечно, лучше держать копию локально. В динамической среде приходится надеяться на центральное хранилище: сервер может быть в любой момент остановлен и удалён. небольшое отступление про ELK (основная тройка продуктов от elastic.co): мне совершенно не нравится как и на чем они написаны, всей душой не люблю ни Java, ни Ruby ни Nodejs с его npm. Но, к сожалению, ничего лучше на рынке пока нет. Идея хорошая и та часть, с которой общаются пользователи, тоже неплоха. Радостно видеть, что они наконец начинают переходить на Golang (все *Beats). полностью с Java они не уйдут, так как используют Apache Lucene.