Экспорт технологического журнала 1С в Elastic с помощью Logstash

 Основные функции Logstash:

• Чтение исходных данных из разных источников (файлы, базы данных, API)
• Парсинг и нормализация данных
• Фильтрация и обогащение данных
• Трансформация данных в нужный формат
• Отправка данных в нужное хранилище

Без Logstash пришлось бы делать всю эту работу вручную при подготовке данных для Elasticsearch. А с Logstash весь процесс выгрузки и преобразования данных описывается конфигурационными файлами.

Таким образом, Logstash берет на себя всю рутинную работу по обработке данных от источника до приёмника. Это экономит время разработчика и избавляет от сложной ETL-разработки.

 Обычно Elasticsearch используется для решения таких задач:

• Поиск информации - быстрый и точный поиск по большим массивам текстов, файлов, данных.
• Аналитика - построение срезов, выявление тенденций, группировки. Позволяет извлекать ценные знания из данных.
• Мониторинг - agregaция и визуализация метрик в реальном времени.
• Лог-аналитика - хранение, поиск и анализ логов систем и приложений.
• Программная аналитика - анализ кода и данных о разработке ПО.
• Геопространственная аналитика - поиск и визуализация геоданных на картах.

Основные преимущества Elasticsearch:

• Высокая скорость поиска и анализа больших данных.
• Масштабируемость - легко расширять ёмкость кластера.
• Отказоустойчивость - данные реплицируются по узлам кластера.
• Гибкость - можно хранить и производить поиск по данным в любом формате.
• Простота - документно-ориентированный подход, прост в освоении.

Основные возможности Kibana:

• Построение графиков и диаграмм по данным из Elasticsearch
• Создание информационных панелей (дэшбордов)
• Визуальный конструктор запросов и фильтров
• Быстрый поиск по данным с подсветкой результатов

Без Kibana пришлось бы использовать только текстовый API Elasticsearch для поиска и анализа данных. Это крайне неудобно.

Kibana делает работу с данными в Elasticsearch понятной и доступной для пользователя без навыков программирования. Это opened-source альтернатива BI-инструментам вроде Power BI.

Основные возможности Kibana:

• Построение графиков и диаграмм по данным из Elasticsearch
• Создание информационных панелей (дэшбордов)
• Визуальный конструктор запросов и фильтров
• Быстрый поиск по данным с подсветкой результатов

Без Kibana пришлось бы использовать только текстовый API Elasticsearch для поиска и анализа данных. Это крайне неудобно.

Kibana делает работу с данными в Elasticsearch понятной и доступной для пользователя без навыков программирования. Это opened-source альтернатива BI-инструментам вроде Power BI.

Конфигурационный файл Logstash имеет следующую структуру:

1. Input - настройка источника данных. Может быть файл, сетевой порт, база данных и т.д. Определяет откуда брать данные.

Пример:

input { stdin { } }

2. Filter - фильтры и преобразования данных. Используются для парсинга, структурирования, модификации данных.

Пример:

filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } }

3. Output - настройка куда помещать обработанные данные. Может быть Elasticsearch, файл, Kafka и др.

Пример:

output { elasticsearch { hosts => ["http://elasticsearch:9200"] } }

input {
  file {
    path => "/var/log/logtj/*/*.log"
    start_position => "beginning"
    sincedb_path => "/dev/null"
    tags => [ 'onec' ]
    codec =>   multiline {
      pattern => "^[0-5][0-9]:([0-5]?[0-9]|60).[0-9]{6}"
      negate => 'true'
      what => 'previous'
    }  
  }
}

Что означает эта настройка:

1. file - означает, что источником данных являются файлы.
2. path - указывает путь к лог-файлам, из которых будут считываться данные. Здесь это все файлы с расширением .log в директории /var/log/logtj/ и её поддиректориях.
3. start_position - указывает, что читать файлы нужно с самого начала.
4. sincedb_path - временная БД для хранения текущей позиции чтения из файлов. Здесь указан /dev/null, то есть эта БД не будет использоваться.
5. tags - добавляет метку onec ко всем событиям из этих файлов.
6. codec - настройка multiline фильтра для обработки многострочных сообщений:

• pattern - регулярное выражение для определения нового сообщения. Все строки до строки, подходящей под выражение, будут объединены.
• negate - true означает, что pattern применяется ко всем кроме подходящих строк.
• what - previous объединяет текущую строку с предыдущим сообщением.

filter {

         if "onec" in [tags] {
                 grok {
                         patterns_dir => ["/usr/share/logstash/pipeline/patterns"]
                         match => { "message" => "%{TIME:MoH}[0-9]{3}-%{DURATION:duration_msec:int},%{TYPE:event},%{NESTING:nesting_level:int}" }
                         match => { "message" => ",process=%{PROCESS:process}" }
                         match => { "message" => "p:processName=%{PPROCESSNAME:pprocessname}," }
                         match => { "message" => "t:applicationName=%{WORD:application},"}
                         match => { "message" => "t:clientID=%{WORD:clientid},"}
                         match => { "message" => "Usr=%{USERNAME:username},"}
                         match => { "message" => "DataBase=%{USERNAME:infobase},"}
                         match => { "message" => "OSThread=%{WORD:osthread},"}
                         match => { "message" => "SessionID=%{WORD:sessionid},"}
                         match => { "message" => "Regions=%{REGION:region},"}
                         match => { "message" => "Locks=[\"\']%{INSIDEQUOTES:locks}[\"\'],"}
                         match => { "message" => "WaitConnections=%{WORD:waitconnections},"}
                         match => { "message" => "Context=[\"\']%{INSIDEQUOTES:context}[\"\']"}
                         match => { "message" => "Descr=[\"\']%{INSIDEQUOTES:description}[\"\']"}
                         match => { "message" => "Sdbl=[\"\']%{INSIDEQUOTES:sdbl}[\"\']"}
                         match => { "path" => ".*%{DaHFILE:DaH}\.log"}
                         break_on_match => false
                 }
                 mutate {
                         add_field => { "MyTime" => "%{DaH}%{MoH}" }
                        remove_field => [ "DaH", "MoH" ]
                 }
                 date {
                         match => ["MyTime", "yyMMddHHmm:ss.SSS"]
                         timezone => "Europe/Moscow"
                         remove_field => [ "MyTime" ] 
                         target => "@timestamp"
                 }
                 ruby {
                        code => "
                        event.set('duration_sec', if event.get('duration_msec').to_i > 0 then event.get('duration_msec').to_i / 1000000 else 0 end)
                        event.set('duration_minutes', if event.get('duration_msec').to_i > 0 then event.get('duration_msec').to_i / 60000000 else 0 end)
                        "

                        }
         }}

Эта настройка filter в Logstash выполняет разбор и обработку логов 1С, помеченных тегом onec. Рассмотрим по порядку:

1. Секция if проверяет наличие тега onec.
2. Далее идет разбор полей лога 1С при помощи grok и регулярных выражений. Извлекаются такие поля как duration_msec, event, nesting_level и многие другие.
3. Затем дата и время извлекаются в отдельные поля, объединяются в MyTime и конвертируются в timestamp @timestamp.
4. Поля DaH и MoH удаляются, так как более не нужны.
5. Руби код рассчитывает дополнительные поля duration_sec и duration_minutes на основе duration_msec.

output {
  if "onec" in [tags] {
    elasticsearch {
      hosts => ["http://es:9200"]
      index => "onec-%{+YYYY.MM.dd}"
    }
    stdout {
      codec => rubydebug
    }
  }
}

Эта настройка output в Logstash выполняет следующие действия:

1. Проверяет, есть ли в событии тег onec.
2. Если да, отправляет событие в Elasticsearch на узел es:9200.
3. Индекс в Elasticsearch имеет вид onec-YYYY.MM.dd, то есть данные будут разбиты по дням.
4. Также выводит событие в stdout с детализацией в формате rubydebug - это помогает отлаживать.
5. Если тега onec нет, то ничего делать не будет - событие игнорируется.

Grok - это инструмент в Logstash для парсинга и структурирования неструктурированных данных, таких как логи.

Grok использует регулярные выражения и шаблоны для извлечения данных из текста логов в именованные поля.

Например, есть такой паттерн для парсинга логов веб-сервера Nginx:

%{IPORHOST:clientip} - %{NGUSERNAME:ident} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer}) %{QS:agent}

Он извлекает такие поля как clientip, ident, timestamp, method, request, httpversion и т.д.

Пример работы:

Лог: 127.0.0.1 - john [09/Mar/2018:16:45:07 +0300] "GET /api/v2/songs HTTP/1.1" 200 786 "https://site.com/songs?genre=pop" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Результат парсинга:

clientip: 127.0.0.1 ident: john timestamp: 09/Mar/2018:16:45:07 +0300 method: GET request: /api/v2/songs httpversion: 1.1 response: 200 bytes: 786 referrer: https://site.com/songs?genre=pop agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Таким образом из "сырого" лога мы получаем структурированные данные для дальнейшего анализа.

 Grok - это инструмент в Logstash для парсинга и структурирования неструктурированных данных, таких как логи.

Grok использует регулярные выражения и шаблоны для извлечения данных из текста логов в именованные поля.

Например, есть такой паттерн для парсинга логов веб-сервера Nginx:

%{IPORHOST:clientip} - %{NGUSERNAME:ident} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer}) %{QS:agent}

Он извлекает такие поля как clientip, ident, timestamp, method, request, httpversion и т.д.

Пример работы:

Лог: 127.0.0.1 - john [09/Mar/2018:16:45:07 +0300] "GET /api/v2/songs HTTP/1.1" 200 786 "https://site.com/songs?genre=pop" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Результат парсинга:

clientip: 127.0.0.1 ident: john timestamp: 09/Mar/2018:16:45:07 +0300 method: GET request: /api/v2/songs httpversion: 1.1 response: 200 bytes: 786 referrer: https://site.com/songs?genre=pop agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Таким образом из "сырого" лога мы получаем структурированные данные для дальнейшего анализа.

 12 событий было

дальше можно сразу посмотреть что за приложение себя плохо чувствовало:

и т.д. дальше можно в один клик посмотреть в каких базах, по каким пользователям...

 Это график по сумме полей Durations_sec по пользователям.

Т.е. у одного пользователя было вызовов на 18 сек а у другого на 10 сек.

Обработка "FormCodeGenerator": Проект на GitHub 

Статьи:

• Часть 0. Быстрая кодогенерация программной доработки форм. Как я пришел к данной обработке. 
• Часть 1 (Режим работы "Палитра")
• Часть 2 (Режим работы "Режим сравнения форм") на примере ERP 2.5

Модуль "FormEditor"(РедакторФорм): Проект на GitHub 

Статьи:

• FormEditor - поставляемый модуль программного создания элементов форм

Модуль Kafka Adapter 1С (Confluent) : Проект на GitHub 

#KafkaЭтоПросто: Kafka Adapter 1С (Confluent) - отправляем сообщения

#KafkaЭтоПросто: Kafka Adapter 1С (Confluent) - читаем сообщения

 Модуль APM Adapter 1C : Проект на GitHub 

#APMЭтоПросто: APM Adapter 1C (elastic)