search

akpaevj / OneSTools.EventLog

Библиотеки и готовые инструменты для чтения и экспорта журнала регистрации 1С в ClickHouse и ElasticSearch
MIT License
126 stars 45 forks source link

Первый файл лога #21

Closed 1rV1N-git closed 3 years ago

1rV1N-git commented 3 years ago

А по какому критерию он ищет первый файл лога. Lgp file (C:\Program Files\1cv8\srvinfo\reg_1541\%guid%\1Cv8Log\20210504000000.lgp) doesn't exist. The reading will be started from the first found file

У меня разбивка по дням стоит. Я к это к тому через сколько можно удалять файлы логов?

akpaevj commented 3 years ago

При запуске, если уже данные в индексе или таблице были, то осуществляется попытка считывания последнего обработанного файла с последней обработанной позиции. Иначе файлы в каталоге сортируются по дате создания и начинается их обработка

1rV1N-git commented 3 years ago

В том то и проблема что данные в индексе есть. перезапускаешь EventLogaManager и он хочет почему то файл за 4 число image

akpaevj commented 3 years ago 
var response = await _client.SearchAsync<EventLogItem>(sd => sd .Index($"{_eventLogItemsIndex}-*") .Sort(ss => ss.Descending(c => c.Id)) .Size(1) , cancellationToken);

Индекс сортируется по убыванию Id и берётся первая запись. Предлагаю посмотреть что возвращает такой запрос

1rV1N-git commented 3 years ago

Сделал запрос. Ага. Запись от 4 числа имеет очень дольшой номер (48 876 838) "id" при том что сейчас новые логи прилетают с айдишниками около 1 695 596. Скорее всего это из за ошибки которая была здесь либо еще какой то. Он id инкрементит, а данные не отправляет, Я замечал поведедие что EventLogaManager что то делает по загрузке процесора, а данные новые не отправляет.

P. S А Id обнуляется при создании нового индекса в начале нового периода(в данном случаем месяца) ?

akpaevj commented 3 years ago

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

1rV1N-git commented 3 years ago

осортировал по дате записи в индексе. первая запись вот такая

        "_source" : {
          "id" : 44998247,
          "fileName" : "20210501000000.lgp",
          "endPosition" : 17704782,
          "lgfEndPosition" : 153065,
          "dateTime" : "2021-05-01T00:00:00Z",

По поводу проца это понятно что в обычное время он что то потребляет около 2-5% В тот момент было около 20%

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

akpaevj commented 3 years ago

Могу предположить что что-то было считано до этой записи и удалено, потому что endPosition слишком большой для данных одного события (17 с копейками мегабайт).

akpaevj commented 3 years ago

По поводу загрузки в 20% - надо смотреть лог с дебаг уровнем, иначе тяжело понять что там творится внутри

1rV1N-git commented 3 years ago

Там не первая запись оказывается. С датой "dateTime" : "2021-05-01T00:00:00Z" около 20 записей

1rV1N-git commented 3 years ago

По поводу загрузки в 20% - надо смотреть лог с дебаг уровнем, иначе тяжело понять что там творится внутри

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

akpaevj commented 3 years ago

Там не первая запись оказывается. С датой "dateTime" : "2021-05-01T00:00:00Z" около 20 записей

Такое может быть, детализация в журнале регистрации только до секунды

1rV1N-git commented 3 years ago

Там не первая запись оказывается. С датой "dateTime" : "2021-05-01T00:00:00Z" около 20 записей

Такое может быть, детализация в журнале регистрации только до секунды

просмотрел все записи в первую секунду, все с большим числом endPosition 177ххххх

akpaevj commented 3 years ago

Если это совсем новый индекс, то отсчёт однозначно должен был быть с 0. Начальный инкрементный номер устанавливается только при наличии записей в индексе. Хорошо бы посмотреть сырые данные логов, что там реально в файлах было. Некоторые типы событий ЖР пропускаются ридером, но вряд-ли их было настолько много, конечно.

1rV1N-git commented 3 years ago

Сырых данных уже нет вроде. Завра поищу. Это не новая база. Последняя запись в прошлом месяце была с айди 44998246. Я понял что айди увеличивается постоянно и не обнуляется. Мне пока не понятно что произошло 4 числа. Из за чего номерация сбилась.

Ок посмотрим что дальше будет. Большое спасибо!

akpaevj commented 3 years ago

Я, к сожалению, тоже не могу ответить так сразу. Нужно разбираться с исходными данными и логами самого приложения одновременно. Не за что)

JohnyDeath commented 1 year ago

Тоже нарвался на похожую проблему. Что было у меня:

  1. Сначала загрузил текущий ЖР, который хранятся в каталоге 1с с октября 2022 года
  2. Далее пошел в каталог, где лежат архивные ЖР и прогрузил в ту же базу журналы за 2021 и 2022 года
  3. Сейчас пытаюсь запустить менеджер, а он мне пишет такое: 
    2023-01-17 11:52:08.998 | Warning | OneSTools.EventLog.Exporter.Core.EventLogExporter[0]
Lgp file (C:\\Program Files\1cv8\srvinfo\reg_1541\50ca9f86-3a7e-47e7-bb8c-8fb6c2c66bd4\1Cv8Log\20220425000000.lgp) doesn't exist. The reading will be started from the first found file
2023-01-17 11:52:09.055 | Information | OneSTools.EventLog.Exporter.Core.EventLogExporter[0]
Reader started reading 20221001000000.lgp

    т.е. явно берет стартовую позицию неправильно. Нашел в коде вот такой запрос https://github.com/akpaevj/OneSTools.EventLog/blob/7eee3719b4d3ff8d9806d97422ba60a7e07a8ca4/OneSTools.EventLog.Exporter.Core/ClickHouse/ClickHouseStorage.cs#L43

Предлагаю переделать его на следующий:


SELECT
    FileName,
    EndPosition,
    LgfEndPosition,
    Id
FROM {TableName}
ORDER BY
    FileName DESC,
    EndPosition DESC
LIMIT 1

Показываю разницу на моих данных.

  1. Запрос, который сейчас отправляет экспортер в кликхауз: image

  2. Предлагаемый запрос: image

Но я бы тоже посмотрел в сторону того, чтобы позиции хранить в каталоге экспортера рядом с настройками и логом, а не в БД. Так было бы более надежно и предсказуемо. Также можно будет в случае чего и ручками поправить. Плюс сейчас указанные запросы в Кликхауз выполняются достаточно долго (около минуты). Что тоже немаловажно

JohnyDeath commented 1 year ago

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

SELECT
    FileName,
    EndPosition,
    LgfEndPosition,
    Id
FROM {TableName}
ORDER BY
    DateTime DESC,
    EndPosition DESC
LIMIT 1