Logstash: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) (→grok) |
||
(не показано 49 промежуточных версий этого же участника) | |||
Строка 3: | Строка 3: | ||
[[Категория:Logstash]] |
[[Категория:Logstash]] |
||
[[Категория:Grok]] |
[[Категория:Grok]] |
||
+ | [[Категория:Elasticsearch]] |
||
+ | [[Категория:Kibana]] |
||
+ | [[Категория:Filebeat]] |
||
=Logstash= |
=Logstash= |
||
Заметки по Logstash с примерами конфигов |
Заметки по Logstash с примерами конфигов |
||
+ | |||
+ | <B>Заметка возникла по-тому что каждый раз когда надо настроить Logstash я обнаруживал что забыл почти все - и решил записать что б в следующий раз зачитать по бумажке</B> |
||
+ | ==Установка== |
||
+ | * https://www.elastic.co/guide/en/logstash/current/index.html |
||
+ | <PRE> |
||
+ | wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - |
||
+ | sudo apt-get install apt-transport-https |
||
+ | echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list |
||
+ | sudo apt-get update |
||
+ | sudo apt-get install elasticsearch |
||
+ | </PRE> |
||
+ | |||
+ | Порядок работы - input --> filter (в том числе изменение) -->output |
||
+ | <BR> |
||
+ | Для каждой фазы есть множество плагинов |
||
+ | <PRE> |
||
+ | input { |
||
+ | ... |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | filter { |
||
+ | ... |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | output { |
||
+ | ... |
||
+ | } |
||
+ | </PRE> |
||
+ | |||
+ | ==INPUT== |
||
+ | Данный метод является входной точкой для логов |
||
+ | |||
+ | Тыщи их если что |
||
+ | * https://www.elastic.co/guide/en/logstash/current/input-plugins.html |
||
+ | |||
+ | В описании только самые простые/ходовые |
||
+ | |||
+ | ==Beats== |
||
+ | Точка для получения логов от Filebeat |
||
+ | * https://www.elastic.co/guide/en/beats/filebeat/current/configuring-howto-filebeat.html |
||
+ | * https://www.elastic.co/guide/en/logstash/current/plugins-inputs-beats.html#plugins-inputs-beats |
||
+ | <PRE> |
||
+ | beats { |
||
+ | port => 5400 |
||
+ | ssl => true |
||
+ | ssl_certificate_authorities => ["/etc/elk-certs/elk-ssl.crt"] |
||
+ | ssl_certificate => "/etc/elk-certs/elk-ssl.crt" |
||
+ | ssl_key => "/etc/elk-certs/elk-ssl.key" |
||
+ | ssl_verify_mode => "force_peer" |
||
+ | } |
||
+ | </PRE> |
||
+ | Сертефикаты должны быть подписаны одним CA - по сути тут требуется авторизация с помошью сертефикатов (как например OpenVPN или такое можно делать с nginx) |
||
+ | <BR> |
||
+ | Важнейшая настройка Ж |
||
+ | <PRE> |
||
+ | ssl_verify_modeedit |
||
+ | </PRE> |
||
+ | Value can be any of: none, peer, force_peer Default value is "none" By default the server doesn’t do any client verification. <BR> |
||
+ | peer will make the server ask the client to provide a certificate. If the client provides a certificate, it will be validated. <BR> |
||
+ | force_peer will make the server ask the client to provide a certificate. If the client doesn’t provide a certificate, the connection will be closed. <BR> |
||
+ | <BR> |
||
+ | This option needs to be used with ssl_certificate_authorities and a defined list of CAs. |
||
+ | <BR> |
||
+ | |||
+ | ===Генерация серетфикатов=== |
||
+ | Простой скрипт для самоподписанных сертефикатов (хотя конечно лучше организовать свой PKI) |
||
+ | <PRE> |
||
+ | #!/bin/bash |
||
+ | |||
+ | CN="logstash.tld" |
||
+ | sudo openssl req -subj "/CN=${CN}/" -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout elk-ssl.key -out elk-ssl.crt |
||
+ | |||
+ | chown logstash elk-ssl.crt |
||
+ | chown logstash elk-ssl.key |
||
+ | </PRE> |
||
+ | <B>Важно:</B> В конфигурации Filbeat нужно указат CN из серетфиката или будет ошибка SSL (что логично когда знаешь но не очевидно сразу) |
||
+ | |||
+ | ==File== |
||
+ | </PRE> |
||
+ | input { |
||
+ | file { |
||
+ | path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ] |
||
+ | exclude => [ "*.gz", "*.zip", "*.rar" ] |
||
+ | start_position => "end" |
||
+ | stat_interval => 1 |
||
+ | discover_interval => 30 |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ] |
||
+ | </PRE> |
||
+ | указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (?) |
||
+ | <PRE> |
||
+ | exclude => [ "*.gz", "*.zip", "*.rar" ] |
||
+ | исключает из обработки файлы с соответствующими расширениями. |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | start_position => "end" |
||
+ | ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов. |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | stat_interval => 1 |
||
+ | как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк. |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | discover_interval => 30 |
||
+ | время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path. |
||
+ | </PRE> |
||
+ | |||
+ | ==tcp== |
||
+ | Пример конфигурации, для работы с логами удалённых сервисов: |
||
+ | <PRE> |
||
+ | input { |
||
+ | tcp { |
||
+ | data_timeout => 10 |
||
+ | mode => "server" |
||
+ | host => "192.168.3.12" |
||
+ | port => 3337 |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | |||
+ | Построчное описание настроек: |
||
+ | <PRE> |
||
+ | data_timeout => 10 |
||
+ | </PRE> |
||
+ | время (в секундах), по истечении которого не активное tcp соединение будет закрыто. Значение -1 — соединение всегда будет открыто. |
||
+ | <PRE> |
||
+ | mode => "server" |
||
+ | host => "192.168.3.12" |
||
+ | port => 3337 |
||
+ | </PRE> |
||
+ | в этом случае Logstash становится сервером, и начинает слушать на 192.168.3.12:3337. При установке mode => «client» Logstash будет присоединятся к удалённому ip:port для забора логов. |
||
+ | |||
+ | ==udp== |
||
+ | <PRE> |
||
+ | Для udp настройки аналогичные tcp: |
||
+ | input { |
||
+ | udp { |
||
+ | buffer_size => 4096 |
||
+ | host => "192.168.3.12" |
||
+ | port => 3337 |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | |||
+ | ==FILTER== |
||
+ | Все плагины - https://www.elastic.co/guide/en/logstash/current/filter-plugins.html |
||
+ | <BR> |
||
+ | В данном блоке настраиваются основные манипуляции с логами. <BR> |
||
+ | Это может быть например |
||
+ | * разбивка по key=value |
||
+ | * удаление ненужных параметров |
||
+ | * замена имеющихся значений |
||
+ | * использование geoip или DNS запросов для ип-адресов или названий хостов. |
||
+ | |||
+ | |||
+ | ===grok=== |
||
+ | GROK - разбивает строку с помошью регулярных выражений. |
||
+ | <BR> |
||
+ | Пример конфигурационного файла для основной нормализации логов: |
||
+ | <PRE> |
||
+ | filter { |
||
+ | grok { |
||
+ | patterns_dir => "/path/to/patterns/" |
||
+ | pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | |||
+ | Описание настроек: |
||
+ | <PRE> |
||
+ | patterns_dir => "/path/to/patterns/" |
||
+ | </PRE> |
||
+ | путь к каталогу, содержащим шаблоны обработки логов.<BR> |
||
+ | Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны. |
||
+ | <BR> |
||
+ | <PRE> |
||
+ | pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" |
||
+ | </PRE> |
||
+ | указывается шаблон разборки логов. |
||
+ | <BR> |
||
+ | Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов. |
||
+ | <BR> |
||
+ | Создавать свои шаблоны необязательно - достаточно встроенных |
||
+ | * https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/ecs-v1/grok-patterns |
||
+ | |||
+ | ===Подробнее про шаблоны=== |
||
+ | С помощью grok фильтра можно структурировать большую часть логов — syslog, apache, nginx, mysql итд, записанных в определённом формате. |
||
+ | Logstash имеет более 120 шаблонов готовых регулярных выражений (regex). Так что написание фильтров для обработки большинства логов не должно вызвать особого страха или недопонимания. |
||
+ | |||
+ | Формат шаблонов относительно простой — NAME PATTERN, то есть построчно указывается имя шаблона и ему соответствующее регулярное выражение. Пример: |
||
+ | <PRE> |
||
+ | NUMBER \d+ |
||
+ | WORD \b\w+\b |
||
+ | USERID [a-zA-Z0-9_-]+ |
||
+ | </PRE> |
||
+ | |||
+ | Можно использовать любой ранее созданный шаблон: |
||
+ | <PRE> |
||
+ | USER %{USERID} |
||
+ | </PRE> |
||
+ | Шаблоны можно так же и комбинировать: |
||
+ | <PRE> |
||
+ | CISCOMAC (?:(?:[A-Fa-f0-9]{4}\.){2}[A-Fa-f0-9]{4}) |
||
+ | WINDOWSMAC (?:(?:[A-Fa-f0-9]{2}-){5}[A-Fa-f0-9]{2}) |
||
+ | MAC (?:%{CISCOMAC}|%{WINDOWSMAC}) |
||
+ | </PRE> |
||
+ | |||
+ | Допустим формат логов у нас следующий (пример шаблона выше): |
||
+ | <PRE> |
||
+ | 55.3.244.1 GET /index.html 15824 0.043 |
||
+ | </PRE> |
||
+ | |||
+ | |||
+ | С данным примером лога достаточно pattern записать в виде |
||
+ | <PRE> |
||
+ | "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" |
||
+ | </PRE> |
||
+ | После обработки наша строка будет выглядеть следующим образом: |
||
+ | <PRE> |
||
+ | client: 55.3.244.1 |
||
+ | method: GET |
||
+ | request: /index.html |
||
+ | bytes: 15824 |
||
+ | duration: 0.043 |
||
+ | </PRE> |
||
+ | |||
+ | ===mutate=== |
||
+ | Пример конфигурационного файла для изменения/удаления записей из логов: |
||
+ | * https://www.elastic.co/guide/en/logstash/current/plugins-filters-mutate.html |
||
+ | filter { |
||
+ | mutate { |
||
+ | remove_field => [ "client" ] |
||
+ | replace => { "message" => "%{source_host}: My new message" } |
||
+ | |||
+ | rename => [ "HOSTORIP", "client_ip" ] |
||
+ | gsub => [ "message", "\\/", "_" ] |
||
+ | add_field => [ "sample1", "from %{clientip}" ] |
||
+ | } |
||
+ | } |
||
+ | <PRE> |
||
+ | remove => [ "client" ] |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | rename => [ "HOSTORIP", "client_ip" ] |
||
+ | </PRE> |
||
+ | переименование название поля HOSTORIP в client_ip. |
||
+ | |||
+ | <PRE> |
||
+ | add_field => [ "sample1", "from %{clientip}" ] |
||
+ | добавление нового поля «sample1» со значением «from %{clientip}». |
||
+ | Допускается использование названий переменных или статических значений. |
||
+ | </PRE> |
||
+ | ===date=== |
||
+ | Пример конфигурационого файла: |
||
+ | </PRE> |
||
+ | filter { |
||
+ | date { |
||
+ | match => [ "timestamp", "MMM dd HH:mm:ss" ] |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | match => [ "timestamp", "MMM dd HH:mm:ss" ] |
||
+ | </PRE> |
||
+ | временная метка события. |
||
+ | <BR> |
||
+ | Если в логах время указано в unix timestamp, то следует использовать match => [ «timestamp», «UNIX» ] |
||
+ | |||
+ | ===kv=== |
||
+ | Пример конфигурационного файла для обработки логов в формате key=value: |
||
+ | <PRE> |
||
+ | filter { |
||
+ | kv { |
||
+ | value_split => "=:" |
||
+ | fields => ["reminder"] |
||
+ | field_split => "\t?&" |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | value_split => "=:" |
||
+ | </PRE> |
||
+ | использовать символы "=" и ":" для разделения ключа-значения. |
||
+ | <PRE> |
||
+ | fields => ["reminder"] |
||
+ | </PRE> |
||
+ | название поля в котором искать 'ключ=значение'. По умолчанию разбивка будет происходить для всей строки лога. |
||
+ | <PRE> |
||
+ | field_split => "\t?&" |
||
+ | </PRE> |
||
+ | использовать символы "\t?&" для разделения ключей. \t — знак табулятора |
||
+ | |||
+ | ==OUTPUT== |
||
+ | * https://www.elastic.co/guide/en/logstash/current/output-plugins.html |
||
+ | |||
+ | ===stdout=== |
||
+ | Пример конфигурационного файла для вывода логов в standard output: |
||
+ | <PRE> |
||
+ | output { |
||
+ | stdout { |
||
+ | message => "IP - %{clientip}. Full message: %{@message}. End of line." |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | |||
+ | <PRE> |
||
+ | message => "clIP - %{clientip}. Full message: %{@message}. End of line." |
||
+ | </PRE> |
||
+ | указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации. |
||
+ | |||
+ | ===file=== |
||
+ | Пример конфигурационого файла для записи логов в файл: |
||
+ | <PRE> |
||
+ | output { |
||
+ | file { |
||
+ | flush_interval => 5 |
||
+ | gzip=> true |
||
+ | path => "/var/log/custom/%{clientip}" |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | flush_interval => 5 |
||
+ | </PRE> |
||
+ | интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение (что конечно создаст дополнительную нагрузку на диск). |
||
+ | <PRE> |
||
+ | gzip=> true |
||
+ | </PRE> |
||
+ | файл исходящих сообщений будет сжат Gzip. |
||
+ | <PRE> |
||
+ | path => "/var/log/custom/%{clientip}" |
||
+ | </PRE> |
||
+ | путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. |
||
+ | В данном примере, для каждого уникального IP адреса будет создана своя папка. |
||
+ | |||
+ | <B>Формат как будет записано определяет кодек - в общем случае это JSON</B> Так как кодек всех устраивает в большей части примеров он никак не указан |
||
+ | <PRE> |
||
+ | codec |
||
+ | </PRE> |
||
+ | Value type is codec |
||
+ | Default value is "json_lines" |
||
+ | |||
+ | ===elasticsearch=== |
||
+ | Пример конфигурационного файла для записи логов в базу Elasticsearch: |
||
+ | <PRE> |
||
+ | output { |
||
+ | elasticsearch { |
||
+ | cluster => "es_logs" |
||
+ | host => "192.168.1.1" |
||
+ | port => "19300" |
||
+ | index => "logs-%{+YYYY.MM.dd}" |
||
+ | } |
||
+ | } |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | cluster => "es_logs" |
||
+ | </PRE> |
||
+ | <PRE> |
||
+ | port => "19300" |
||
+ | </PRE> |
||
+ | транспортный port Elasticsearch. |
||
+ | <PRE> |
||
+ | host => "192.168.1.1" |
||
+ | </PRE> |
||
+ | IP адрес Elasticsearch |
||
+ | <PRE> |
||
+ | index => "logs-%{+YYYY.MM.dd}" |
||
+ | </PRE> |
||
+ | название индекса куда будут записываться логи. |
||
+ | |||
+ | =Пример= |
||
+ | Перенесен сюда -> https://noname.com.ua/mediawiki/index.php/LogstashExample1 |
||
+ | |||
+ | =Альтернативы= |
||
+ | * Vector: |
||
+ | ** https://habr.com/ru/post/514480/ |
||
+ | =Ссылки= |
||
+ | * https://stackoverflow.com/questions/57599095/parse-json-array-string-using-logstash |
Текущая версия на 16:27, 23 августа 2021
Logstash
Заметки по Logstash с примерами конфигов
Заметка возникла по-тому что каждый раз когда надо настроить Logstash я обнаруживал что забыл почти все - и решил записать что б в следующий раз зачитать по бумажке
Установка
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - sudo apt-get install apt-transport-https echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list sudo apt-get update sudo apt-get install elasticsearch
Порядок работы - input --> filter (в том числе изменение) -->output
Для каждой фазы есть множество плагинов
input { ... }
filter { ... }
output { ... }
INPUT
Данный метод является входной точкой для логов
Тыщи их если что
В описании только самые простые/ходовые
Beats
Точка для получения логов от Filebeat
- https://www.elastic.co/guide/en/beats/filebeat/current/configuring-howto-filebeat.html
- https://www.elastic.co/guide/en/logstash/current/plugins-inputs-beats.html#plugins-inputs-beats
beats { port => 5400 ssl => true ssl_certificate_authorities => ["/etc/elk-certs/elk-ssl.crt"] ssl_certificate => "/etc/elk-certs/elk-ssl.crt" ssl_key => "/etc/elk-certs/elk-ssl.key" ssl_verify_mode => "force_peer" }
Сертефикаты должны быть подписаны одним CA - по сути тут требуется авторизация с помошью сертефикатов (как например OpenVPN или такое можно делать с nginx)
Важнейшая настройка Ж
ssl_verify_modeedit
Value can be any of: none, peer, force_peer Default value is "none" By default the server doesn’t do any client verification.
peer will make the server ask the client to provide a certificate. If the client provides a certificate, it will be validated.
force_peer will make the server ask the client to provide a certificate. If the client doesn’t provide a certificate, the connection will be closed.
This option needs to be used with ssl_certificate_authorities and a defined list of CAs.
Генерация серетфикатов
Простой скрипт для самоподписанных сертефикатов (хотя конечно лучше организовать свой PKI)
#!/bin/bash CN="logstash.tld" sudo openssl req -subj "/CN=${CN}/" -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout elk-ssl.key -out elk-ssl.crt chown logstash elk-ssl.crt chown logstash elk-ssl.key
Важно: В конфигурации Filbeat нужно указат CN из серетфиката или будет ошибка SSL (что логично когда знаешь но не очевидно сразу)
File
input {
file { path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ] exclude => [ "*.gz", "*.zip", "*.rar" ] start_position => "end" stat_interval => 1 discover_interval => 30 }
}
path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ]
указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (?)
exclude => [ "*.gz", "*.zip", "*.rar" ] исключает из обработки файлы с соответствующими расширениями.
start_position => "end" ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов.
stat_interval => 1 как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк.
discover_interval => 30 время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path.
tcp
Пример конфигурации, для работы с логами удалённых сервисов:
input { tcp { data_timeout => 10 mode => "server" host => "192.168.3.12" port => 3337 } }
Построчное описание настроек:
data_timeout => 10
время (в секундах), по истечении которого не активное tcp соединение будет закрыто. Значение -1 — соединение всегда будет открыто.
mode => "server" host => "192.168.3.12" port => 3337
в этом случае Logstash становится сервером, и начинает слушать на 192.168.3.12:3337. При установке mode => «client» Logstash будет присоединятся к удалённому ip:port для забора логов.
udp
Для udp настройки аналогичные tcp: input { udp { buffer_size => 4096 host => "192.168.3.12" port => 3337 } }
FILTER
Все плагины - https://www.elastic.co/guide/en/logstash/current/filter-plugins.html
В данном блоке настраиваются основные манипуляции с логами.
Это может быть например
- разбивка по key=value
- удаление ненужных параметров
- замена имеющихся значений
- использование geoip или DNS запросов для ип-адресов или названий хостов.
grok
GROK - разбивает строку с помошью регулярных выражений.
Пример конфигурационного файла для основной нормализации логов:
filter { grok { patterns_dir => "/path/to/patterns/" pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" } }
Описание настроек:
patterns_dir => "/path/to/patterns/"
путь к каталогу, содержащим шаблоны обработки логов.
Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны.
pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}"
указывается шаблон разборки логов.
Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов.
Создавать свои шаблоны необязательно - достаточно встроенных
- https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/ecs-v1/grok-patterns
Подробнее про шаблоны
С помощью grok фильтра можно структурировать большую часть логов — syslog, apache, nginx, mysql итд, записанных в определённом формате. Logstash имеет более 120 шаблонов готовых регулярных выражений (regex). Так что написание фильтров для обработки большинства логов не должно вызвать особого страха или недопонимания.
Формат шаблонов относительно простой — NAME PATTERN, то есть построчно указывается имя шаблона и ему соответствующее регулярное выражение. Пример:
NUMBER \d+ WORD \b\w+\b USERID [a-zA-Z0-9_-]+
Можно использовать любой ранее созданный шаблон:
USER %{USERID}
Шаблоны можно так же и комбинировать:
CISCOMAC (?:(?:[A-Fa-f0-9]{4}\.){2}[A-Fa-f0-9]{4}) WINDOWSMAC (?:(?:[A-Fa-f0-9]{2}-){5}[A-Fa-f0-9]{2}) MAC (?:%{CISCOMAC}|%{WINDOWSMAC})
Допустим формат логов у нас следующий (пример шаблона выше):
55.3.244.1 GET /index.html 15824 0.043
С данным примером лога достаточно pattern записать в виде
"%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}"
После обработки наша строка будет выглядеть следующим образом:
client: 55.3.244.1 method: GET request: /index.html bytes: 15824 duration: 0.043
mutate
Пример конфигурационного файла для изменения/удаления записей из логов:
filter {
mutate { remove_field => [ "client" ] replace => { "message" => "%{source_host}: My new message" }
rename => [ "HOSTORIP", "client_ip" ] gsub => [ "message", "\\/", "_" ] add_field => [ "sample1", "from %{clientip}" ] }
}
remove => [ "client" ]
rename => [ "HOSTORIP", "client_ip" ]
переименование название поля HOSTORIP в client_ip.
add_field => [ "sample1", "from %{clientip}" ] добавление нового поля «sample1» со значением «from %{clientip}». Допускается использование названий переменных или статических значений.
date
Пример конфигурационого файла:
filter {
date { match => [ "timestamp", "MMM dd HH:mm:ss" ] }
}
match => [ "timestamp", "MMM dd HH:mm:ss" ]
временная метка события.
Если в логах время указано в unix timestamp, то следует использовать match => [ «timestamp», «UNIX» ]
kv
Пример конфигурационного файла для обработки логов в формате key=value:
filter { kv { value_split => "=:" fields => ["reminder"] field_split => "\t?&" } }
value_split => "=:"
использовать символы "=" и ":" для разделения ключа-значения.
fields => ["reminder"]
название поля в котором искать 'ключ=значение'. По умолчанию разбивка будет происходить для всей строки лога.
field_split => "\t?&"
использовать символы "\t?&" для разделения ключей. \t — знак табулятора
OUTPUT
stdout
Пример конфигурационного файла для вывода логов в standard output:
output { stdout { message => "IP - %{clientip}. Full message: %{@message}. End of line." } }
message => "clIP - %{clientip}. Full message: %{@message}. End of line."
указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации.
file
Пример конфигурационого файла для записи логов в файл:
output { file { flush_interval => 5 gzip=> true path => "/var/log/custom/%{clientip}" } }
flush_interval => 5
интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение (что конечно создаст дополнительную нагрузку на диск).
gzip=> true
файл исходящих сообщений будет сжат Gzip.
path => "/var/log/custom/%{clientip}"
путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. В данном примере, для каждого уникального IP адреса будет создана своя папка.
Формат как будет записано определяет кодек - в общем случае это JSON Так как кодек всех устраивает в большей части примеров он никак не указан
codec
Value type is codec Default value is "json_lines"
elasticsearch
Пример конфигурационного файла для записи логов в базу Elasticsearch:
output { elasticsearch { cluster => "es_logs" host => "192.168.1.1" port => "19300" index => "logs-%{+YYYY.MM.dd}" } }
cluster => "es_logs"
port => "19300"
транспортный port Elasticsearch.
host => "192.168.1.1"
IP адрес Elasticsearch
index => "logs-%{+YYYY.MM.dd}"
название индекса куда будут записываться логи.
Пример
Перенесен сюда -> https://noname.com.ua/mediawiki/index.php/LogstashExample1
Альтернативы
- Vector: