Re: Разбор ошибок в логах.
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.
Reply to: