Home » ELK Stack » Централизованный сбор логов Mikrotik в ELK Stack

Централизованный сбор логов Mikrotik в ELK Stack

Очередной материал на тему централизованной системы сбора логов. Сегодня расскажу, как настроить сбор логов с устройств компании Mikrotik в ELK Stack. Статья ничем не примечательна, так как делается все стандартно и просто. Никакого парсинга и разбора логов я делать не буду. То есть будем просто хранить логи микротиков в одном месте с удобным поиском.

Введение

Ранее я рассказал, как установить и настроить elk stack, потом как загружать и анализировать логи nginx и samba. Теперь пришел черед логов Mikrotik. Я уже рассказывал, как отправлять логи микротика на удаленный syslog сервер, в качестве которого может выступать в том числе syslog-ng. В данном случае на самом микротике ничего особенного делать не надо. Будем точно так же отправлять данные на удаленный syslog сервер, в качестве которого будет трудиться logstash.

Я некоторое время рассуждал на тему парсинга и разбора логов. Но посмотрев на типичную картину стандартных логов mikrotik, понял, что ничего не выйдет. События очень разные и разобрать их одним правилом grok не получится. Если нужен парсинг и добавление метаданных к событиям, необходимо определенные события выделять и направлять отдельным потоком в logstash, где уже обрабатывать своим фильтром. Например, отдельный фильтр можно настроить на парсинг подключений к vpn или подключение по winbox с анализом имен пользователей.

Я же буду просто собирать все логи скопом и складывать в единый индекс. У записей не будет метаданных, по которым можно строить дашборды и анализировать данные. Но тем не менее, это все равно удобно, так как все логи в одном месте с удобным и быстрым поиском.

Настройка logstash на прием логов микротик

В конфиге /etc/logstash/conf.d/input.conf добавляем секцию для приема syslog логов. Вместе с логами от beats конфиг будет выглядеть вот так:

input {
    beats {
	port => 5044
    }
    syslog {
	port => 5045
	type => syslog
    }
}

В конфиге с фильтрами filter.conf я разделил с помощью тэгов логи обычных роутеров, свитчей и wifi точек доступа по ip адресам. Получилось примерно так:

    else if [host] == "10.1.4.19" or [host] == "10.1.5.1" {
        mutate {
            add_tag => [ "mikrotik", "gateway" ]
        }
    }
    else if [host] == "10.1.4.66" or [host] == "10.1.3.110" or [host] == "10.1.3.111" {
        mutate {
            add_tag => [ "mikrotik", "wifi" ]
        }
    }
    else if [host] == "10.1.4.14" or [host] == "10.1.5.33" {
        mutate {
            add_tag => [ "mikrotik", "switch" ]
	}
    }

Это простой случай, когда устройств мало. Если у вас много устройств, то лучше наверно придумать что-то другое, чтобы не нагружать logstash лишними правилами. Да и в ручную править конфиг неудобно. Как лучше поступать в таком случае — не знаю, не продумывал тему. Наверно имеет смысл разделить потоки по разным портам и на этом основании принимать решение о дальнейшей обработке.

Отправляем полученные логи в elasticsearch, настроив конфиг output.conf:

    else if "mikrotik" in [tags] {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "mikrotik-%{+YYYY.MM}"
        }
    }

Я просто складываю все логи с тэгом mikrotik в один индекс с разбивкой по месяцам. На типы gateway, switch и wifi не разделяю, хотя можно это сделать. Тэги я добавил просто для удобства просмотра логов. С помощью тэгов можно будет быстро группировать логи по типу устройств.

Перезапускаем logstash и идем настраивать микротики на отправку логов на удаленный сервер.

Отправка логов mikrotik на удаленный сервер

Подключаемся к Mikrotik по winbox и идем в раздел System -> Logging. Изначально там вот так, если вы ничего не меняли.

Настройки логирования в Микротике

Идем на вкладку Actions, выбираем remote и указываем параметры:

Отправка логов Mikrotik на удаленный сервер

В данном случае:

  • 10.1.4.114 — сервер elk, точнее с logstash;
  • 5045 — порт, по которому logstash принимает syslog подключения.

После этого идем на вкладку Rules и дублируем стандартные правила, указывая action remote или добавляем новые правила для отправки логов. Должно получиться примерно вот так:

Централизованный сбор логов Mikrotik

Все, микротик настроен на отправку логов на удаленный сервер. Больше на нем ничего делать не надо. Идем в web интерфейс Kibana.

Добавление индекса mikrotik в kibana

Если в предыдущих разделах вы все сделали правильно, в elasticsearch должны начать поступать данные от микротиков в индекс mikrotik-*. Идем в Kibana в раздел Management -> Index Patterns и добавляем новый индекс.

Индекс в elasticsearch для логов микротика

После этого можно в разделе Discover просматривать логи. При этом работает группировка по тэгам, которые характеризуют тип устройства.

Хранение логов mikrotik в elk stack

На этом по настройке хранения логов mikrotik в elk stack все. Надеюсь, было полезно.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Получилась простая статья по сбору логов. Для тех, кто уже работал с ELK Stack тут ничего нового нет. По сути, никакого анализа и графиков нет, а именно это чаще всего интересует при использовании elk. Я просто не придумал, что может быть полезного в логах микротика, что требует какого-то детального разбора и построения дашбордов. Если у кого-то есть идеи или примеры grok фильтров, прошу поделиться.

Помогла статья? Есть возможность отблагодарить автора

25 комментариев

  1. Дмитрий

    Давно хотел почитать эти статьи про ELK, наконец, добрался.
    А можно настроить какие-то уведомления на критические события? Допустим, тот же логин пользователя или, к примеру, падение интерфейса.
    Полезное в логах микротика? Нагрузка на dhcp, wifi, данные PoE out. Или, например, если каждый час измеряется скорость, то можно рисовать эту скорость на графиках, но это, мне кажется, очень узкоприменимый кейс.

    • Zerox

      Мне кажется под все описанное больше zabbix подходит.

      • Дмитрий

        Да, zabbix сейчас и используется. Просто интересен функционал ELK с точки зрения хранения всех логов. Кстати, вопрос по уведомлениям актуален) Или, наверно, логичнее уже мониторить эти логи в zabbix?

        • Zerox

          Нужно разделять функционал. То, что вы описали вначале, не только про логи. Например, падение интерфейса. Логичнее это мониторить по snmp в zabbix и слать уведомления. Логин пользователя, тут уже надо думать, где лучше реализовывать. Можно и в заббиксе и в elk. Но мне кажется, elk все же больше про большие логи и визуализацию, поиск в них. Мониторинг не его задача. Уведомления в нем есть, но я не разбирался и не настраивал.

  2. Что по вашему все таки удобнее/оптимальнее для сбора логов с mikrotik, syslog-ng или ELK?

    • Прошу прощения, имел ввиду rsyslog. У вас статья была по этому поводу.

    • Zerox

      Так это совсем разные вещи, решающие разные задачи. rsyslog просто хранит логи в текстовом виде и все. А elk это целый многофункциональный комплекс с web доступом. Только для микротиков я бы не стал поднимать elk. Я бы настроил rsyslog и webmin, если хочется через браузер смотреть логи и выполнять поиск по ним.

  3. Валерий

    И все таки как прикрутить грамотно dashboard сюда пока не разобрался никто

  4. Константин

    Спасибо за статью.
    нет ли ошибки в logstash input? ведь там не указан протокол (tcp, udp)
    И должен ли быть порт 5044 в состоянии LISTEN в системе?

    • Zerox

      Ошибки нет. Порт должен быть открыт и принимать соединения.

      • Валерий

        Мне удалось запустить на данной системе модуль netflow в настройках файла logstash.yml «Module Settings» раскомментируем строку modules (второй) и добавляем

        modules:
        -name:netflow
        var.input.udp.port: 9300

        Сохраняем, перезапускаем
        # systemctl restart logstash.service
        Идем смотреть лог
        # tail -f /var/log/logstash/logstash-plain.log

        После этого он будет игнорировать некоторые версии пакетов, но в индексах появиться «netflow-2018.11.30»
        Гораздо более расширенные данные о трафике, и не забудьте на микроте настроить TraffikFlow с портом и таргетом на logstash

        • Валерий

          Один существенный минус, я так и не разобрался как выставить сопоставление IP адресов и DNS имен

          • Валерий

            https://github.com/robcowart/elastiflow/blob/master/INSTALL.md Вот еще лучше версия и кстати 300 готовых визуализаций

            • Валерий

              Установка и настройка прошла успешно, 7 день полет нормальный принимаю полностью статистику от микротика с выводом данных и визуализацией и движениям по сети как локальной так и внешней

              • Zerox

                Можно скриншот этой красоты увидеть? Визуализацию или дашборд готовый, если есть.

                • Валерий

                  Вот скрины https://yadi.sk/d/eX5VFNDYjKzckw

                  Если есть вопросы могу помочь почта для вопросов valerondestoer@gmail.com

                  • Zerox

                    Красиво получилось, информативно. Мне кажется, эти логи будут очень много места занимать. Если нет большой нужды в таком подробном анализе логов, то весьма накладно все это хранить и обрабатывать. Хотя для расследования инцидентов, можно хранить за последние 2-3 дня и дальше чистить.

                    • Валерий

                      Выделил под виртуалку 600гб лог за день весит от 1.5-до 2гб на месяц должно хранить, и главное для jvm выделить не 4 а 8

        • Константин

          А input.conf надо настраивать для netflow?

          • Валерий

            для netflow лучше использовать кодеки, и там настраивается целый стек параметров

  5. Доброго.

    В догонку habr.com/post/431600/

Добавить комментарий

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.