Сегодня хочу рассказать вам несколько полезных историй про то как нам помог Elastic search в связке с Kibana.
Про сам Elastic рассказывать не буду, уже все давным давно описали и до меня. Все обычно говорят что это полезно, это классно. В то же время, очень мало кто рассказывает про практические ситуации: когда и как помог Elastic. Итак, начнем.
Время чтения: 4 мин.
Содержание
- История первая: о потерянном процессорном времени.
- История вторая: о снижении количества ошибок.
- История третья: о том что мы точно знаем когда не работали внешние сервисы поставщиков услуг.
- История четвертая: о редких ошибках поставщиков сервисов.
- Что дальше?
- Итоги
История первая: о потерянном процессорном времени.
Развернули мы, значит, Elastic search с Kibana и подумали на что можно натравить ее для начала. Выбрали базу-кролика, ей оказалась база для сервис-деска. Собрали статистику журнала регистрации. И меня смутил большой объем повторяющихся каждые 10 минут транзакций. Начал разбираться, оказалось что выполняется абсолютно ненужное регламентное задание, которое перезаписывает абсолютно ненужный реквизит в тысяче заявок каждые 10 минут! Оставим архитектуру решения на совести разработчиков этого программного продукта. Выключив регламент мы, хоть и немного, но снизили нагрузку на наши сервера. Слава Kibana!
На графике видно, что все еще остались массовые обработки, но это нужные транзакции. Ужасная архитектура этого ПО для сервис-деска, конечно…
История вторая: о снижении количества ошибок.
Дальше анализировать базу сервис-деска стало неинтересно: аномалий выявлено не было, выгрузка в Elastic работала хорошо и не нагружала базу. Настало время заняться серьезными делами и я натравил обработку выгрузки ЖР на нашу самую основную и рабочую базу.
Что мне было интересно изначально: статистика по количеству и видам ошибок, которые бывают у нас в программе, количество транзакций по пользователям, количество ошибок по пользователям и все вот это вот.
Увидев количество ошибок, я немного опешил, но, взяв себя в руки, начал разбираться. Без систематического анализа ЖР никто и никогда не знает о том что происходит в программе, на чем она спотыкается, о чем молчат пользователи. А так как ЖР анализировать стандартными средствами смерти подобно, то никто и никогда стандартными средствами этого не делает, кроме мазохистов, их в расчет не берём.
Итак, фильтр по ошибкам показал что ошибок много и самое приятное, что примерно 60% ошибок генерит один тип. Ошибка, которую ребята все никак не брались исправить, т.к. ну очень много нужно было переделывать. Переделали, снизили количество. Следующая массовая ошибка, переделали. Следующая массовая ошибка, переделали. Вот примерный график снижения ошибок. Почему ошибки ещё есть спросите вы? А про это история под номером три.
На графике динамика снижения количества ошибок в нашей системе.
История третья: о том что мы точно знаем когда не работали внешние сервисы поставщиков услуг.
Цель была минимизировать количество ошибок и своевременно реагировать на новые всплески. В результате, пришли к тому, что основной поток ошибок стали генерировать внешние поставщики услуг, когда их сервисы лежат.
Например, сервис проверки ИНН в типовой бухгалтерии или сервис одного известного оператора ЭДО. И есть ещё один классный цифровой продукт, который выключается как по расписанию в 20.30, как будто рубильник у них там кто-то дёргает. Прикольно, че. Только вот перфекционист во мне рыдает, когда я вижу огромное количество ошибок и хочу это все поправить, но не могу! Боль.
Вот график, на котором за один день 16.09.2024 выбраны все ошибки из журнала регистрации. Всего ошибок 602. Наша ошибка одного типа и всего 10 событий. Это успех.
История четвертая: о редких ошибках поставщиков сервисов.
Отправляли мы смски через один из сервисов. Все казалось нам хорошо, пока мы не начали анализировать журнал регистрации. Оказалось, что некоторые номера этот сервис не проглатывал и в тестовых условиях воспроизвести такое просто было невозможно. Самое прекрасное: после нескольких попыток этот сервис отключался на некоторое время. Ошибку нашли и заботливо исправили. Слава Kibana!
На графике видно блокировку при многократной отправке одинаковых неправильных запросов.
Что дальше?
Сейчас мониторинг происходит все же несистемно. Захожу я или мои ребята и смотрим как дела. Что мне хочется получить в итоге? Мониторинг, который не будет зависеть от человека. В этом мне поможет ElastAlert.
Каждый раз, когда количество определенного типа ошибок за определенное время пробивает дно потолок и начинается неприятный такой сквозняк, то наш ElastAlert будет самоотверженно создавать инцидент в системе сервис-деска и бравые программисты будут фиксить ошибки. Или даже когда будет наблюдаться тренд на рост количества ошибок, то тоже будет создан тикет на анализ проблемы.
Таким образом будет обеспечен системный мониторинг: ошибок станет меньше, пользователи станут счастливее.
И ещё одна идея: воспользоваться мощными возможностями Microsoft Power BI для более глубокого анализа журнала регистрации, но для этого нужно оплачивать сервис, а ROI всего этого пока непонятен.
И ещё одна идея: засунуть туда логи технологического журнала, ведь что там происходит мы узнаем только при анализе проблем производительности. А вдруг там есть что-то подобное первой истории?
Итоги
Резюмируя вышесказанное: Elastic search и Kibana действительно классные продукты и действительно помогают решать проблемы анализа журнала регистрации. Не только в теории, но и на практике.
Всем спасибо за внимание!
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Читая такие статьи, прямо хочется у вас работать…
(1) у нас есть открытые вакансии
у меня желание сделать подобное у себя 🙂
Опять статья из разряда «Смотрите, как я умею».
«Смотрите, какое вкусное пирожное! Я его вот так ем, и вот так, а вот тут я медленно слизываю с него этот восхитительный крем! Если у вас будут деньги — обязательно купите себе такое пирожное!»
О том, что существует ЭС и Кибана, вполне можно узнать из Википедии.
(4) Да, все так. Круто же умею?
(0) Все отлично описано!
+
(5) автор все правильно сделал, что поделился опытом. Откуда столько токсичности 🙂
(7)
А где здесь опыт? Здесь факт того, что ЭС и Кибана существуют и что автор круто умеет. Ну ок.
(8) Опыт в том, что был бы инструмент, а проблема всегда найдётся :))
Простите я ещё раз это напишу, но просто как бы косяки множатся:
1) ЖР в ElasticSearch зло! В общем случае это можно классифицировать как архитектурную ошибку. Elastic слишком не экономно обращается с дисковым пространством, диском, процессором. Что оправдано для поисковых задач, но не для хранения логов же
2) kibana как инструмент визуализации не самое лучшее решение. Grafana намного мощнее и стала уже стандартом де факто. При этом вы не будете привязаны к СУБД
(0) мне просто интересно, кто учит складывать логи в elastic? До сих пор… Откуда плчерпнули идею?
(10) 1. Лежит на отдельном слабеньким сервере, никаких проблем. Логи чистим периодически. Нет цели хранить их бесконечно. Цель: понять текущее состояние системы.
2. Спасибо, попробую Grafana.
(11) Инфостарт.
Подскажите какими средствами лучше пользоваться для сбора и анализа логов?
Для меня эластик это просто и быстро. Ещё не пожалел о своем выборе. Но места ест прилично, да.
(13) любая столбцовая СУБД. Vk и флант юзают кликхаус. Посчитайте сколько занимает жр у вас упакованеый в zip. А теперь сколько места в elastic. Для маленького жр эластик не нужен. И так будет быстро. А для большого надо сжимать данные
Вы молодцы, поздравляю с первым шагов в сторону оперативного мониторинга!
Возможно вам будет теперь интересно мое выступление про логирование на Инфостарт в 2018м, посмотрите его при возможности. И попробуйте Graylog! Он бесплатен, есть и дашборды и уведомления о наступлении определенных событий в логах.
(0) спасибо за обзор!
Вот этот абзац про стандартный ЖР — не про всех верно, и даже обидно за всех. Я вот к примеру, за последний месяц посмотрел в ЖР только ошибки (в нерабочее время делал, ночью) — увидел повторяющуюся ошибку обмена — не хватает прав на пару объектов. Прописал привилегированный режим при обмене, на некоторые объекты дал права. Ошибка ушла.
Многие алгоритмы заложены в конструкции Попытка Исключение, поэтому многие ошибки не замечаются в процессе работы пользователей.
Мое итоговое мнение, с помощью ЖР можно выявлять проблемы!
(4) странно как-то слышать от вас такое.
и как же узнать , что еще почитать в этом направлении? а что еще почитать из других направлений?
Я знаю, что я знаю …. пишем статьи на ИС
Я знаю, что я не знаю…. смотрим википедию
Я не знаю, что я не знаю… читаем статьи на ИС
Я не знаю, что я знаю… живем счастливо
(15) ссылку на видео никто не запрещает выложить… выкладывайте
(18)
А чем плохо добавить в этот великолепный материал ещё информации о том, как это устанавливается, настраивается, системные требования, интеграция с 1С, подводные камни и прочую полезную информацию? Чтобы здесь была не википедия для бедных, а реальная польза. Автор вначале статьи пишет «не буду писать про эластик, и так много написано». Всё правильно, и про эластик, и про кибану, и про прочие вещи много написано именно в контексте «о, а ещё вот такое бывает». Зачем тогда это здесь? Люди, которые дальше 1С (и инфостарта) носа не кажут, всё равно не будут это реализовывать. Те, которые кажут, и так найдут эту воду.
А так — есть ЭС. Ок. Знал ли я о нём? Да. У него есть плагины. Знал ли я об этом? Да. Есть автор, который вот как умеет классно! Супер. Что я вынес из этого материала? Ничего.
Всё это — моё личное мнение. Если вы считаете по-другому — без проблем. Для этого здесь и есть плюсы и минусы.
(17) Чтобы проблемы были видны в попытке, нужно делать запись в журнал регистрации. Так велят стандарты разработки 1С.
&НаСервере
Процедура ВыполнитьОперацию()
Попытка
// код, приводящий к вызову исключения
….
Исключение
// Запись события в журнал регистрации для системного администратора.
ЗаписьЖурналаРегистрации(НСтр(«ru = ‘Выполнение операции'»),
УровеньЖурналаРегистрации.Ошибка,,,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
ВызватьИсключение;
КонецПопытки;
КонецПроцедуры
(20)
Вот статьи про установку:
….
Ещё одну написать?)
У нас немного жесче. Раз в час прочёсывается ЖР по всем базам и автоматно создаются задачи в баг-трекере. Если ошибка уже была, то информация дописывается в ранее созданную задачу. Естественно настроены исключения по тем ошибкам, на которые мы не можем повлиять. И да, мы истребили все ошибки типа «значение не является значением объектного типа», «поле объекта не обнаружено» и т.п. И часто бывает так, что мы ошибку уже фиксим или уже закончили, а пользователи только начинают бомбить.
Очень полезная функциональность должен сказать. Когда внедрили, тоже немного офигели от того сколько у нас ошибок и как часто пользователи об них молча спотыкаются.
Ну и мы не вы#бывались 🙂 а сделали по простоте — средствами 1С.
(10) «Гни свою линию»… Comol, не надоело? И еще раз — выгруженный за год журнал в ELK утверждение о «Elastic слишком не экономно обращается с дисковым пространством» не подтверждает. Как вы мне заявили — «объемы не те». Ну так значит для необъемных инсталляций вполне себе решение.
Про Grafana — ну так опишите работающее решение… Вот про ELK люди постоянно рассказывают. А рассказов об альтернативах от вас нет.
(25) рассказ про альтернативу у меня есть. На инфостарте был даже на конференции.
Пррсто сожмите ЖР зипом и посмотрите сколько он будет весить. +- столько же он будет весить в кликхаусе… Сравните с тем сколько он у вас весит в ELK. Если цифра не смущает — юзайте дальше ELK. Нормальное для вас решение… Просто не стоило с ним особо заморачиваться. Я пишу для того чтобы остановить эти рассказы. Один хм… кто то придумал остальные повторили и «а у нас так заведено» дальше