Comments 22
Я еще не пробовал filebeat, но у меня сразу возникают два вопроса:
1 — если будет рестарт filebeat, то как он узнает с какого места перечитывать файл? Или же он снова начнет отправлять все файлы?
2 — Вы сказали, что logstash не должен отвечать за доставку данных и этим должен заниматься filebeat. Но не объяснли — почему? :)
2 — Вы сказали, что logstash не должен отвечать за доставку данных и этим должен заниматься filebeat. Но не объяснли — почему? :)
Logstash может выступать в качестве шиппера логов, конечно, но футпринт, мягко говоря, значительный. Написан на JRuby, требует целую JVM и гору памяти. Ставить такого монстра на каждый хост — лучше ресурсы веб-серверу или аппликухе отдать… А вот filebeat — это наследник logstash-forwarder (экс. lumberjack) — написан на Go, быстрый, портабельный (один бинарник) и нетребовательный к ресурсам. Что еще надо от агента?
Ответ на вопрос 2: Даже если посмотреть на сайт https://www.elastic.co то в разделении по продуктам вы увидете, что logstash занимается своими задачами, а доставка данных вынесена в отдельные сервисы. Этих сервисов у вас может быть много, а сервер обработки данных 1.
Вот тут https://github.com/sqshq/ELK-docker отличный docker-compose для сбора ELK.
https://github.com/elastic/kibana/issues/5170
Почему приняли решение отказаться?
Производительность сильно упала по сравнению с syslog? Что, если в ELK отправлять не всё подряд, а наиболее значимую информацию?
для отслеживания ситуации в реальном времени использовать стриминг on demand
Как вы это реализуете и с помощью чего?
https://habrahabr.ru/company/uteam/blog/278729/#comment_8799489
https://habrahabr.ru/post/275815/#comment_8751947
Кратко подытоживая: причины отказа низкая производительность, плохое масштабирование и проблемы со стабильностью. На данный момент у меня кластер А 10 машин (каждая машина 24 ядра 48 гб памяти) с трудом тянет 15к логов в секунду. На кластере Б памяти 128 гб на машину, что дает порядка 50к логов в секунду. Это при дневных индексах, 7-ми дневно ретеншене и около 1000 шард на кластер А, около 3000 шард на кластер Б. Если переключится на часовые индексы и снизить ретеншен до 3-х дней количество шард на кластере Б поднимается до 25к и он начинает падать с завидной периодичностью. У всех машин стоит по 4 диска 1.8тб. На кластере А количество документов около 7г и диски заняты от 26% до 45%, на кластере Б документов около 3.5г, диски заняты от 9% до 14%. Полный траффик логов у меня 130 логов/с, что значит мне нужно кластер А расширить до как минимум 200 машин, что будет 2 миллиона долларов только на покупку железа, обслуживание встанет в отдельные деньги. Глядя на подобные суммы начинаешь уже задумываться о спланке, который безумно дорог, но тебе вообще не надо думать об инфраструктуре.
Real time log streaming пока в стадии обдумывания. Самое простое решение, которое на данный момент обсуждается, это логировать все в локальные файлы на лог сервере с очень короткой ротацией и tail-ом отдавать их по http возможно фильтруя grep-ом. Но это предварительно, возможно все будет сложнее.
Отвечая на ваш вопрос об ограничении трафика в ELK: да, на маленьких объемах все работает нормально. Только вот объяснить людям, что не надо лить в логи все подряд (у меня был прецедент, когда начали заливали целиком http ответы, каждый log entry был за 100к) задача крайне не простая. И опять же мое крайне субъективное мнение: когда кто-то требует ELK утверждая, что только так он может гарантировать нормальную работу своего сервиса скорее всего что-то сильно не так с самим сервисом.
у sebp/elk есть один минус — до недавнего времени он не использовал тэги, кроме latest. Сейчас с этим чуть лучше. Мы на эти грабли наступили однажды, когда latest переключился на новый logstash, который стал несовместим с нашими конфигами. Рекомендую в продакшене использовать не один контейнер, а три, примерно по такой схеме:
logstash:
image: logstash:2.1.1
links:
- elasticsearch
elasticsearch:
image: elasticsearch:2.2.2
kibana:
image: kibana:4.3.1
ports:
- 5601:5601
links:
- elasticsearch
Тоже пользуемся ELK стеком. У меня на гитхабе есть докер-компоуз конфигурация с ELK и куратором (для регулярного удаления устаревших индексов, выполнения optimize итп), автоматической настройкой темплейтов Логстеша для Эластиксерча (по всем битсам) — может кому пригодится.
На текущем проекте в проде используем именно такую конфигурацию с небольшой кастомизацией. На наших объемах все работает хорошо.
Почему вы решили весь ELK стек положить в один контейнер? Это ведь противоречит одной из главных идей Докера — один процесс на контейнер, со всеми вытекающими плюсами.
Например в моем случае стояла цель сделать прототип, показать коллегам и получить добро на внедрение в продуктив.
ELK на Docker