ELK. Время изумительных историй!

31.10.19

База данных - Журнал регистрации

Всем привет! Сегодня хочу рассказать вам несколько полезных историй про то как нам помог Elastic search в связке с Kibana. Про сам Elastic рассказывать не буду, уже все давным давно описали и до меня. Все обычно говорят что это полезно, это классно. В то же время, очень мало кто рассказывает про практические ситуации: когда и как помог Elastic. Итак, начнем.

Время чтения: 4 мин.

Содержание

  • История первая: о потерянном процессорном времени.
  • История вторая: о снижении количества ошибок.
  • История третья: о том что мы точно знаем когда не работали внешние сервисы поставщиков услуг.
  • История четвертая: о редких ошибках поставщиков сервисов.
  • Что дальше?
  • Итоги

История первая: о потерянном процессорном времени.

Развернули мы, значит, Elastic search с Kibana и подумали на что можно натравить ее для начала. Выбрали базу-кролика, ей оказалась база для сервис-деска. Собрали статистику журнала регистрации. И меня смутил большой объем повторяющихся каждые 10 минут транзакций. Начал разбираться, оказалось что выполняется абсолютно ненужное регламентное задание, которое перезаписывает абсолютно ненужный реквизит в тысяче заявок каждые 10 минут! Оставим архитектуру решения на совести разработчиков этого программного продукта. Выключив регламент мы, хоть и немного, но снизили нагрузку на наши сервера. Слава Kibana!

На графике видно, что все еще остались массовые обработки, но это нужные транзакции. Ужасная архитектура этого ПО для сервис-деска, конечно…

История вторая: о снижении количества ошибок.

Дальше анализировать базу сервис-деска стало неинтересно: аномалий выявлено не было, выгрузка в Elastic работала хорошо и не нагружала базу. Настало время заняться серьезными делами и я натравил обработку выгрузки ЖР на нашу самую основную и рабочую базу.
Что мне было интересно изначально: статистика по количеству и видам ошибок, которые бывают у нас в программе, количество транзакций по пользователям, количество ошибок по пользователям и все вот это вот.
Увидев количество ошибок, я немного опешил, но, взяв себя в руки, начал разбираться. Без систематического анализа ЖР никто и никогда не знает о том что происходит в программе, на чем она спотыкается, о чем молчат пользователи. А так как ЖР анализировать стандартными средствами смерти подобно, то никто и никогда стандартными средствами этого не делает, кроме мазохистов, их в расчет не берём.

Итак, фильтр по ошибкам показал что ошибок много и самое приятное, что примерно 60% ошибок генерит один тип. Ошибка, которую ребята все никак не брались исправить, т.к. ну очень много нужно было переделывать. Переделали, снизили количество. Следующая массовая ошибка, переделали. Следующая массовая ошибка, переделали. Вот примерный график снижения ошибок. Почему ошибки ещё есть спросите вы? А про это история под номером три.

На графике динамика снижения количества ошибок в нашей системе.

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


Цель была минимизировать количество ошибок и своевременно реагировать на новые всплески. В результате, пришли к тому, что основной поток ошибок стали генерировать внешние поставщики услуг, когда их сервисы лежат.
Например, сервис проверки ИНН в типовой бухгалтерии или сервис одного известного оператора ЭДО. И есть ещё один классный цифровой продукт, который выключается как по расписанию в 20.30, как будто рубильник у них там кто-то дёргает. Прикольно, че. Только вот перфекционист во мне рыдает, когда я вижу огромное количество ошибок и хочу это все поправить, но не могу! Боль.

Вот график, на котором за один день 16.09.2019 выбраны все ошибки из журнала регистрации. Всего ошибок 602. Наша ошибка одного типа и всего 10 событий. Это успех.

История четвертая: о редких ошибках поставщиков сервисов.

Отправляли мы смски через один из сервисов. Все казалось нам хорошо, пока мы не начали анализировать журнал регистрации. Оказалось, что некоторые номера этот сервис не проглатывал и в тестовых условиях воспроизвести такое просто было невозможно. Самое прекрасное: после нескольких попыток этот сервис отключался на некоторое время. Ошибку нашли и заботливо исправили. Слава Kibana!

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

Что дальше?

Сейчас мониторинг происходит все же несистемно. Захожу я или мои ребята и смотрим как дела. Что мне хочется получить в итоге? Мониторинг, который не будет зависеть от человека. В этом мне поможет ElastAlert.

Каждый раз, когда количество определенного типа ошибок за определенное время пробивает дно потолок и начинается неприятный такой сквозняк, то наш ElastAlert  будет самоотверженно создавать инцидент в системе сервис-деска и бравые программисты будут фиксить ошибки. Или даже когда будет наблюдаться тренд на рост количества ошибок, то тоже будет создан тикет на анализ проблемы.

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

И ещё одна идея: воспользоваться мощными возможностями Microsoft Power BI для более глубокого анализа журнала регистрации, но для этого нужно оплачивать сервис, а ROI всего этого пока непонятен.

И ещё одна идея: засунуть туда логи технологического журнала, ведь что там происходит мы узнаем только при анализе проблем производительности. А вдруг там есть что-то подобное первой истории?

Итоги

Резюмируя вышесказанное: Elastic search и Kibana действительно классные продукты и действительно помогают решать проблемы анализа журнала регистрации. Не только в теории, но и на практике.

Всем спасибо за внимание!

ELK Elastic Kibana Мониторинг Журнал Регистрации ЖР

См. также

LogManager - Внешний журнал регистрации в SQL

Журнал регистрации Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Журнал регистрации платформы 1С в SQL. Общая база хранения всех журналов. Через com-подключение регламентным заданием периодически догружает журналы регистраций из рабочих баз. Предоставляет настраиваемый доступ к журналам по правам подразделений. Формирует отчеты по пользователям и данным.

10000 руб.

23.05.2014    55416    52    16    

47

Версионирование справочников, документов и регистров сведений на SQL-сервере

Журнал регистрации Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

История изменений реквизитов и табличных частей справочников, документов, независимых регистров сведений, возможность отката изменения, восстановление удаленных объектов, сбор статистики использования базы 1С. Альтернативный журнал регистрации.

22800 руб.

22.02.2018    35117    58    53    

55

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

19200 руб.

15.05.2017    42470    10    24    

38

Мониторинг баз и серверов 1С

Журнал регистрации Мониторинг Платформа 1С v8.3 Платные (руб)

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

9000 руб.

28.08.2019    30838    14    21    

65

Версионирование объектов для Альфа-авто, ред 4 и 5.

Оптовая торговля Розничная торговля Журнал регистрации Платформа 1С v8.3 Конфигурации 1cv8 Автомобили, автосервисы Управленческий учет Платные (руб)

Подсистема версионирования объектов для конфигураций Рарус: Альфа-авто на базе типовой подсистемы от 1С. Позволяет хранить историю изменений документов и справочников, кто, что, когда и какие данные изменял, а так же вернуться к предыдущим версиям объекта.

4800 руб.

03.09.2016    42215    32    24    

36

Богатый редактор картинок, хранимых в базе, с возможностью РИСОВАНИЯ. Редактор внешних файлов картинок. Объект, расширяющий возможности работы с картинками из встроенного языка (Три в одном) + Обработка «Стандартизация картинок»

Работа с интерфейсом Рабочее место Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Обработка предназначена для редактирования картинок в режиме «Предприятие», с возможностью РИСОВАТЬ на них. Поддерживается работа как в обычных формах (толстый клиент) так и на управляемых формах (тонкий клиент). Обработка позволяет редактировать как картинки, хранимые в базе, так и графические файлы с диска на файловой системе. Помимо базовых функций (изменение размеров, преобразование формата, обрезание картинки, повороты и т.п.) – редактор имеет богатый набор инструментов для рисования. Доступна функция вставки изображения из буфера обмена. Также обработка может быть использована из встроенного языка как объект для редактирования картинок. Объект может быть использован: на стороне клиента, на стороне сервера, из внешнего соединения. Данная обработка будет особенно полезна тем, кто вносит картинки в базу (изображения номенклатуры, фотографии физических лиц и т.п.). Функционал реализуется с использованием JavaScript и бесплатного ПО ImageMagick (без использования внешних компонент).

6000 руб.

16.01.2015    61707    43    59    

80

Уведомления на почту по событиям журнала регистрации на email и в Telegram (для УНФ, УТ 11, БП 3.0, ЗУП 3.0, ERP)

Мессенджеры и боты Журнал регистрации Мониторинг Email рассылки Платформа 1С v8.3 Управляемые формы 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Платные (руб)

Рассылка уведомлений о событиях журнала регистрации на электронную почту и в Телеграмм. Программа позволяет анализировать журнал регистрации по заданным критериям, находить в нём интересующие события, и отправлять уведомления об этих событиях на электронную почту (одного или нескольких получателей) или в телеграмм. Может работать и как внешняя обработка, и как регламентное задание. Для УНФ, УТ 11, БП 3.0, ЗУП 3.0, ERP.

10800 руб.

18.06.2017    32257    3    2    

15

[Расширения] Динамическое управление видимостью и доступностью элементов форм (УФ) (8.3.6+)

Работа с интерфейсом Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Механизм «Динамическое управление доступом к элементам форм объектов 1С8» предназначен для обеспечения возможности оперативного управления видимостью и доступностью элементов форм документов и справочников продуктов фирмы «1С» «1С:Предприятие 8». Решение универсальное, встраивается в любую конфигурацию с минимальными доработками, что позволяет без проблем обновлять типовые решения.

5000 руб.

14.01.2016    54320    16    21    

42
Отзывы
16. leemuar 01.11.19 19:59 Сейчас в теме
(13) продолжайте пользоваться Эластиком. Олег рассказывает про подходы высоконагруженных систем, для вас сейчас это не актуально. КОгда станет актуально - вы сами придете к нужному решению.
Эластик дает высокую скорость поиска, но занимает много места на диске. В крупных системах обычно есть требование хранить все логи бесконечно долго, поэтому для длительного _хранения_ логов Эластик подходит плохо. Но для быстрого поиска по текущим логам, за пару дней-недель - вполне!

Часто встречаемая практика - логи писать сразу в 2 системы: в систему долгосрочного хранения, где оптимизировано занимаемое место, и в систему быстрого поиска, где поиск быстрый и работают алерты, но информация хранится только за последние n дней
EliasShy; user1174805; comol; DonAlPatino; slozhenikin_com; RustIG; +6 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dock 44 31.10.19 19:45 Сейчас в теме
Читая такие статьи, прямо хочется у вас работать...
2. slozhenikin_com 302 31.10.19 20:29 Сейчас в теме
3. ВикторП 342 01.11.19 10:05 Сейчас в теме
у меня желание сделать подобное у себя :)
YPermitin; +1 Ответить
4. for_sale 970 01.11.19 10:29 Сейчас в теме
Опять статья из разряда "Смотрите, как я умею".

"Смотрите, какое вкусное пирожное! Я его вот так ем, и вот так, а вот тут я медленно слизываю с него этот восхитительный крем! Если у вас будут деньги - обязательно купите себе такое пирожное!"

О том, что существует ЭС и Кибана, вполне можно узнать из Википедии.
azhilichev; ImHunter; +2 1 Ответить
5. slozhenikin_com 302 01.11.19 10:36 Сейчас в теме
(4) Да, все так. Круто же умею?
EliasShy; user1174805; user843241; SoFluffy; RustIG; acanta; +6 Ответить
7. пользователь 01.11.19 11:21
(5) автор все правильно сделал, что поделился опытом. Откуда столько токсичности :)
user1174805; user843241; support; +3 Ответить
8. for_sale 970 01.11.19 11:38 Сейчас в теме
(7)
А где здесь опыт? Здесь факт того, что ЭС и Кибана существуют и что автор круто умеет. Ну ок.
9. genayo 01.11.19 11:49 Сейчас в теме
(8) Опыт в том, что был бы инструмент, а проблема всегда найдётся :))
18. RustIG 1301 02.11.19 06:14 Сейчас в теме
(4) странно как-то слышать от вас такое.
и как же узнать , что еще почитать в этом направлении? а что еще почитать из других направлений?

Я знаю, что я знаю .... пишем статьи на ИС
Я знаю, что я не знаю.... смотрим википедию
Я не знаю, что я не знаю... читаем статьи на ИС
Я не знаю, что я знаю... живем счастливо
20. for_sale 970 02.11.19 11:10 Сейчас в теме
(18)
А чем плохо добавить в этот великолепный материал ещё информации о том, как это устанавливается, настраивается, системные требования, интеграция с 1С, подводные камни и прочую полезную информацию? Чтобы здесь была не википедия для бедных, а реальная польза. Автор вначале статьи пишет "не буду писать про эластик, и так много написано". Всё правильно, и про эластик, и про кибану, и про прочие вещи много написано именно в контексте "о, а ещё вот такое бывает". Зачем тогда это здесь? Люди, которые дальше 1С (и инфостарта) носа не кажут, всё равно не будут это реализовывать. Те, которые кажут, и так найдут эту воду.

А так - есть ЭС. Ок. Знал ли я о нём? Да. У него есть плагины. Знал ли я об этом? Да. Есть автор, который вот как умеет классно! Супер. Что я вынес из этого материала? Ничего.

Всё это - моё личное мнение. Если вы считаете по-другому - без проблем. Для этого здесь и есть плюсы и минусы.
22. slozhenikin_com 302 02.11.19 15:10 Сейчас в теме
(20)
Вот статьи про установку:
https://infostart.ru/public/545895/
https://infostart.ru/public/1128327/
https://infostart.ru/public/1033418/
....

Ещё одну написать?)
EliasShy; gubanoff; RustIG; +3 Ответить
29. Symbiat 01.04.21 22:02 Сейчас в теме
(22) ни в одной из указанных статей нет ни слова об установке "с нуля", зато почерк такой же - автор пробежался по верхам, а кто понял - тот молодец
6. пользователь 01.11.19 10:48
(0) Все отлично описано!
+
10. comol 5046 01.11.19 14:10 Сейчас в теме
Простите я ещё раз это напишу, но просто как бы косяки множатся:

1) ЖР в ElasticSearch зло! В общем случае это можно классифицировать как архитектурную ошибку. Elastic слишком не экономно обращается с дисковым пространством, диском, процессором. Что оправдано для поисковых задач, но не для хранения логов же

2) kibana как инструмент визуализации не самое лучшее решение. Grafana намного мощнее и стала уже стандартом де факто. При этом вы не будете привязаны к СУБД
12. slozhenikin_com 302 01.11.19 14:45 Сейчас в теме
(10) 1. Лежит на отдельном слабеньким сервере, никаких проблем. Логи чистим периодически. Нет цели хранить их бесконечно. Цель: понять текущее состояние системы.
2. Спасибо, попробую Grafana.
25. DonAlPatino 176 13.11.19 16:21 Сейчас в теме
(10) "Гни свою линию"... Comol, не надоело? И еще раз - выгруженный за год журнал в ELK утверждение о "Elastic слишком не экономно обращается с дисковым пространством" не подтверждает. Как вы мне заявили - "объемы не те". Ну так значит для необъемных инсталляций вполне себе решение.
Про Grafana - ну так опишите работающее решение... Вот про ELK люди постоянно рассказывают. А рассказов об альтернативах от вас нет.
26. comol 5046 13.11.19 16:51 Сейчас в теме
(25) рассказ про альтернативу у меня есть. На инфостарте был даже на конференции.
Пррсто сожмите ЖР зипом и посмотрите сколько он будет весить. +- столько же он будет весить в кликхаусе... Сравните с тем сколько он у вас весит в ELK. Если цифра не смущает - юзайте дальше ELK. Нормальное для вас решение... Просто не стоило с ним особо заморачиваться. Я пишу для того чтобы остановить эти рассказы. Один хм... кто то придумал остальные повторили и "а у нас так заведено" дальше
11. comol 5046 01.11.19 14:11 Сейчас в теме
(0) мне просто интересно, кто учит складывать логи в elastic? До сих пор... Откуда плчерпнули идею?
13. slozhenikin_com 302 01.11.19 14:48 Сейчас в теме
(11) Инфостарт.
Подскажите какими средствами лучше пользоваться для сбора и анализа логов?

Для меня эластик это просто и быстро. Ещё не пожалел о своем выборе. Но места ест прилично, да.
14. comol 5046 01.11.19 14:57 Сейчас в теме
(13) любая столбцовая СУБД. Vk и флант юзают кликхаус. Посчитайте сколько занимает жр у вас упакованеый в zip. А теперь сколько места в elastic. Для маленького жр эластик не нужен. И так будет быстро. А для большого надо сжимать данные
slozhenikin_com; +1 Ответить
28. antonio_i 79 11.02.20 08:20 Сейчас в теме
(14) Дайте, пожалуйста, ссылку, как это настроить.
Где можно найти информацию по настройке сбора и хранения логов указанным вами способом?
16. leemuar 01.11.19 19:59 Сейчас в теме
(13) продолжайте пользоваться Эластиком. Олег рассказывает про подходы высоконагруженных систем, для вас сейчас это не актуально. КОгда станет актуально - вы сами придете к нужному решению.
Эластик дает высокую скорость поиска, но занимает много места на диске. В крупных системах обычно есть требование хранить все логи бесконечно долго, поэтому для длительного _хранения_ логов Эластик подходит плохо. Но для быстрого поиска по текущим логам, за пару дней-недель - вполне!

Часто встречаемая практика - логи писать сразу в 2 системы: в систему долгосрочного хранения, где оптимизировано занимаемое место, и в систему быстрого поиска, где поиск быстрый и работают алерты, но информация хранится только за последние n дней
EliasShy; user1174805; comol; DonAlPatino; slozhenikin_com; RustIG; +6 Ответить
15. leemuar 01.11.19 19:39 Сейчас в теме
Вы молодцы, поздравляю с первым шагов в сторону оперативного мониторинга!
Возможно вам будет теперь интересно мое выступление про логирование на Инфостарт в 2018м, посмотрите его при возможности. И попробуйте Graylog! Он бесплатен, есть и дашборды и уведомления о наступлении определенных событий в логах.
19. RustIG 1301 02.11.19 06:18 Сейчас в теме
(15) ссылку на видео никто не запрещает выложить... выкладывайте
17. RustIG 1301 02.11.19 06:04 Сейчас в теме
(0) спасибо за обзор!

Увидев количество ошибок, я немного опешил, но, взяв себя в руки, начал разбираться. Без систематического анализа ЖР никто и никогда не знает о том что происходит в программе, на чем она спотыкается, о чем молчат пользователи. А так как ЖР анализировать стандартными средствами смерти подобно, то никто и никогда стандартными средствами этого не делает, кроме мазохистов, их в расчет не берём.


Вот этот абзац про стандартный ЖР - не про всех верно, и даже обидно за всех. Я вот к примеру, за последний месяц посмотрел в ЖР только ошибки (в нерабочее время делал, ночью) - увидел повторяющуюся ошибку обмена - не хватает прав на пару объектов. Прописал привилегированный режим при обмене, на некоторые объекты дал права. Ошибка ушла.
Многие алгоритмы заложены в конструкции Попытка Исключение, поэтому многие ошибки не замечаются в процессе работы пользователей.
Мое итоговое мнение, с помощью ЖР можно выявлять проблемы!
21. slozhenikin_com 302 02.11.19 13:23 Сейчас в теме
(17) Чтобы проблемы были видны в попытке, нужно делать запись в журнал регистрации. Так велят стандарты разработки 1С.

https://its.1c.ru/db/v8std#content:499:hdoc

&НаСервере
Процедура ВыполнитьОперацию()
Попытка
// код, приводящий к вызову исключения
....
Исключение
// Запись события в журнал регистрации для системного администратора.
ЗаписьЖурналаРегистрации(НСтр("ru = 'Выполнение операции'"),
УровеньЖурналаРегистрации.Ошибка,,,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
ВызватьИсключение;
КонецПопытки;
КонецПроцедуры
i.kovtun; RustIG; +2 Ответить
23. Armando 1399 02.11.19 23:31 Сейчас в теме
У нас немного жесче. Раз в час прочёсывается ЖР по всем базам и автоматно создаются задачи в баг-трекере. Если ошибка уже была, то информация дописывается в ранее созданную задачу. Естественно настроены исключения по тем ошибкам, на которые мы не можем повлиять. И да, мы истребили все ошибки типа "значение не является значением объектного типа", "поле объекта не обнаружено" и т.п. И часто бывает так, что мы ошибку уже фиксим или уже закончили, а пользователи только начинают бомбить.
Очень полезная функциональность должен сказать. Когда внедрили, тоже немного офигели от того сколько у нас ошибок и как часто пользователи об них молча спотыкаются.
Ну и мы не вы#бывались :-) а сделали по простоте - средствами 1С.
24. пользователь 06.11.19 00:16
Сообщение было скрыто модератором.
...
27. user722762 30.12.19 14:23 Сейчас в теме
Добрый день! Подскажите, пожалуйста, как в реалиях ELK создать оповещение о появлении новой ошибки?
Оставьте свое сообщение