ELK: Анализ почтовых журналов.

Итак, на сегодня у нас готовы:
1. Сбор журналов почтового сервера;
2. Их парсинг для упрощения анализа.
Займемся тем, ради чего все затеяно – собственно анализом.
Автоматизированный анализ, освобождающий наше время для чтения Интернета, пока отложим и займемся первичным визуальным анализом (Exploratory Data Analysis).
Для начала, нам нужно нечто, красиво формующее получаемые журналы.
Сделаем это посредством Kibana. Для этого был сделан небольшой dashboard выложенный на  github.com . Забирайте. Прежде чем загрузить dashboard в Kibana, в любом текстовом редакторе сделайте замену “dom1.int” и “dom2.int” на свои собственные домены.

Пара слов о dashborde. Он состоит из 5ти блоков.
1. “ALLMAIL” - Cодержит общий график отражающий количество отправленных и принятых сообщений по типу: внутренние, пришедшие извне, ушедшие вовне.
2. “INTERNAL” - график и таблицы для сообщений пересылаемых внутри периметра
 таблица “Source count (all)” - количество отправленных сообщений в штуках
 таблица “Destination count (all)” - количество полученных сообщений в штуках
 таблица “Summ by src (all)” - объем отправленных сообщений в байтах
 таблица “Summ by dst (all)” - объем полученных сообщений в байтах
3. “INSIDE” - график и таблицы для сообщений входящих в периметр
 набор таблиц аналогичен блоку “INTERNAL”
4. “OUTSIDE” - график и таблицы для сообщений выходящих за периметр
 набор таблиц аналогичен блоку “INTERNAL”
5. “ALL EVENTS” - таблица сообщений с полями, разобранными на предудущем этапе:
 @timestamp – примерное время отправки\приема сообщения
 source – источник (электронный адрес)
 destination – получатель (электронный адрес)
 subject - тема
 size – размер в байтах

Давайте скорее займемся самым интересным – анализом. Рассмотрим не очень сложный сценарий, который не просто выполнить сортировками почтовых журналов – будем искать сотрудников, пересылающих свою почту на внешний почтовый ящик.
Итак открываем dashboard “Maillog analysis” (пример сделан на данных последней недели января). Выберем четрверг с полуночи до полуночи. На периоде в сутки, как будет видно дальше, анализ проще.

Сразу замечаем человечка, который, вероятно, настроил пересылку. Делаем фильтр по его внутреннему адресу, щелкнув на значке лупы в любой из таблиц.

Видим, что в рамках рабочего дня (выделено красным), графики коррелируют довольно сильно, а за пределами – графики абсолютно идентичны. Разница вида графиков в рабочее время обусловлена тем, что сотрудник отправляет почту не только на внешний почтовый ящик, но и внутри периметра.
Для более точного анализа, отфильтруем сообщения, которые адресованы только на внутренний адрес сотрудника либо на его внешний адрес.
Фильтр, содержащий логику в kibana, формируется с особенностью – логический оператор пишется с использованием прописных букв:

 destination: “username@ dom1.int” OR “external@email.box”  

 

К счастью мы видим, что пересылка осуществляется не полностью. Сотрудник настроил пересылку только с определенных адресов для получения диспетчерских сводок. Дальнейшая проверка подтвердила это. Но сейчас мы об этом не знаем. Если закрыть глаза на разницу графиков в рабочее время, то по ночным журналам можно заряжать зондер-команду и отправлять ее вязать нарушителя. Подтверждение - пересылки почты вне рабочего дня - приведено на рисунке.

Ограничения метода:
1. Высокая трудоемкость, как следствие нерегулярность.
2. Не полное покрытие – отсеиваем сотрудников с большим трафиком и не замечаем слабонагруженные адреса, которые никогда не окажутся в топах.

Вообще, созданный dashboard, позволяет увидеть много интересного:
1. Сбои в работе почтовой системы – не фатальные, которые все замечают без специальных средств, а те в которых появляются задержки в пересылке, например. На первом рисунке видно, что почтовую систему лихорадило в пятницу, хотя на сбои в пересылке почты никто не жаловался.
2. Массовые рассылки, в том числе произведенные вредоносным ПО.
Выведя его на экран ситуационного центра, проходя мимо, можно зацепиться за что-нибудь глазами и выполнить детальный анализ уже на рабочем месте.

Буду рад, если сообщество предложит свои сценарии или направления анализа, с тем чтобы модифицировать dashboard и выложить его для использования.

ELK: Анализ почтовых журналов. Подготовка. Logstash.

Некоторое время назад мы начали готовиться к анализу почтовых журналов. Продолжим подготовку.
Используем logstash для парсинга сообщения на поля.
Тут нет ничего интересного и сложного. Вот часть файла конфигурации (/etc/logstash/conf.d/filter.conf), разбирающая сообщения, формируемые в предыдущей заметке:

 ...  
  else if [message] =~ "Secure_Maillog" {  
    mutate { replace => { "type" => "maillog" } }  
    grok {  
     patterns_dir => "/etc/logstash/patterns"  
     match => ["message", "<134>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}  
     \s+%{WORD:syslogprog}:\s+%{NUMBER:timestamp}\t%{EMAIL:source}  
     \t%{EMAIL:destination}\t%{NUMBER:size:int}\t%{GREEDYDATA:subject}"]  
    }  
    date {  
     match => ["timestamp", "UNIX"]  
    }  
  }  
 ....  

В "/etc/logstash/patterns" хранятся файлы с шаблонами. В частности файл "/etc/logstash/patterns/mail" состоит из следующих строк:

 LOGIN [A-Za-z0-9$.+!*'(),~#%&/=:;_-]+  
 EMAIL %{LOGIN}@%{IPORHOST}  
 GREEDYDATA .*  

На сегодня все.

ELK: Ситуационный центр своими руками

Заполним вынужденную паузу про ELK, продолжим развлекаться в канун праздников.
Месяц назад на Хабре проскочила рекламная статья про ситуационные центры, которая вдохновила на создание чего-то похожего своими руками.
Сначала на отдельно стоящий монитор была выведена консоль для мониторинга кластера, который таки был собран (о чем может быть позже, когда рецепт будет вылизан и записан).
Жизнь оказалась слишком прозаична – игры с ELK начали набивать оскомину, поэтому в консоли заглядывали уже не так часто как в начале. В то же время, постоянно включенная консоль мониторинга состояния кластера бросалась в глаза постоянно и, когда кластер желал внимания, привлекала оное своей желтизной или даже краснотой.
Эта особенность отфильтровалась сознанием и было принято решение вывести на нашу «видеостену» диагональю 19”, в том числе информацию с основными индикаторами состояния сети. К сожалению, определить и вывести на один экран правильные индикаторы не получилось, по причине отсутствия последних. Даже придумать их не получилось. Может космический разум предложит что-то? Поэтому было принято решение попеременно выводить на «видеостену» разные dashboards, беглый взгляд на которые поможет понять, что что-то идет не по плану. Опять же мигание и смена видов добавит новогоднего настроения в кабинете.
Сказано, сделано.
Так как свободных компьютеров у нас не оказалось, ситуационный центр был собран на одном из узлов кластера, размещенных под столом. Клавиатуру и мышку можно не подключать, для работы достаточно ssh.
Как поставить пакеты на вашу систему, думаю, разберетесь самостоятельно. Повторюсь, мы работаем с клоном Unix, точнее с Debian.
Из того, что обычно не устанавливается на серверы, нам понадобится:

• Xorg
• firefox (iceweasel)
• xdotool

Как настроить машину для автоматического запуска Xorg, легко найти в сети. Для нормальной работы более чем достаточно прав обычного пользователя.
А теперь, собственно, скрипт, который будет творить магию на мониторе:

  #!/bin/bash   
  #Kibana and Marvel host   
  HOST="ХХХ.ХХХ.ХХХ.ХХХ"            
  #Marvel URL   
  URL="http://$HOST:9200/_plugin/marvel/kibana/index.html#/dashboard/file/marvel.overview.json"   
  #Kill everything   
  killall iceweasel            
  killall Xorg             
  #wait a moment   
  sleep 3               
  #start new Xorg   
  Xorg :1 &   
  #prepare DISPLAY variable for output   
  export DISPLAY=:1   
  #wait Xorg startup   
  sleep 1   
  #disable screensaver   
  xset s off   
  #disable power management for monitor   
  xset -dpms   
  #start browser.   
  iceweasel -width 1920 -height 1080 --display=:1 $URL &   
  sleep 30   
  #if Marvel show agreement - accept   
  xdotool mousemove 1100 250   
  xdotool click 1   
  sleep 5   
  #if Marvel show form for developer - skip   
  xdotool mousemove 1000 450   
  xdotool click 1   
  sleep 5   
  #fullscreen for browser   
  xdotool key F11   
  #get dashboards list from Kibana   
  _URL=$(curl -s -XGET "http://$HOST:9200/kibana-int/dashboard/_search?fields=title" | grep -Po '"title":.*?[^\\\\]"\]\}\},' | sed 's/.*\["//' | sed 's/"\].*//' | sed 's/ /%20/g')   
  #Prepare list of URL   
  for i in $_URL; do   
   URL="http://$HOST/kibana/#/dashboard/elasticsearch/$i $URL";   
  done   
  #forever change dashboards   
  while true; do.   
   for i in $URL; do   
    sleep 60   
    xdotool key "CTRL+l"   
    xdotool type $i   
    xdotool key Return   
    xdotool key F11   
    xdotool key F11   
   done   
  done   

Теоретически, можно было бы вывести на монитор основные графики, которых может хватить для беглого анализа глазами, но пока нет мыслей, как это сделать правильно.
PS. Этот скрипт поступает не очень честно с ребятами из elasticsearch.com, отщелкивая согласие с лицензией. Решайте сами как вам с этим быть.

ELK в технологии

Переменка.
Тренировался в способах импорта данных в Elasticsearch, так же хотелось поиграться с "интенсивными и объемными" данными. Попросил данные у метрологов за месяц. Отдали с улыбкой, сказав, что какая-то жутко прогрессивная и дорогая система визуализации данных не справилась с их объемами, поэтому анализ больше чем за 1 день сделать не получается.
Получите и распишитесь.

Характеристика данных:
1. Объем данных 7.2 гб

2. Количество записей 122 000 000

3. Количество параметров: 713

4. Период месяц

Старый десктоп и пара ноутбуков (2-4 CPU, 4Gb RAM) собранные в кластер делают месячную выборку по 4м параметрам за несколько секунд.

Схема или, в терминах эластика, mapping:

 "sdku_type": {  
  "_all" : {"enabled" : false},    
  "_source" : {"enabled" : false},    
  "properties": {  
  "@timestamp": {  
   "type": "date",  
   "format": "dateOptionalTime"  
  },  
  "field": {  
   "type": "string"  
  },  
  "value":{  
   "type": "double"  
  }  
  }  
 }  

Скрипт для импорта:

 #!/usr/bin/python  
 import csv, sys, time, json, elasticsearch  
 from elasticsearch import helpers  
 es = elasticsearch.Elasticsearch(['localhost:9200'])  

 csvfile = 'MyTable.csv'  
 jdata = dict()  
 actions = list()  
 i = 0  

 with open(csvfile, 'rb') as file :  
   line = csv.reader(file, delimiter = ',', skipinitialspace = True)  
   for row in line :  
      i += 1  
      ptime = time.strptime(row[0][0:19], "%Y-%m-%d %H:%M:%S")   
      ctime = time.strftime('%Y-%m-%dT%H:%M:%S', ptime)   
      jdata = { '@timestamp': ctime, 'field': row[1], 'value': float(row[2]) }  
      action = { '_index': 'sdku', '_type': 'sdku_type', '_id': i, '_source': json.dumps(jdata, separators=(',', ':'))}  
      actions.append(action)  
      if i % 1000000 == 0:  
        elasticsearch.helpers.bulk(es, actions)  
        print "Indexed %d, working on next 100000" %(i)  
        actions = list()  
   elasticsearch.helpers.bulk(es, actions)  
   print "Indexed %d, finishing." %(i)  

Результат:

Возникла дилемма - показать результат и оказаться втянутым в работу метрологической службы или сделать вид, что проиграл?

ELK: Анализ почтовых журналов. Подготовка

Продолжим тематику визуального анализа журналов. С журналов доступа в сеть Интернет переключимся на почтовые.
Начнем с получения журналов с почтового сервера и их подготовку к передаче ELK.
Так получилось, что в моей сети в качестве внутреннего почтового сервера используется Microsoft Exchange 2003. Каким-то неведомым мне образом, раз в сутки в почту падает файл с архивом почтового журнала сервера за предыдущий день. Мы пытались настоять на том, чтобы журналы отправлялись по протоколу syslog c помощью snare, но в этом было отказано под "уважительным" предлогом "высокой чувствительности пользователей к минимальным задержкам в работе сервиса".
Сначала письмо, как и множество других, проходит через procmail. Оно попадает под действие правила:

 :0:  
 * ^Subject(.*Exchange log file*)  
 {  
   :0 Bcw  
   | /home/sa/bin/logs/ExtractAttachment.pl  
   :0 a  
   | /home/sa/bin/logs/ImportMaillog.pl  
   :0  
   inbox/mailstat/.  
 }  

Скрипт "/home/sa/bin/logs/ExtractAttachment.pl" является вариантом этого скрипта.
За скрипт "home/sa/bin/logs/ImportMaillog.pl" не судите строго. Он писался в режиме "быстрее хоть что-нибудь" и сейчас исправлять его не хочется, потому-что "работает!".

 use strict;  
 use Encode qw(decode);  
 use Time::Local;  
 use Sys::Syslog;  
 use open qw(:std :utf8);  
 my $configfile = "/home/sa/bin/logs/rcfile";  
 my $conf = new Config::General("$configfile");  
 my %config = $conf->getall;  
 open (FILE, "<:encoding(utf8)", "/tmp/maillog.tmp") or die "Can't open file /tmp/maillog.tmp!\n";  
 open (OFILE, ">/tmp/maillog") or die "unable to open /tmp/maillog !";  
 openlog("Secure_Maillog", "ndelay", "local0");  
 while (<FILE>) {  
   s/\<\>/postmaster\@udmurtneft.ru/g;  
   my @str = split(/\t/);  
   my $str18 = "";  
   if ( $str[8] =~ /102[80]/ ) {  
      if ( $str[18] =~ /=?/ ) {  
        $str[18] =~ s/UNICODE-1-1-UTF-8/UTF-8/g;  
        $str[18] =~ s/unicode-1-1-utf-7/UTF-8/g;  
        $str[18] =~ s/x-user-defined/UTF-8/g;  
        $str[18] =~ s/gb18030/windows-1251/g;  
        $str[18] =~ s/window-1251/windows-1251/g;  
        $str[18] =~ s/UNKNOWN/windows-1251/g;  
        $str[18] =~ s/134/windows-1251/g;  
        my $flag = utf8::is_utf8($str[18]);  
           $str[18] = Encode::decode('MIME-Header',$str[18]);  
           $str18 = $str[18];  
      }  
      $str[1] =~ s/ GMT//g;  
      my $time = $str[0]." ".$str[1];  
      my @t = ($time =~ /^(\d{4})-(\d{1,2})-(\d{1,2})\s(\d{1,2}):(\d{1,2}):(\d{1,2})/);  
      $t[1]--; $t[3] = $t[3]+4;  
      if ( $t[3] > 23 ) { $t[3] = $t[3] - 24 };  
      my $timestamp = timelocal 0,@t[4,3,2,1,0];  
      print OFILE "\t$timestamp\t$str[19]\t$str[7]\t$str[12]\t$str[18] \n";  
      syslog('mail|info', $timestamp."\t".$str[19]."\t".$str[7]."\t".$str[12]."\t".$str[18]);  
   }  
 }  
 closelog();  
 close(OFILE);  
 system("mysqlimport --local logs /tmp/maillog --user=$config{db}->{user} --password=$config{db}->{password}");  
 unlink("/tmp/maillog.tmp");  
 unlink("/tmp/maillog");  
 unlink("/tmp/report.zip");  

Важные строки выделены жирным. Первая из них передает строку журнала в syslog, а оттуда в logstash. Вторая записывает в олдскульный sql для тяжелого анализа.
В следующий раз, чтобы разбавить тему анализа глазами. рассмотрим что можно достать из SQL.
PS. Если вы захотите отметить, что хранить временные файлы в общей директории /tmp не безопасно, то ответа будет два:
1. На сервере, куда падают журналы, все пользователи имеют доступ к ним.
2.

 $ cat /etc/profile | grep umask  
 umask 077  

Осторожно, серпантин или особенность систем BigData.

Elasticsearch - замечательный продукт, который дарит нам не только удовольствие от пользования качественным ПО, но и ощущение скоростной езды по горной дороге. Вираж, запрос - ответ. Перевал, фильтр - выборка
А скорость?! В mysql выборка по одной учетной записи за сутки, с целью посчитать с каких же сайтов человек накачал больше всего байтов занимало 30-40 секунд. А тут суточная выборка по всем сотрудникам, с определением байтового ТОРа и пяток других запросов выполняются менее чем за секунду! Вот оно "счастие аналитика".
Но не все на СТОЛЬКО хорошо. Особенностью работы с большими данными, а ES позиционирует себя как продукт для обработки больших массивов информации, является снижение точности.
Давайте не будем падать в дебри 100% корректного описания внутренней кухни ES, а упростим описание в угоду пониманию. Кому нужны детали, добро пожаловать на сайт производителя. Все-равно лучше его не скажешь.
Итак. ES видит много-много (именно "много", а не 1478) запросов от пользователя Иванов на сайт www.ru. Все запросы примерно одинаковы (положим javasctipt резвится) и более-менее регулярны.
И тут, неожиданно для всех, аналитик Петров спрашивает - скажи ка мне, дорогой Elastic, а сколько раз сотрудник Иванов обращался к сайту www.ru. У ES нет времени на раздумья, ведь главное ответить быстро, чтобы Петров не успел забыть вопрос. Поэтому ES смотрит, что Иванов обращался к www.ru в 1й, 10й и 20 часы примерно 60 раз в час, значит за сутки он сделал около 1440 обращений. Эта цифра и летит на экран. Примерно 1440, нужно держать в голове аналитику Петрову.
Хорошо, отвечает ошалевший от скорости ответа Петров, а сколько байтов сотрудник Иванов выдернул с сайта www.ru? И практически мгновенно получает ответ 288000. Замечательно! Тем более, что это почти соответствует точной цифре, то есть примерно 288000. А ES просто умножил 1440 на средний размер ответа сервера равный 200 байтам, который опять рассчитал по быстрому.
Все довольны, Петров отходит ко сну. Занавес.
"Да ладно", скажете вы, "выдумываешь тут какую-то чушь! Я по калькулятору считал. Байты почти сошлись".
"Здорово", отвечу я, "только не всегда прогнозы и усреднения оказываются верными". Посмотрите на картинку ниже.

Утренний анализ за чашечкой кофе показал, что пользователь serg вытянул из Интернета за последние сутки примерно 221 мегабайт. Ну-ка глянем, чего это он вчера был таким вялым?

И видим, что цифра меняется в 1.5 раза! Все в шоке. Как так?
Оказывается - сменился контекст выборки и алгоритмы усреднения дали новый результат, который, кстати говоря, сильно ближе к реальному. Это и есть особенность работы с большими данными или цена скоростной выборки.
Мораль - будьте осторожны на горной серпантине и он подарит вам множество отличных видов.

Анализ журналов прокси. Продолжение

Почему-то Интернет ломится от статей в стиле "как собрать логи", но статей описывающих, что с этими логами можно сделать практически нет.
Давайте попытаемся заполнить эту нишу и рассмотрим несколько возможных сценариев анализа журналов прокси сервера собранных нами ранее.

Классика:«кто больше съел»
Тут все просто. В панели «Down by user» (это не оскорбление. слово download не влезло в панель) выбираем верхних пользователей, щелкаем на изображении лупы и анализируем

Причем, что удобно, мы на одном экране видим:

1. Человечек смотрел видео с youtube;
2. Человечек начал это делать в обед (12-13);
3. Человечек не смог остановиться, когда обед закончился.

Можно проанализировать, что он смотрел, сопоставить это с журналами работы с информационными ресурсами, но этим сегодня заниматься не будем. Классика!
Классика «слабое звено»

Допустим, мы хотим посмотреть, кто ищет себе работу? Добавляем запрос «urihost: *job* or *rabota* or hh.ru» и наблюдаем кандидатов на анализ. Благодаря панели «Upload max» можно даже отловить момент выкладывания резюме.

В момент написания поста ничего интересного не происходило, поэтому просто посмотрите, что в обед люди не только отдыхают, но и занимаются серфингом по сайтам навевающим грусть на HR.
Стандартный «кто послал»
Вы, наверное, уже обратили внимание на панельку «Upload max» справа от панели запросов. Эта панель показывает размеры индивидуальных отправок данных через прокси-сервер. То есть на ней визуально мы можем выявить нарушения связанные с отправкой наружу информации. Таблично это делать не очень удобно
Смотрим, как у нас дела были в последние 12 часов.

Ага, видим 12 мегабайтную отправку. Уменьшаем время, за которое проводится анализ, так как количество событий в секунду превышает 50.

Уточняем. Фильтруем по пользователю и затем по имени сайта

И вот мы видим, кто отправил информацию и куда. К счастью это штатная отправка на сайт закупок, на анализ которой потребовалось несколько секунд.
Стандартный «масс-контакт»
Случилось некоторое время назад такое, что корпорация добра несколько усовершенствовала свой браузер, в результате чего в нем как-то особенно выделился функционал чата. В результате на прокси обрушился шквал запросов на соединение с IM-сервером, которые отклонялись. Это не есть хорошо.
Чтобы продемонстрировать работу по анализу, пришлось отключить фильтрацию отклоненных запросов (TCP_DENIED). В результате наблюдаем сайт требующий нашего внимания – urs.microsoft.com. Он не связан с IM, описанным в предыдущем абзаце, но для примера пойдет.

Продвинутый «ratio»К сожалению, такой вид анализа на ELK мне пока не удалось реализовать. Его идея в том, чтобы делать расчет соотношения информации отправленной на сайт к принятой. Этот способ анализа позволяет выявлять туннели и сайты-интерфейсы к IM, например. Делается все на сегодня запросом из SQL, где журналы так же хранятся. Нужно сохранить немного брутальности.
Продвинутый «reputation»
Это из раздела помечтать. Идея – дергать из репутационных баз информацию о доверии сайтам и выводить информацию на экран анализа. Идея навеяна плагином WOT для браузеров.

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

Анализ журналов прокси

Так получилось, что отдел, в котором я работаю, в основном состоит из сотрудников правоохранительных органов, представления о защите информации у которых отличаются от моих. В частности, одним из основных показателей благополучия в информационной системе является «правильное» использование сотрудниками ресурсов сети Интернет. «Правильное» можно расшифровать как мало и редко. И, так как проверки по этим критериям достаточно просто организовать, отчет по результатам мониторинга работы пользователей в сети Интернет становится одним из ключевых в работе отдела.
Как собирать журналы, описано многократно и много где.
Давайте поподробнее рассмотрим, как их анализировать, чтобы покрыть нужды коллег пришедших в коммерческую безопасность из органов и решить свои задачи.
Есть брутальный способ, для настоящих мужиков, через запись журналов в какой-нибудь SQL и запросы к нему из командной строки в стиле:

---

select id, from_unixtime(time), r_host, inet_ntoa(r_ip), r_port, sum(sc_bytes) from proxylog where time > (UNIX_TIMESTAMP() - 86400*2) and cs_username like 'ХХХ' group by r_host order by sum(sc_bytes);

---

Используя его, мы можем быть уверенными, что анализ журналов не сможет сделать никто кроме нас. Это по-своему круто и дает нам определенный авторитет.
Но давайте повернемся лицом к коллегам и используем стандартную на сегодня связку Logstash-Elasticsearch-Kibana (ELK в английском просторечии) для анализа журналов. Вероятно, есть более оптимальные решения, но они потребуют больше времени на настройку и тюнинг. Итак…


ELK мне было удобно поставить на Debian. Правильный "Debian way" описан на этой страничке.

Squid:
Журналы Squid падают в Logstash. Способы выбирайте сами, они описаны во многих местах.
Пара особенностей. По подсказке коллеги из головной конторы, в журнал был добавлен заголовок referrer, а по моей инициативе - количество отправленных байт. В результате директива logformat выглядит так:

---

%ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt %>st %{Referer}>h

---

Logstash:
Чтобы падающие сообщения были нормализованы, то есть из потока символов была извлечена информация, используем вот такую конструкцию:

---

…
else if [message] =~ "(squid)" {
mutate { replace => { "type" => "squid-access" } }
grok {
match => ["message", "<14>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}\s+\(%{WORD:syslogprog}\):\s+%{NUMBER:timestamp}\s+%{NUMBER:request_msec}\s+%{IPORHOST:client}\s+%{WORD:cache_result}/%{NUMBER:status}\s+%{NUMBER:size:int}\s+%{WORD:http_type}\s+(%{URIPROTO}://)?(?:%{USER}(?::[^@]*)?@)?(?:%{URIHOST:urihost})?(?:%{URIPATHPARAM})?\s+(%{WORD:username}|-)\s+%{WORD:request_route}/(%{IPORHOST:forwarded_to}|-)\s+%{NOTSPACE:content_type}
\s+%{NUMBER:send_size:int}\s+(%{URI:referer}|-)"]
}
}
…

---

Тут и мне, написавшему этот жуткий regexp, мало что понятно с ходу, но когда будете настраивать logstash разберетесь что к чему - выбора не будет.
ElasticSearch:
Прелесть этой "не базы данных" в том, что все в ней хранится как-то. Поля, индексы, типы - все это появится в момент, когда вы решите заняться оптимизацией или добиться каких-то расширенных возможностей. Что происходит внутри связки ELK нам не важно. На вход мы подаем поток текста, на выходе получаем "кузявые" таблички и графики.
Kibana:
Статей по настройке интерфейса Kibana великое множество. Мне показалось, что эффективнее всего ставить себе какую-то задачу и искать механизм реализации задачи в ограничениях данного нам средства.
В результате для анализа журналов прокси сервера получился такой интерфейс

Панельки пришлось сделать поменьше, чтобы они все помещались на монитор одновременно. Поэтому по всем параметрам показывает TOP5. Чаще всего этого достаточно. Больше чем на 1-2 "нарушителей" в день нет времени.
Схему можно скачать здесь.

Основные способы применения решения рассмотрим в следующий раз.

Opensource vs. Non-opensource

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

Opensource vs. Non-opensource from Sergey Soldatov