Comments 18
Выбор сразу пал на ELK или еще что-то рассматривали?
cooper051, да, конечно, мы рассматривали и сравнивали разные системы — и IBM QRadar, и Solarwinds, Splunk, HP ArcSight. В нашем случае (для наших задач) ELK оказался максимально функциональным и соответствующим требованиям к стоимости. При этом мы не рассматриваем ELK как полноценную замену SIEM и сами в перспективе планируем запускать SOС. В данном примере ELK это именно система управления логами.
Облачное хранилище в заголовке упомянуто для чего? Непонятно какие преимущества для хранения и обработки его логов дал ELK…
Hardened, ELK – это инструмент для сбора, хранения и просмотра логов платформы Техносерв Cloud, а значит, и нашего облачного хранилища. Внедрение централизованной системы хранения логов позволило сократить время на диагностику проблем в случае их возникновения.
Может у вас реализована какая-нибудь нотификация в случае возникнования записей с различными level? Например лог запись с level: ERROR/WARNING с уведомлением на email или например slack.
А почему вы выбрали связку ELK, а не Graylog например? И как вы делаете бекапирование вашей системы?
Спасибо за ответы.
P.S Не ради троллинга.
Спасибо за ответы.
P.S Не ради троллинга.
kataklysm, не страшно, даже если ради него)). Резервное копирование мы делаем с помощью elasticdump. Данные планируем хранить глубиной на полгода, потом будем удалять раз в неделю на полгода + неделю, и хранить в архиве. Архивы – раз в неделю глубиной в неделю. (Храним данные в объектном хранилище, о котором писали в предыдущих постах).
Я терпеть не могу кибану, но из доступных решений, это единственное, достаточно универсальное. К EL части нареканий меньше, а вот адекватизация кибаны — это острейшая задача. В ней можно сделать всё, но всё, что в ней можно сделать, делается неудобно.
amarao, спасибо за понимание)
Можете немного расписать, что именно вам не нравится в кибане? Использую её ежедневно, вроде все мои запросы удовлетворяются.
Отсутствие параметризации/шаблонов как в grafana. Например, три типовых поля, по которым мы фильтруем: syslog_hostname, syslog_program и syslog_severity. Я бы хотел их прибить drop box'ами или другими тривиальными элементами управления. Как такое сделать я не нашёл. На выходе — несколько мучительных кликов с раздумием и чтением кучи надписей чтобы сделать очевидное и частое действие.
А почему у вас входными нодами для запросов являются master-ноды, а не coordinating-ноды?
LighteR, любая нода ES является координирущей. С текущей нагрузкой на мастер-ноды использовать выделенные координирующие ноды, на наш взгляд, нет необходимости.
спланк не рассматривали или объем больше 500мб?
box4, Спланк рассматривали как возможный вариант, но ELK в нашем случае оказался наиболее подходящим продуктом с точки зрения предоставляемых возможностей и стоимости внедрения. Отвечая на второй вопрос, на данный момент ежедневно мы получаем 1-2 ГБ новых логов.
еще вопрос, каким образом передаете логи с виндовс? у меня сейчас для таких целей используется заббикс(как лог коллектор), в день падает около 17гб логов, через питон парсер выгружаю нужные логи по id(субд постгре, время на обработку запроса уходит около 3мин), и спланк подгружает автоматом из каталога лог в формате csv размер около 100мб в день. но хотелось бы избавиться от костылей и перейти на ELK.
box4, с серверов windows мы собираем только события системных журналов, используем winlogbeat.
Если у вас задача собирать логи с файловой системы или напрямую из базы данных, смотрите в сторону filebeat и jdbc-input плагина для Logstash.
Если у вас задача собирать логи с файловой системы или напрямую из базы данных, смотрите в сторону filebeat и jdbc-input плагина для Logstash.
Sign up to leave a comment.
Хранилище логов для облачной платформы. Опыт внедрения ELK