Скорее всего, многие из вас уже столкнулись с проблемой анализа логов журнала регистрации 1С высоконагруженных конфигураций и, скорее всего, задавались вопросом: «А какие есть варианты, кроме анализа штатными средствами 1С?». Если этот вопрос уже стоял перед вами, то надеюсь, что эта статья поможет вам в выборе альтернативы.
Небольшие извинения прежде, чем мы начнем
Прошло уже больше двух месяцев с момента опубликования последней статьи, где мы обещали продолжение темы мониторинга. Конечно, можно найти множество оправданий, почему мы до сих пор так и не опубликовали обещанное, но я этого делать не буду, так как мы предполагаем, а Бог располагает. Поэтому прошу понять и простить 😊.
Постановка проблемы и формулировка задачи
Как я писал в предыдущей статье, в современном мире ИТ просто хорошо работать недостаточно, нужно уметь продавать свои решения, подходы, результаты. Нужно менять парадигму восприятия ИТ продуктов, да и самого ИТ бизнесом. А что является лучшим решением, как не представить реальные показатели работы информационных систем (ИС) компании в виде красивых картинок? Правильно. BI борды, где каждый желающий в реальном времени может посмотреть, что происходит с той или иной ИС, и в случае необходимости получить детализацию нужного показателя.
Именно поэтому мы продолжаем внедрять у себя комплексную систему мониторинга ИТ продуктов, включая инфраструктуру, на которой все это крутится. На основании этой системы мониторинга мы визуализируем метрики, которые показывают качество конечного программного продукта и убеждаем бизнес, что эти показатели являются бизнес-показателями. Например, количество ошибок, генерируемое системой в единицу времени - это одна из ключевых бизнес-метрик, характеризующая качество программного решения.
В этой статье мы затронем вопрос анализа ошибок, регистрируемых в журнале регистрации 1С.
Наша цель понять какие модули в 1С генерируют нам наибольшее количество ошибок, чтобы менеджмент смог на ранних этапах увидеть проблемы и смог корректно приоритизировать задачи по исправлению этих ошибок.
Что не так со штатными средствами 1С?
Мы все знаем, что анализ логов журнала регистрации штатными средствами 1С для высоконагруженных конфигураций 1С – это боль и страдания, а если нам нужно мониторить ошибки и проводить регулярную работу по их устранению, то эта задача становится просто недостижимой.
Более или менее нормальный анализ штатными средствами 1С возможен, только если мы имеем достаточно большую периодичность хранения логов. Например, месяц или в худшем случае неделя. Но тут есть минимум три проблемы:
- Чем больше периодичность, тем больше шанс получить «утечку памяти» при чтении данных из файла логов. Хотя, конечно, словосочетание «утечка памяти» здесь может быть и не к месту, но наши пользователи очень любят открывать ЖР в рабочее время и выполнять свои аналитические дела. С учетом того, что у нас была месячная периодичность файлов логов, а при открытии наш дорогой windows подтягивает весь этот файл в память, то мы попадали в ситуацию, когда память неожиданно заканчивалась на сервере. Поэтому мы реализовали запись логов с периодичностью в час, что сразу привело к невозможности проведения полноценного анализа ЖР, но решило проблему с памятью.
- Чем больше периодичность, тем больше данных в файле, и тем медленнее выбираются эти данные.
- Штатными средствами мы так и не решаем проблему с понятной бизнесу визуализацией данных в реальном времени.
Все новое - хорошо забытое старое
Мы не стали изобретать велосипед и воспользовались наработками Юрия Пермитина, о которых он рассказывал еще в 20 году в своей статье Работа с журналом регистрации. Выходим за границы платформы.
Описанные в статье наработки позволяют в реальном времени загружать данные из логов журнала регистрации 1С в различные базы данных. Так как мы используем MS SQL в качестве СУБД для 1С и у нас уже есть лицензии и люди, обслуживающие данный тип СУБД, то мы приняли решение использовать существующий стек и загружать логи в СУБД MS SQL.
Фактически решение из себя представляет консольную утилиту, которая читает данные из текстовых логов ЖР 1С и пишет их в БД SQL. Утилита умеет догружать данные для этого в БД есть таблица LogFiles в которую пишется последний записанный лог файл. В следующий раз загрузка начнется с этого файла:
Ниже немного расскажу о ключевых таблицах и их назначении. Так как я нигде не нашел информацию о назначениях таблиц, то пришлось разбираться самому, поэтому сильно не пинайте, если где-то я понял что-то неправильно.
RowsData - все основные данные пишутся в эту таблицу. Структура таблицы достаточно понятная и имеет практически все необходимые данные для проведения анализа.
Applications – это сервис или приложение, где произошла ошибка:
Computers – здесь находятся имена всех клиентских компьютеров, с которых произошла ошибка, записанная в ЖР 1С
Events – здесь находятся все имена логируемых событий 1С
InformationSystems – здесь хранится имя системы которой принадлежит ЖР 1С
LogFiles – про него я уже упоминал выше.
Metadata – здесь хранятся имена метаданных, при работе с которыми произошла ошибка:
Severities – серьезность ошибки, точнее слово «ошибка» я использую в контексте всего что логируется в ЖР, но в реальности там следующая разбивка:
Users – в таблице хранятся все пользователи и их UID-ы, при работе которых произошла ошибка
WorkServers – это имена серверов, с которыми работает текущий сервер 1С. Если у вас сбалансированный кластер, состоящий из нескольких нод, то в таблице будут все эти ноды.
Есть еще две таблицы ErrorsMetricByHour и ErrorsMetricByWeek, в которых, как я понял, агрегируются ошибки по часам и неделям, но я пытался сравнить расчетные данные, полученные из таблицы RowsData с данными из этих таблиц, и не получил равенство, поэтому я не использую эти агрегированные таблицы для свои целей.
И, к слову сказать, есть еще view vw_EventLog, представляющая из себя такой огромный join, но забегая вперед скажу, что с учетом нашего объема данных вариант оказался для нас нерабочим.
Отсюда мы брали последние версии исходников от автора:
https://github.com/YPermitin/YY.EventLogExportAssistant
https://github.com/YPermitin/YY.EventLogReaderAssistant
А дальше дело техники
После того как мы получили весь набор логов в одной таблице (RowsData), мы подключили БД с логами (EventLog) к нашей BI Superset. Почему мы выбрали Superset, мы уже писали в предыдущей статье. Здесь я дам чуть больше технических деталей.
Так как я не DevOps инженер, то не могу рассказать о процессе установки и настройки Superset-а, но я могу описать те вещи, с которыми мне удалось столкнуться самому.
Подключение БД
По умолчанию Superset не имеет драйвера для подключения MS SQL, и для того чтобы подключить MS SQL нашим DevOps инженерам пришлось еще поискать как это сделать, но по итогу мы получили такую возможность:
Строка подключения к БД выглядит следующим образом:
mssql+pymssql://имя пользователя SQL:пароль@имя сервера SQL/EventLog(это собственно имя базы)
Создание Dataset
Фактически мы создаем набор данных, из которого потом сможем построить Charts, а те в свою очередь можно будет добавить на Dashboard.
Dataset можно создавать двумя путям:
- Если вы будете делать запрос к одной таблице и вам не нужны join-ы, то вы просто нажимаете большую кнопку «+ DATASET», заполняете все указанные поля и радуетесь жизни.
- Обычно жизнь сложнее и нужны данные из нескольких таблиц. В этом случае Dataset нужно создавать из механизма SQL Lab. Так как данных может быть много и запрос может выполняться долго, то я рекомендую сначала сделать запрос в Management Studio. В случае необходимости добавить индексы, а только потом создавать Dataset. И важный момент: запрос должен выбирать максимальное количество данных, без сложных группировок и условий. Условия и группировки вы сможете сделать в Chart-ах. Если вы будете использовать это правило, то на базе одного Dataset-а вы сможете строить различные разрезы. Ниже пример настроек Dataset-а по всем ошибкам в ЖР 1С:
Создание Chart
На базе созданного ранее набора данных (Dataset) можно делать различную визуализацию при помощи Chart-ов. Например, на рисунке ниже показано, что на базе описанного выше dataset-а было сделано три chart-а с разной визуализацией:
А это как выглядит интерфейс редактирования конкретного chart-а:
Создание Dashbord
Dashbord-ы создаются по нажатию большой кнопки «+DASHBORD». Добавление Chart-ов на конкретный dashboard происходит в момент сохранения chart-а. И по итогу вы можете получить «красивенький» dashboard, который сможете презентовать всем, кому нужно:
Ну да, есть и подводные камни
Первая проблема, с которой мы столкнулись, это периодическое падение консольной утилиты по различным причинам. Это могут быть как ошибки подключения к БД, так и различные ошибки данных. Некоторые ошибки просто пропускались после перезапуска утилиты, а некоторые пришлось исправлять.
Например, была ошибка поиска данных в словаре. Оказалось, что словарь в c# регистрозависимый, и у нас появилась ситуация, когда значение условия из БД не совпадало со значением в словаре.
Вторая ошибка, которую мы еще не исправили – это то, что в системе может появиться пользователь с одним именем, но при этом иметь два разных UID-а и по итогу приложение падает с ошибкой, так как не может получить id пользователя. Пока я не разобрался, как починить.
В связи с тем, что проект https://github.com/YPermitin/YY.EventLogExportAssistant использует библиотеки из проекта https://github.com/YPermitin/YY.EventLogReaderAssistant мне пришлось объединить эти проекты, чтобы иметь возможность полноценно пользоваться отладчиком.
Объединенный вариант с исправленной ошибкой лежит в моём репозитории на github: https://github.com/ValentinKozlov/YY.EventLogExportAssistant
Я в начале пути по изучению c# и возможно наделал всяких непотребств, но до других вариантов решения я пока не дошел.
Вторая большая проблема – это объем БД и соответственно скорость выполнения запросов. Мы закачали данные с 1 января 2021 года и на начало апреля 2022 года наша база имеет размер 1,1 Тб, с количеством строк в таблице RowsData более 1 млрд. Это накладывает огромные накладные расходы как на обслуживание такой базы, так и на скорость выполнения запросов, поэтому пока приходится тюнить индексами каждый разрабатываемый запрос и внимательно следить за тем, чтобы запросы выполнялись за адекватное время.
Что дальше
Для решения первой проблемы мы привлекли профессиональных разработчиков c#, которые помогут нам превратить консольную утилиту в полноценный enterprise service с возможностью автоматического перезапуска, безопасного хранения паролей и логированием ошибок для дальнейшего их мониторинга при помощи Prometheus + Grafana.
Для решения второй проблемы у нас уже есть план по уменьшению базы:
- Мы сделали скрипт, которым будем удалять данные старше 6 месяцев, не считая текущий месяц. Скрипт и его тестовый вариант можно найти в моём репозитории в папке Scripts (TableClearing_RowsData_DB_EnentLog.sql и TableClearing_RowsData_DB_EnentLog_Test.sql)
- Также мы планируем применить к таблице RowsData сжатие. На основании статьи MSDN для таблицы RowsData мы выбрали тип сжатия - page compression. В первую очередь это связанно с тем, что данные в таблице не обновляются, а только добавляются, а чтений у нас будет достаточно много.
Заключение
Мне показалось, что получилось как-то много букАв, но сократить текст без потери смысла не получилось. Вероятно, Чукча не писатель, Чукча читатель 😊. В любом случае, надеюсь, читать было интересно, и кто-то из вас смог почерпнуть полезную информацию.
Больше не буду обещать, что в ближайшее время напишу новую статью, но пока я собирался писать эту, я уже успел набросать 1С connector для хранилища S3 Minio на базе типовой БСП. Доработка не претендует на законченный вариант, так как там еще полно багов, да и тестирования полноценного не было, но взять в качестве прототипа для своих разработок уже можно. Кому интересно, можно взять здесь и потыкать: https://github.com/ValentinKozlov/1c-s3connector
