Собираем, парсим и отдаём логи с помощью Logstash

Пример конфигурации, для работы с локальными лог-файлами:

input {
  file {
    type => "some_access_log"
    path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ]
    exclude => [ "*.gz", "*.zip", "*.rar" ]
    start_position => "end"
    stat_interval => 1
    discover_interval => 30
  }
}

Построчное описание настроек:

type => "some_access_log"

тип/описание лога. При использовании нескольких входных блоков, удобно их разделять для последующих действий в filter или output.

path => [ "/var/log/vs01/*.log", "/var/log/vs02/*.log" ]

указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (/path/to/logs/), а не относительным (../../some/other/path/). 

exclude => [ "*.gz", "*.zip", "*.rar" ]

исключает из обработки файлы с соответствующими расширениями.

start_position => "end"

ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов.

stat_interval => 1

как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк.

discover_interval => 30

время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path.

Пример конфигурации, для работы с логами удалённых сервисов:

input {
  tcp {
    type => "webserver_prod"
    data_timeout => 10
    mode => "server"
    host => "192.168.3.12"
    port => 3337
  }
}

Построчное описание настроек:

type => "webserver_prod"

тип/описание лога.

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 настройки аналогичные tcp:

input {
  udp {
    type => "webserver_prod"
    buffer_size => 4096
    host => "192.168.3.12"
    port => 3337
  }
}

Пример конфигурационного файла для основной нормализации логов:

filter {
  grok {
    type => "some_access_log"
    patterns_dir => "/path/to/patterns/"
    pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}"
  }
}

Построчное описание настроек:

type => "apache_access"

тип/описание лога. Здесь надо указать тот тип (type), который прописан в блоке input для которого будет происходить обработка.

patterns_dir => "/path/to/patterns/"

путь к каталогу, содержащим шаблоны обработки логов. Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны.

pattern => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}"

указывается шаблон разборки логов. Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов. Что бы не путаться, я для каждого формата логов создаю отдельный шаблонный файл.

Пример конфигурационного файла для изменения/удаления записей из логов:

filter {
  mutate {
    type => "apache_access"
    remove => [ "client" ]
    rename => [ "HOSTORIP", "client_ip" ]
    gsub => [ "message", "\\/", "_" ]
    add_field => [ "sample1", "from %{clientip}" ]
  }
}

Построчное описание настроек:

type => "apache_access"

тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.

remove => [ "client" ]

удаление всех данных имеющих название поля client. Возможно указание нескольких названий полей.

rename => [ "HOSTORIP", "client_ip" ]

переименование название поля HOSTORIP в client_ip.

gsub => [ "message", "\\/", "_" ]

замена всех «/» на «_» в поле messages.

add_field => [ "sample1", "from %{clientip}" ]

добавление нового поля «sample1» со значением «from %{clientip}». Допускается использование названий переменных.

Пример конфигурационого файла:

filter {
  date {
    type => "apache_access"
    match => [ "timestamp", "MMM dd HH:mm:ss" ]
  }
}

Построчное описание настроек:

type => "apache_access"

тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.

match => [ "timestamp", "MMM dd HH:mm:ss" ]

временная метка события. Важная настройка для дальнейшей возможности сортировки или выборки логов. Если в логах время указано в unix timestamp (squid), то следует использовать match => [ «timestamp», «UNIX» ]

Пример конфигурационного файла для обработки логов в формате key=value:

filter {
  kv {
    type => "custom_log"
    value_split => "=:"
    fields => ["reminder"]
    field_split => "\t?&"
  }
}

Построчное описание настроек:

type => "custom_log"

тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.

value_split => "=:"

использовать символы «=» и «:» для разделения ключа-значения.

fields => ["reminder"]

название поля в котором искать ‘ключ=значение’. По умолчанию разбивка будет происходить для всей строки лога.

field_split => "\t?&"

использовать символы «\t?&» для разделения ключей. \t — знак табулятора

Пример конфигурационного файла для «склеивания» многострочных логов (например Java stack trace):

filter {
  multiline {
    type => "java_log"
    pattern => "^\s"
    what => "previous"
  }
}

Построчное описание настроек:

type => "java_log"

тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.

pattern => "^\s"

регулярное выражение

what => "previous"

при соответствии шаблону «pattern» строка принадлежит предыдущей (previous) строке.

Пример конфигурационного файла для вывода логов в standard output:

output {
  stdout {
    type => "custom_log"
    message => "IP - %{clientip}. Full message: %{@message}. End of line."
  }
}

type => "custom_log"

тип/описание лога.

message => "clIP - %{clientip}. Full message: %{@message}. End of line."

указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации.

Пример конфигурационого файла для записи логов в файл:

output {
  file {
    type => "custom_log"
    flush_interval => 5
    gzip=> true
    path => "/var/log/custom/%{clientip}/%{type}"
    message_format => "ip: %{clientip} request:%{requri}"
  }
}

type => "custom_log"

тип/описание лога.

flush_interval => 5

интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение.

gzip=> true

файл исходящих сообщений будет сжат Gzip.

path => "/var/log/custom/%{clientip}/%{type}"

путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. В данном примере, для каждого уникального IP адреса будет создана своя папка и сообщения будут записываться в файл соответствующий переменной %{type}.

message_format => "ip: %{clientip} request:%{requri}"

формат исходящего сообщения.

Пример конфигурационного файла для записи логов в базу Elasticsearch:

output {
  elasticsearch {
    type => "custom_log"
    cluster => "es_logs"
    embedded => false
    host => "192.168.1.1"
    port => "19300"
    index => "logs-%{+YYYY.MM.dd}"
  }
}

type => "custom_log"

тип/описание лога.

cluster => "es_logs"

название кластера указанного в cluster.name в настроечном файле Elasticsearch.

embedded => false

указывает какую базу Elasticsearch использовать внутреннюю или стороннюю.

port => "19300"

транспортный port Elasticsearch.

host => "192.168.1.1"

IP адрес Elasticsearch

index => "logs-%{+YYYY.MM.dd}"

название индекса куда будут записываться логи.

Данный плагин можно использовать для алертов. Минус в том, что любые изменения уведомлений (в принципе как и любых других настроек) требуют перезапуск logstash программы, но разработчик говорит, что возможно в будущем этого не придётся делать.
Пример конфигурационого файла:

output {
  email {
    type => "custom_log"
    from => "[email protected]"
    to => "[email protected]"
    cc => "[email protected]"
    subject => "Found '%{matchName}' Alert on %{@source_host}"
    body => "Here is the event line %{@message}"
    htmlbody => "<h2>%{matchName}</h2><br/><br/><h3>Full Event</h3><br/><br/><div align='center'>%{@message}</div>"
    via => "sendmail"
    options => [ "smtpIporHost", "smtp.gmail.com",
                          "port", "587",
                          "domain", "yourDomain",
                          "userName", "yourSMTPUsername",
                          "password", "PASS",
                          "starttls", "true",
                          "authenticationType", "plain",
                          "debug", "true"
                         ]
    match => [ "response errors", "response,501,,or,response,301",
                        "multiple response errors", "response,501,,and,response,301" ]
  }
}

type => "custom_log"

тип/описание лога.

from => "[email protected]"
to => "[email protected]"
cc => "[email protected]"

если у вас хватило сил дочитать до этих строк, значит вы можете сами определить смысл этих 3х настроек ?

subject => "Found '%{matchName}' Alert on %{@source_host}"

тема письма уведомления. Можно использовать переменные. Например %{matchName} — название условия совпадения из настройки «match».

body => "Here is the event line %{@message}"
htmlbody => "<h2>%{matchName}</h2><br/><br/><h3>Full Event</h3><br/><br/><div align='center'>%{@message}</div>"

тело письма. 

via => "sendmail"

способ отсылки письма. Возможен один вариант из двух — smtp или sendmail.

options => ...

стандартные настройки почтовых параметров.

match => [ "response errors", "response,501,,or,response,301",
                    "multiple response errors", "response,501,,and,response,301" ]

«response errors» — название алерта (записывается в переменную %{matchName}). «response,501,,or,response,301» — критерии срабатывания алертов. В данном примере если поле response содержит значение 501 или 301, то алерт считается сработавшим. Во второй строке используется логика AND, т.е. оба условия должны быть выполнены.