BigData LogManager для 1С


#41

@pumbaE, обычная обработка 1С для запуска из командной строки. Тестирую по OS X и Windows, предполагаю, что и под Linux будет работать, но пока не могу определенно сказать.


#42

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


#43

Репозиторий:

Оно все еще требует доработки, в текущем виде пригодно разве что - для ознакомления.
Важный момент, чтобы Kibana работала - ИспользованиеByteOrderMark.НеИспользовать

Приглашаю в issues для обсуждения :slight_smile:


#44

Если кто тестил обработку - мог заметить - самым узким местом была отправка запросов к ES. У меня это было 20000 за 600 сек.
Я подумал, что это непозволительно долго и переписал это дело на _bulk API (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html)

Теперь 70% времени тратится на строку:
СтрокаЗапрос = СтрокаЗапрос + "{ ""index"" : { ""_index"" : """ + ИмяИндекса + """, ""_type"" : """ + ИмяТипа + """ } }" + Символы.ПС;

Как думаете, есть способы оптимизации?


#45

Говорят, ТекстовыйДокумент складывает строки намного быстрее. Из-за использования какого-то другого буфера.


#46

Итак, что происходит при выполнении операции S=S+“Some Text”

Происходит т.н. ReAlloc (перевыделение памяти):
a) Выделяется область памяти размером = размер(S) + размер(“Some Text”)
b) В выделенную область копируется S
c) В выделенную область дописывается "Some Text"
d) Адрес дескриптора строки S устанавливается на новую область
e) Старая область памяти, использовавшаяся S освобождается


#47

Спасибо большое! Текстовый документ действительно ощутимо быстрее.
Теперь новые вводные :slight_smile: 150_000 записей не пролазят одним запросом, почему то. Еще разбираюсь с этим.


#48

Если там http запросы, может попробовать multipart через boundary?


#49

Получил забавную ситуацию:
После загрузки в ES ~5_000_000 записей на виртуалке под docker-machine закончилось свободное место в результате индекс за 1 месяц оказался разрушен с полной потерей данных :slight_smile: при этом сервер продолжал принимать запросы и отвечал на запись новых с кодом 200, как ни в чем не бывало.

То что 150_000 не пролазило решил разделением на порции по 50_000

Короче говоря, О сколько нам открытий чудных готовит просвященья дух. (с)

Замер производительности (запущен не с самого начала)


#50

Без тестов ? Без feature файлов ? Как так можно. Ну хоть бы заглушку создал для фич.


#51

Я с самым первым вопросом застрял “Mock в привязке к 1С” - чем сэмулировать ES?


#52

Докером, без хранения данных.

Контекст: 
  Дано: Вызвана команда docker up elk

Сценарий Выгрузка данных

#53

Хозяйке на заметку - самый быстрый способ потоковой записи текста - это

ЗаписьXML.ЗаписатьБезОбработки(ВашТекст);

быстрее ЗаписьТекста и уж тем более ТекстовогоДокумента.


#54

Добрый день.
Решаю задачу разбора логов ТЖ 1С и их анализа средствами ELK.
Архитектура следующая:
Сервер 1. На нем: Служба 1С, FileBeat.
Сервер 2. На нем: logstash, elasticsearch (with watcher plagin), kibana, membrane-service-proxy (вместо elastic Shield).

Принцип работы (beats+ELK).
FileBeat выступает в роли агента, при появлении новых данных (причем склеивает их используя multiline) отправляет пакет в logstash. Logstash преобразовывает данные в JSON и отправляет в elasticsearch. Kibana выступает в роли вьюшки. Membrane-service-proxy используется для авторизации к elasticsearch и Kibana.

При реализации этой схемы столкнулся со следующими проблемами:

  1. Лишний символ (0xEF 0xBB 0xBF)

Логи ТЖ (*.log) записываются в кодировке UTF-8. Как следствие в начало каждого файла добавляется ‘п»ї’ (0xEF 0xBB 0xBF). Подробнее W3 UTF-8.
В filebeat.yml я указал encoding: utf-8, но проблема осталась.
Как следствие я теряю одно событие в каждом новом файле лога.

Пример того что filebeat отправляет в logstash:

{
  "@timestamp": "2016-05-12T12:06:53.593Z",
  "beat": {
    "hostname": " 1CAPP-07",
    "name": "1CAPP-07"
  },
  "count": 1,
  "fields": null,
  "input_type": "log",
  "message": "**?**06:45.0409-229386,SDBL,3,process=rphost,p:processName=PP
,t:clientID=919,t:applicationName=1CV8,t:computerName=TERM4,t:connectID=9603,
SessionID=6119,Usr=...,Trans=0,Func=Transaction,Func=CommitTransa
ction",
  "offset": 5691,
  "source": "T:\\tehjourn\\rphost_8876\\16051215.log",
  "type": "tj1s"
}
  1. Преобразование даты события в UTC

Получая данные в logstash и разбирая их я получаю две даты: @timestamp (дата и время обработки логов из beats) и timestamp (дата события из ТЖ – собирается из 16051215.log и ?06:45.0409).
Обеда даты имеют формат "YYYY-MM-dd HH:mm:ss.SSS Z (mutate {add_field => { “timestamp” => “%{year}-%{month}-%{day}T%{hour}:%{minute}:%{second}Z” }})
@timestamp – если я правильно понимаю в UTC, а timestamp в локальном формате.
Как timestamp перевести в UTC?

Помогите пожалуйста решить эти проблемы.


#55

Этот “лишний символ” - byte offset mark. пересохраните (рядом) в файл без BOM, или вырежьте его кодом


#56

Я понимаю.

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

вырежьте его кодом
в filebeat это можно сделать? или наверное только в logstash…


#57

оффтопик - программа вебинара тут http://infostart.ru/webinars/524404/


#58

Сам спросил и по классике жанра сам отвечу.

п.1
не нашел простого пути избавиться от BOM средствами filebeat, отрезал его logstash’ом.
mutate {gsub => ["message", "^[\W]{1,}", ""]}

п.2
(mutate {add_field => { "timestamp" => "%{year}-%{month}-%{day}T%{hour}:%{minute}:%{second}Z"}})
не внимательно ознакомился с ISO 8601.
вместо Z (признак времени по UTC) необходимо указать часовой пояс +03:00 ("%{year}-%{month}-%{day}T%{hour}:%{minute}:%{second}+03:00")
Вместо часового пояса +03:00 можно так же указать Europe/Moscow. подробнее тут


#59

Провел свой микро тест.
10 раз по 10 000 строк. 4 метода. Результат в табличке. Победителем оказался ЗаписьТекста


#60

Всем привет!
Помогите пожалуйста разобраться в ошибке.
Я использую PaketBeat (Version: 1.2.3) для анализа трафика и записи в elasticsearch.

Регулярно получаю следующую ошибку:
2016/08/08 15:29:09.853618 decoder.go:97: INFO packet decode failed with: Invali d (too small) IP length (0 < 20) 2016/08/08 15:29:12.853618 http.go:421: WARN Response from unknown transaction. Ingoring.

Пакеты c подобной ошибкой PaketBeat соответственно не разбирает.

PaketBeat запускаю с ключами ..\packetbeat.exe -e -dump c:\temp\trace2.pcap.

В trace2.pcap (https://drive.google.com/open?id=0B_459K_hkeaRb2VhNjhZOVhsWEE)
визуально проблем нет, все отображается корректно.

packetbeat.yml:

`
############################# Sniffer #########################################
interfaces:
device: 0

############################# Protocols #######################################
protocols:
http:

ports: [2001]

send_all_headers: true

include_body_for: ["application/json","text/html"]

send_request: true

send_response: true

transaction_timeout: 2s

############################# Output ##########################################
output:
console:

pretty: true
`

Подскажите пожалуйста в чем может быть проблема и как можно ее решить?