Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
прошу меня простить, это не вброс guano на вентилятор. Но все же…
Мне кажется — это адский треш, если логи валятся очень быстро и очень много. ( ну скажем от 5k events/sec и масса среза, ну скажем >1Тб )
А вот почитать что-то вроде graylogUI vs kibana было бы интересно.
Для работы ему нужна Java, логи он будет хранить в MongoDB, для поиска использовать ElasticSearch.
Мне кажется — это адский треш, если логи валятся очень быстро и очень много. ( ну скажем от 5k events/sec и масса среза, ну скажем >1Тб )
А вот почитать что-то вроде graylogUI vs kibana было бы интересно.
Встречный вопрос, что не так в этой связке? MongoDB как NoSql база должна показывать хорошую производительность на вставку данных.
С одной стороны компетентные товарищи говорят, что монгу, со времен 2,6 допилили. С другой стороны, в моем опыте использования mongo — это были вечные проблемы с консистентностью, и диском, с запутанной системой кластеризации. ES точно так же может выступать как nosql база, а масштабируется он куда проще и удобнее.
Возможно я не прав, но без должного ухода (читай как: elasticsearch, как хранилище его не требует) хранить в монге много много данных выглядит не целесообразно.
Возможно я не прав, но без должного ухода (читай как: elasticsearch, как хранилище его не требует) хранить в монге много много данных выглядит не целесообразно.
Автор ошибся. Он уже давно не хранит логи в MongoDB ( сейчас там хранится только конфигурация ). Для хранения и поиска используется ElasticSearch.
Сам использую GrayLog2 и мне показалось, что документация у него довольно понятная и подробная, так что было бы интереснее узнать опыт реальной эксплуатации продукта, «подводные камни» и т.п.
Например: GraylogCollector не поддерживает новую архитектуру EventLog, так что его использование на Windows сильно ограничено. Бесплатный NXLog Community имеет ограниченный функционал ( правда, которого хватит почти всем ), за расширение надо доплачивать.
Сам использую GrayLog2 и мне показалось, что документация у него довольно понятная и подробная, так что было бы интереснее узнать опыт реальной эксплуатации продукта, «подводные камни» и т.п.
Например: GraylogCollector не поддерживает новую архитектуру EventLog, так что его использование на Windows сильно ограничено. Бесплатный NXLog Community имеет ограниченный функционал ( правда, которого хватит почти всем ), за расширение надо доплачивать.
Я давно и плотно сижу на ELK стеке, но приглядываю за конкурентами. Собственно а почему он не хранит конфигурацию в ES, как та же kibana например?
Например что бы иметь возможность стартовать без ES.
А ещё ES для хранения логов подразумевает возможность большой нагрузки на ES.
Будет неприятно, если из-за очередного запроса логов отвалятся все сессии у пользователей (ведь в эластике очередь запросов ограничена, и если очередь заполнена, запросы режектятся).
Ах да, ещё у ES есть проблема с изменением данных. Любое изменение — это создание новой записи и удаление старой (причём физически данные удаляются только после переиндексирования).
А ещё ES для хранения логов подразумевает возможность большой нагрузки на ES.
Будет неприятно, если из-за очередного запроса логов отвалятся все сессии у пользователей (ведь в эластике очередь запросов ограничена, и если очередь заполнена, запросы режектятся).
Ах да, ещё у ES есть проблема с изменением данных. Любое изменение — это создание новой записи и удаление старой (причём физически данные удаляются только после переиндексирования).
Например что бы иметь возможность стартовать без ES.
а смысл?
А ещё ES для хранения логов подразумевает возможность большой нагрузки на ES.
Будет неприятно, если из-за очередного запроса логов отвалятся все сессии у пользователей (ведь в эластике очередь запросов ограничена, и если очередь заполнена, запросы режектятся).
при 150k event/sec на 4 головы ES + 1 голова только на http. Все машины 12 ядер на 16 гигов оперативы, обычные SAS диски, полет нормальный. А кластер работает с приличным запасом по мощности.
Ах да, ещё у ES есть проблема с изменением данных. Любое изменение — это создание новой записи и удаление старой (причём физически данные удаляются только после переиндексирования).
иииииииии? в чем тут проблема?
1. Graylog умеет скидывать логи в журнал, если не может залить их в elastic. Мне например это позволяет спокойно перезапускать/обновлять единственную ноду ELK без страха потерять данные (сыпятся не только логи, но и реалтайм статистика, которая не хранится на хостах)
2. А у меня один слабенький сервер на виртуалке и очередь эластика частенько забивается. Особенно если запускать поиски на большие периоды. А ещё я использую Grafana для графиков, а она не умеет отменять запросы. И если несколько раз тыкнуть refresh на графиге — генерятся тысячи запросов (хоть и не сложных).
3. В том что модификации внутри сессии веб-морды происходят постоянно => индекс будет распухать непонятно ради чего.
2. А у меня один слабенький сервер на виртуалке и очередь эластика частенько забивается. Особенно если запускать поиски на большие периоды. А ещё я использую Grafana для графиков, а она не умеет отменять запросы. И если несколько раз тыкнуть refresh на графиге — генерятся тысячи запросов (хоть и не сложных).
3. В том что модификации внутри сессии веб-морды происходят постоянно => индекс будет распухать непонятно ради чего.
1. Опять же — а смысл? При приличном потоке евентов память забьется моментально. А если эвентов мало, то и syslog достаточно. Хотя каждый городит свой огород. В моем понимании — это скорее минус. Прием который может привести к неявной деградации системы или падению.
2. Может просто перейти на syslog+grep? Я не троллю, просто не вижу смысла использовать подобные системы не имея для них железа.
3. ЭЭЭЭЭ… и? Я не понимаю то же тут проблемы. настроить чистку индекса не проблема от слова вообще. Я пользуюсь кибаной, и даже в объемных конфигурациях ее метаданные больше пары мегабайт не весили. Если что-то там так пухнет, такую систему надо на помойку.
А если хранить в монго — это лишняя память на сервис, лишние IO на перечитывание данных, это свои очереди, а не эластика.
2. Может просто перейти на syslog+grep? Я не троллю, просто не вижу смысла использовать подобные системы не имея для них железа.
3. ЭЭЭЭЭ… и? Я не понимаю то же тут проблемы. настроить чистку индекса не проблема от слова вообще. Я пользуюсь кибаной, и даже в объемных конфигурациях ее метаданные больше пары мегабайт не весили. Если что-то там так пухнет, такую систему надо на помойку.
А если хранить в монго — это лишняя память на сервис, лишние IO на перечитывание данных, это свои очереди, а не эластика.
1. Журнал хранится на диске. В грейлоге данные поступают в Input (которых может быть много и они плагины), оттуда в Process, либо в Journal, если очередь Process занята.
2. Syslog+grep вообще не пойму зачем. Я собираю логи с кучи хостов (на винде и лине) + с роутеров по SNMP.
3. ES предназначен для хранения огромных объёмов данных с возможность быстрого поиска. Mongo — быстрая in-memory база. По моему логично под каждую задачу использовать подходящий инструмент. Kibana использует ES думаю только для продвижения своей платформы.
2. Syslog+grep вообще не пойму зачем. Я собираю логи с кучи хостов (на винде и лине) + с роутеров по SNMP.
3. ES предназначен для хранения огромных объёмов данных с возможность быстрого поиска. Mongo — быстрая in-memory база. По моему логично под каждую задачу использовать подходящий инструмент. Kibana использует ES думаю только для продвижения своей платформы.
Угу, я понял. Комментариев больше не имею. Мы говорим о слишком разных объемах данных, стабильности и удобстве. :)
У вас «150k event/sec на 4 головы ES + 1 голова только на http» и syslog+grep удобнее? Или я что-то не так понял?
У меня действительно нагрузка поменьше — 3k/sec и одна нода ES.
У меня действительно нагрузка поменьше — 3k/sec и одна нода ES.
не так поняли :)
если мало логов, то и грепа достаточно. Если много, то зачем городить непонятные огороды.
если мало логов, то и грепа достаточно. Если много, то зачем городить непонятные огороды.
Очень удобно, когда все логи с машин в одном месте.
Легче находить корреляции при анализе, можно строить дашборды, алерты, управлять доступом к логам.
Если например стоит один сервер apache, то наверное толку не оч много.
А если надо обслуживать несколько взаимодействующих между собой программ, разбросанных по разным хостам — то я не представляю жизни без грейлога.
Легче находить корреляции при анализе, можно строить дашборды, алерты, управлять доступом к логам.
Если например стоит один сервер apache, то наверное толку не оч много.
А если надо обслуживать несколько взаимодействующих между собой программ, разбросанных по разным хостам — то я не представляю жизни без грейлога.
Я о том и говорю. Но только с моей точки зрения, использование двух сторов для этой цели — вещь избыточная, а значит костыльная и не стабильная.
Так mongo стоит только рядом с грейлогом, так же как и его журнал.
И оба они используются исключительно для внутренних нужд грейлога.
ES'же — это распределённое хранилище логов, которым может пользоваться не только сам graylog.
Я например графики строю при помощи Grafana напрямую по данным из ES, а грейлог использую для наполнения ES, анализа логов и алертов.
А ещё у меня ganglia для сбора реалтайм статистики, которая пишет в rrd, к которому имеет доступ graphite, через который Grafana может получать статистические данные и отображать их на одном графике с данными из ES :)
и как не странно — всё работает как часы.
И оба они используются исключительно для внутренних нужд грейлога.
ES'же — это распределённое хранилище логов, которым может пользоваться не только сам graylog.
Я например графики строю при помощи Grafana напрямую по данным из ES, а грейлог использую для наполнения ES, анализа логов и алертов.
А ещё у меня ganglia для сбора реалтайм статистики, которая пишет в rrd, к которому имеет доступ graphite, через который Grafana может получать статистические данные и отображать их на одном графике с данными из ES :)
и как не странно — всё работает как часы.
Так mongo стоит только рядом с грейлогом, так же как и его журнал.
И оба они используются исключительно для внутренних нужд грейлога.
Я еще раз повторюсь: не понимаю ЗАЧЕМ нужна еще одна точка отказа. ELK прекрасно все хранит в ES и проблем нет, от слова вообще.
У меня схема другая, у меня ELK + Influxdb + grafana. Logstas, еще до ES считает нужные метрики по логам, и кидает эти метрики в influx. RRD мне не удобен, так как бывают нужны детализированные данные. Частично kibana и grafana перекрывают друг друга по визуализации, но это скорее взаимодополнение.
Думаю на вопрос ЗАЧЕМ могут ответить только сами разработчики :)
С моей точки зрения mongo больше подходит для хранения небольшого количества часто меняющихся данных.
А ещё у них в доке написано, что планируется сделать возможность использовать любое хранилище вместо mongo.
С моей точки зрения mongo больше подходит для хранения небольшого количества часто меняющихся данных.
А ещё у них в доке написано, что планируется сделать возможность использовать любое хранилище вместо mongo.
Ну вот мы друг друга и поняли. :)
Для меня, если нет альтернатив, монго лучше вообще не использовать. Все же graylog догоняющий, от от ELK отстает сильно.
Для меня, если нет альтернатив, монго лучше вообще не использовать. Все же graylog догоняющий, от от ELK отстает сильно.
Кстати мы относительно недавно озадачились системой сбора логов (около полугода назад)
И при выборе пробовали в том числе Kibana.
Но graylog понравился больше, хоть он и догоняющий.
И при выборе пробовали в том числе Kibana.
Но graylog понравился больше, хоть он и догоняющий.
У kibana порог вхождения повыше, на сколько я понял по документации graylog. Но она гораздо гибче.
Во-первых ELK у нас исторически.
Во-вторых он используется для визуализации данных не только для саппорта, разрабов или девопсов, но и PM и прочих бизнес-аналитиков.
Во-первых ELK у нас исторически.
Во-вторых он используется для визуализации данных не только для саппорта, разрабов или девопсов, но и PM и прочих бизнес-аналитиков.
Graylog позволяет парсить и обогащать данные по условиям. Logstash тоже умеет и в последних версиях logstash в этом вопросе улучшили. Но в grayloge это удобней. Graylog прекрасно скейлится, ставите перед ним haproxy например и будет вам счастье. Самое не приятное в graylog — пишет ВСЕ сообщения только в «один» индекс, нельзя роутить собщения в разные индексы, надеюсь в следующих версиях поправят.
Основная причина — в ELK нет аунтификации без Shield. Поэтому и используется база с разграничением прав доступа.
Пол года назад ставил Graylog2. Необходимость была хранить логи с прод серверов глубиной до года, и иметь возможность посмотреть логи за определенный период. Но столкнулся с проблемой хранения. Логи сыпались 1.5к-2к/s, каждый индекс Elastic'a имел лимит 5гб. В неделю забивилось около 18 индексов по 5 гигов каждый итого ~90 гигов. В настройках ES можно настроить сколько индексов держать(старые закрываются и удаляются). Если увеличивать кол-во индексов, то поиск происходит дольше. Штатного инструмента по архивации старых индексов насколько я помню не было. Были некоторые самописные скрипты(http://tech.superhappykittymeow.com/?p=296), которые закрывали индексы и мувили их из ES допустим в /backup. В случае необходимости просмотра этих индексов, приходилось мувить их в хранилище ES и строить переиндексацию. Для долгосрочного хранения Graylog2 увы не подошел, из-за нехватки штатных инструментов. Возможно сейчас что изменилось?
Изменилось.
Теперь они используют elastic 2, в котором значительно улучшена работа doc_value индексов.
doc_value — это такой индекс, которым можно пользоваться не загружая его в память.
У меня на старом грейлоге хранилось порядка 1млрд сообщений в эластике (около 50 индексов) и любой запрос выполнялся десятки секунд минимум. Теперь же при наличии >2млрд сообщение и более 60 индексов графики строятся за секунды. При этом железо не менялось.
Ну и кроме того очень сильно улучшена вебка + теперь графики это тоже плагины + pipeline для обработки сообщений
Теперь они используют elastic 2, в котором значительно улучшена работа doc_value индексов.
doc_value — это такой индекс, которым можно пользоваться не загружая его в память.
У меня на старом грейлоге хранилось порядка 1млрд сообщений в эластике (около 50 индексов) и любой запрос выполнялся десятки секунд минимум. Теперь же при наличии >2млрд сообщение и более 60 индексов графики строятся за секунды. При этом железо не менялось.
Ну и кроме того очень сильно улучшена вебка + теперь графики это тоже плагины + pipeline для обработки сообщений
Надо добавить, что эти возможности появились в версии 2.0, которая зарелизилась в конце апреля. Архивация индексов появилась в ней, но как «коммерческая» функция.
Можете попробовать WinLogBeat + BeatsInput
Спасибо, ошибся с хранением, поправил. Про новую архитектуру читаю сейчас. Фишка нового graylog как раз в том, что он использует не collector, а sidecar для windows: https://www.graylog.org/blog/55-announcing-graylog-v2-0-ga и у меня все логи хорошо читаются
1. А оно может работать на паре серверов? Master/slave или master/master, например?
2. Наверняка же есть библиотеки для писания логов из java приложений сразу в greylog, без системного syslogd?
2. Наверняка же есть библиотеки для писания логов из java приложений сразу в greylog, без системного syslogd?
библиотеки для писания логов из java приложений
https://github.com/pukkaone/logback-gelf
https://github.com/Moocar/logback-gelf
Elasticsearch легко и непринужденно кластеризуется. Умеет сам находить ноды своего кластера.
www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html
www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html
Может, скейлится горизонтально. Перед нодами graylog нужно установить балансировщик, haproxy например.
Механизм healthcheck поддерживается в веб-интерфейсе graylog, можно прям из морды выводить из баланса.
Механизм healthcheck поддерживается в веб-интерфейсе graylog, можно прям из морды выводить из баланса.
Что в ELK что в GrayLog2 меня отталкивает необходимость использовать Java, может кто подскажет серверное решение не требующее особого напильника и умеющее:
1) Очень много логов в пиках до 10К/sec, не требующее сверхмощного железа.
2) Генерацию алярм по определенным шаблонам, например с одного узла сети за минуту пришло больше Х сообщений содержащих «Error»
3) Умеющее SNMP-trap или которое можно подружить с SNMP, а не только генерация mail, нужно для того чтоб подружить с общей системой мониторинга а не иметь 10 морд для разных аспектов.
4) Желательно cli для генерации выборок прямо в терминале или использования в скриптах, вебморда это конечно красиво, но на большом количестве событий медленно и неудобно.
Использоваться будет в сети ISP где более 10К управляемых железок шлют свои логи на сервер, сейчас используется syslog-ng с собственными фильтрами, плюс скриптовая обвязка, но ели ворочается и требует постоянного напильника, хочется более красивое и желательно готовое решение, но весь гугл забит ссылками на ELK и GrayLog, может я что-то упускаю.
1) Очень много логов в пиках до 10К/sec, не требующее сверхмощного железа.
2) Генерацию алярм по определенным шаблонам, например с одного узла сети за минуту пришло больше Х сообщений содержащих «Error»
3) Умеющее SNMP-trap или которое можно подружить с SNMP, а не только генерация mail, нужно для того чтоб подружить с общей системой мониторинга а не иметь 10 морд для разных аспектов.
4) Желательно cli для генерации выборок прямо в терминале или использования в скриптах, вебморда это конечно красиво, но на большом количестве событий медленно и неудобно.
Использоваться будет в сети ISP где более 10К управляемых железок шлют свои логи на сервер, сейчас используется syslog-ng с собственными фильтрами, плюс скриптовая обвязка, но ели ворочается и требует постоянного напильника, хочется более красивое и желательно готовое решение, но весь гугл забит ссылками на ELK и GrayLog, может я что-то упускаю.
имхо: если opensource — то ничего не упускаешь.
А так, я живу на ELK, у меня среднее 5-7k/sec (очень разных событий, от однострочников a la «mail sand to ...», до портянок килобайт на 300-500 с дампами ошибок), в пике 25-30k/sec, все адекватно крутится на 3 головах ES (виртуалки не на ssd, 8 ядер, 8 гигов оперативы, глубина хранения от недели до месяца, в зависимости от типа), logstash выделен на отдельную машину. И в этой конфигурации я еще не особо игрался с настройками индексов, а это влияет на производительность. Виртуалки загружены на ~60%.
А так, я живу на ELK, у меня среднее 5-7k/sec (очень разных событий, от однострочников a la «mail sand to ...», до портянок килобайт на 300-500 с дампами ошибок), в пике 25-30k/sec, все адекватно крутится на 3 головах ES (виртуалки не на ssd, 8 ядер, 8 гигов оперативы, глубина хранения от недели до месяца, в зависимости от типа), logstash выделен на отдельную машину. И в этой конфигурации я еще не особо игрался с настройками индексов, а это влияет на производительность. Виртуалки загружены на ~60%.
Похоже придется развернуть пару стендов и посмотреть в сторону elasticsearch и его api, он используется в обоих продуктах, а вебморда мне как таковая не нужна совсем. Нашел даже плагин для ES для своего syslog-ng, меньше всего переделывать придется — буду пробовать, раз альтернатив особо нет.
посмотри logstash заодно, возможно не надо будет городить огород с плагинами.
А так же глянь на beats (это проект ребят эластика), возможно еще меньше огорода будет.
А так же глянь на beats (это проект ребят эластика), возможно еще меньше огорода будет.
Если я правильно понял описание, то Beats заменяет logstash, то-есть занимается принятием логов и передачей их на ES, при этом для передачи используется что-то типа diff, а не логи целиком? Если я ничего не напутал из их описания проекта, то так должно быть еще быстрее и меньше нагрузка на систему принятия логов.
Можно и так. Я все гоню в logstash на мутаторы. Пока этот момент я не смотрел глубоко и не перенастраивал. beats использую как локальные агенты.
Спасибо за консультацию, буду пробовать в варианте когда логи принимает logstash и когда beats, сравню производительность, локальных агентов мне не нужно, т.к. почти все устройства — это коммутаторы и маршрутизаторы, на которые агента не поставить.
Обращайтесь.
Думаю тогда имеет смысл смотреть на logstash
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-snmptrap.html
Думаю тогда имеет смысл смотреть на logstash
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-snmptrap.html
Icinga2 https://habrahabr.ru/post/262115/
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Graylog2 стал удобнее и быстрее