Comments 29
А почему Watcher не установили раз меряете производительность железа?
Плагины я в данной статье не описывал, только установку основных приложений. А так да, стоит на логах.
Скажите, собирайть все в одно место это замечательно а как из этой информаци автоматически насторить некий мониторинг?
Ну например процессор уже 5 минут под 95% или там место на диске мало (скажем из логов видно), или ожидаемый лог перестал писаться или неожиданное в нем. и тд. и тп.
Как на такие events автоматически реагировать? Дополнительные утилиты?
Ну например процессор уже 5 минут под 95% или там место на диске мало (скажем из логов видно), или ожидаемый лог перестал писаться или неожиданное в нем. и тд. и тп.
Как на такие events автоматически реагировать? Дополнительные утилиты?
Ну вообще эластикс только предоставляет информацию, и уведомляет о необходимом уровне реакции (например, по шедулеру фильтровать журналы elasticsearch на ошибки, слать тикеты на почту [watcher]).
Если вы имеете ввиду автоматическое устранение проблемы на хосте, при её выявлении, то тут уже однозначно используется код понятный системе, и уровень создания такой автоматической реакции зависит от опыта написания такого кода. Для транспортировки кода можно использовать такие системы как puppet, chef. По мне я люблю salt, т.к. люблю питон.
Если вы имеете ввиду автоматическое устранение проблемы на хосте, при её выявлении, то тут уже однозначно используется код понятный системе, и уровень создания такой автоматической реакции зависит от опыта написания такого кода. Для транспортировки кода можно использовать такие системы как puppet, chef. По мне я люблю salt, т.к. люблю питон.
плагины elasticsearch, имею ввиду
Спасибо за статью, интересно. Года полтора назад я собирал сервер логирования logstash+elasticsearch данные отправлял из rsyslog-а на прямую, а так же из apach-а перенаправлением вывода в nc. Logstash+elasticsearch работали не очень стабильно с течением времени и объёма логов. Так же строил различные счётчики и визуализировал с помощью graphite. Теперь судя по всему, проект сильно развился с тех пор, нужно будет взглянуть ещё раз. А теперь вопросы :)
Почему не собираете данные напрямую из систем логирования *syslog или journald? Чтение уже записанных файлов не оптимально, да и теряется часть информации.
Строите ли какие-нибудь сводные графики и чем?
Есть ли какая нибудь обратная связь и по каким критериям? Я использовал поиск ключевых слов в логах, но это было не удобно, конфигурация получалась громоздкая и запутанная (если нужно настраивать связи событий). И по событиям отправлял сообщения в nagios.
Почему не собираете данные напрямую из систем логирования *syslog или journald? Чтение уже записанных файлов не оптимально, да и теряется часть информации.
Строите ли какие-нибудь сводные графики и чем?
Есть ли какая нибудь обратная связь и по каким критериям? Я использовал поиск ключевых слов в логах, но это было не удобно, конфигурация получалась громоздкая и запутанная (если нужно настраивать связи событий). И по событиям отправлял сообщения в nagios.
Почему не собираете данные напрямую из систем логирования *syslog или journald? Чтение уже записанных файлов не оптимально, да и теряется часть информации.
Именно filebeats этим и занимается. Обновлённая в файле информация моментально поступает на сервер, и только обновлённая (не весь файл целиком). Это могут быть не только динамические файлы, но и, например, конфиги, маунты. А далее плагин watcher ищет в логах то, о чём нам срочно нужно знать (что искать определяется собственными индексами конечно).
Строите ли какие-нибудь сводные графики и чем?
Графики можно строить в визуалайзере Kibana4. В наборе beats-dashboards, который я описывал, есть уже много готовых.
> Именно filebeats этим и занимается.
Нет, он делает это «со вторых рук» и к тому же, в файл логов попадает не вся информация (severity, например) и не сразу. А в случае проблем с файлами (место кончилось, файл ротейтнулся) — данные пропадут. Да и к чему лишние операции чтения?.. А в случае больших объёмов, данные локально лучше вообще не писать.
> Графики можно строить в визуалайзере Kibana4.
Когда я смотрел, там можно было только отображать статистику по данным, без какого-либо расширенного анализа содержимого.
Например, можно ли построить сводный график статистики по кодам ответа http (4хх, 5хх) в секунду в зависимости от вирутального хоста с возможностью группировки по физическому серверу? Или банальный объём трафика отданного веб-сервером?
Нет, он делает это «со вторых рук» и к тому же, в файл логов попадает не вся информация (severity, например) и не сразу. А в случае проблем с файлами (место кончилось, файл ротейтнулся) — данные пропадут. Да и к чему лишние операции чтения?.. А в случае больших объёмов, данные локально лучше вообще не писать.
> Графики можно строить в визуалайзере Kibana4.
Когда я смотрел, там можно было только отображать статистику по данным, без какого-либо расширенного анализа содержимого.
Например, можно ли построить сводный график статистики по кодам ответа http (4хх, 5хх) в секунду в зависимости от вирутального хоста с возможностью группировки по физическому серверу? Или банальный объём трафика отданного веб-сервером?
По первому ответу не много не понял. Плагины же по факту индексируют нацеленные файлы на основе своего кода, которые анализирует файлы на клиенте и предоставляет их уже elasticsearch, а собственно на сервер идёт обработка их в logstash по загруженным индексам от плагина. В чём негатив чтения в данном случае? Не скажу что у меня много глубокого опыта в этом продукте, поэтому хотелось бы подробней уточнить этот момент.
По поводу графиков, то есть возможность любое событие фильтровать. Соответственно анализируя плагинами логи виртуального хоста, можно сознать планировщики сигналок по нужным индексам (например 404, 423 и т.д.) и у казать их в редакторе визуалайзера Kibana4. в графе фильтр
{
«filter»: []
}
Опять же, глубоко я это не разгребал, не смогу пока что сходу описать код под конкретную задачу. Поэтому буду рад указаниям на мои ошибки, и их разъяснениям =)
По поводу графиков, то есть возможность любое событие фильтровать. Соответственно анализируя плагинами логи виртуального хоста, можно сознать планировщики сигналок по нужным индексам (например 404, 423 и т.д.) и у казать их в редакторе визуалайзера Kibana4. в графе фильтр
{
«filter»: []
}
Опять же, глубоко я это не разгребал, не смогу пока что сходу описать код под конкретную задачу. Поэтому буду рад указаниям на мои ошибки, и их разъяснениям =)
1. Само наличие промежуточный файлов — уже не хороший вариант, особенно если есть возможность собирать на прямую из источника событий. И файлы не редко пишутся с опозданием от самого события.
Для этих целей у logstash-а есть приёмник типа syslog, или вообще любой tcp/udp поток на входе слушать, а там разбирать.
Как метод собрать данные из всего универсально файлы не плохи, но если есть другие варианты, то лучше их, но тут нужно настраивать каждый источник.
2. По графикам в кибане конкретнее сказать не смогу, давно смотрел. Но сейчас опять развернул тестовую связку logstash-а, буду разбираться, проверять.
Для этих целей у logstash-а есть приёмник типа syslog, или вообще любой tcp/udp поток на входе слушать, а там разбирать.
Как метод собрать данные из всего универсально файлы не плохи, но если есть другие варианты, то лучше их, но тут нужно настраивать каждый источник.
2. По графикам в кибане конкретнее сказать не смогу, давно смотрел. Но сейчас опять развернул тестовую связку logstash-а, буду разбираться, проверять.
> Logstash+elasticsearch работали не очень стабильно с течением времени и объёма логов. Теперь судя по всему, проект сильно развился с тех пор, нужно будет взглянуть ещё раз.
Та в общем ничего особо и не поменялось по стабильности. Оно все красиво смотриться, но под нагрузками предсказуемо работает только Elasticsearch, как основной продукт компании. Все остальное отпадает, крашится или работает непредсказуемо. Чем дальше от стандартных плагинов в настройке — тем еще больше проблем.
Но это такое, может быть, субъективное. Но вот то, что они строго привязывают версии всех продуктов для работы друг з дружкой — это вообще ужас. Примером захотели обновить logstash из-за того что он у вас падает — а нельзя, нужно обновлять ввесь ELK-стэк. Что в случае использования больших инфраструктур и систем конфигурации очень даже трудозатратно.
Та в общем ничего особо и не поменялось по стабильности. Оно все красиво смотриться, но под нагрузками предсказуемо работает только Elasticsearch, как основной продукт компании. Все остальное отпадает, крашится или работает непредсказуемо. Чем дальше от стандартных плагинов в настройке — тем еще больше проблем.
Но это такое, может быть, субъективное. Но вот то, что они строго привязывают версии всех продуктов для работы друг з дружкой — это вообще ужас. Примером захотели обновить logstash из-за того что он у вас падает — а нельзя, нужно обновлять ввесь ELK-стэк. Что в случае использования больших инфраструктур и систем конфигурации очень даже трудозатратно.
У Вас опечатка в названии статьи,.Logstash а не Logtash.
Большинство прочитанных статей на тему установки приложений Elastic показались мне достаточно расплывчатыми и неполными.
Основной и единственный источник информации, который я использовал: www.elastic.co/guide/index.html.
Так официальный сайт лучше всегда использовать для руководства по установке и настройке, там информация самая полная и актуальная. У вас же получилась еще одна неполная и расплывчатая статья статья по мотивам официальной документации, согласитесь :) Информация их которой понятна только тем людям, кто уже работает с ELK стеком, но они, сюрприз, уже его установили ))
Поделитесь лучше, на каком железе это работает, сколько логов в секунду обрабатывает ваша инсталляция, какое потребление ресурсов, то чего как раз нет в оф манах.
Шел 2016-й, а люди по-прежнему настраивали сервера-снежинки вручную.
А зачем нужен logstash в вашем случае? Beats ведь умеет напрямую в Elasticsearch отправлять?
Я сейчас тоже настраиваю сервер логов, и в раздумьях — нужен ли мне logstash как промежуточное звено.
Я сейчас тоже настраиваю сервер логов, и в раздумьях — нужен ли мне logstash как промежуточное звено.
Logstash определяет по каким каналам принимать данные с beats, как отфильтровать эту информацию, и как это вывести (в зависимости от условий). Без logstash, в elasticsearch нужно будет самому сортировать инфу по индексам вручную, через kibana или с помощью http запросов.
В вашем примере logstash просто форвардит данные в Elasticsearch, без сортировки или фильтрации:
Это же можно сделать и без logstash.
Или я что-то не так понимаю?
input {
beats {
port => 5044
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
sniffing => true
manage_template => false
index => "%{[@metadata][beat]}-%{+YYYY.MM.dd}"
document_type => "%{[@metadata][type]}"
}
}Это же можно сделать и без logstash.
Или я что-то не так понимаю?
В моём примере logstash настроен принимать данные на порт 5044, и выводить данные в elasticsearch по индексу | месяц число год, время | лога. На скринах это первый столбец.
filebeats по-умолчанию настроен писать в индекс filebeat-YYYY.MM.DD
То есть то же самое.
То есть то же самое.
Да можете и не использоваеть logstash. По сути он как клиентская нода, в примере, собирает с удалённых серверов данные и выводит всё в elasticsearch с указанием на индекс по tcp, а последний уже представляет её. Если не в elasticsearch, то можно вывести всё в файл, далее в фильтре указать шаблоны которые разбивают содержимое лога по принципу key=value, использовать регулярные выражение и т.д., чтобы сделать его читабельным и порезать ненужное.
remove => [ "blablabla" ] — удалит содержимое с заголовками blablabla.
gsub => [ "ROBOT", "0", "1" ] — в поле ROBOT все нули станут единицами.
pattern => "%{IP:client} " — выведет "client: 10.0.10.123"
Есть дефолтные ориентированные шаблоны. Примеры тут.
remove => [ "blablabla" ] — удалит содержимое с заголовками blablabla.
gsub => [ "ROBOT", "0", "1" ] — в поле ROBOT все нули станут единицами.
pattern => "%{IP:client} " — выведет "client: 10.0.10.123"
Есть дефолтные ориентированные шаблоны. Примеры тут.
Если интересно поиграться с простой конфигурацией ELK стэка, можно за пару минут запустить все это в контейнерах.
Друже, спасибо за статью. Она хоть морально немного устарела, зато направила меня в нужное русло + хорошо всё равно расписаны моменты конфигурирования.
Почитайте ещё про машинное обучение в Elasticsearch — тоже полезная штука.
Sign up to leave a comment.
Сервер логов Elasticsearch + Logstash + Kibana4 + Beats(windows/linux). Установка и настройка