Логи есть? А если найду!
Аналитики - они же разработчики бизнес-приложения - главные пользователи нашей low-code Платформы. ❣️
Мы заботимся об их душевном спокойствии и стараемся сделать работу с продуктом прозрачной и удобной.
Мы знаем как порой трудно разобраться почему упал запрос или цепочка вызовов не привела к ожидаемому результату.
Нам знакомо это чувство "засучивания рукавов", когда набираешь побольше воздуха и ныряешь в море строчек кода, в попытке найти причины сбоя 🕵️.
А причиной может быть что угодно: опечатка в коде json-схем, упавший сервис инфраструктуры или не верное поведение сервиса Платформы.
Хочется обнять наших пользователей, помочь сэкономить время на расследовании, обезопасить от "глупых опечаток", подсказать верное решение. А главное показать как данные перемещаются между сервисами и обогащаются в результате обработки.
Рассмотрим типовые проблемы, с которыми может столкнуться пользователь:
- ошибка кода json-схем
- устаревший код используемых функций
- не верное использование виджетов/хэлперов
- ошибка самой Платформы
Давайте сегодня поговорим про последний случай.
В любой непонятной ситуации... лети в Петербург cмотри в документацию и логи.
Над подробной пользовательской документацией мы еще работаем 😐...
... а вот логирование уже можно "пощупать" 🥳
При проблеме в браузере будет отображаться страница заглушка о 500 ошибке.
В DevTools можно посмотреть "хлебные крошки" - текст ошибки, с которого начать поиски причин.
Команда разработки хорошо поработала над логированием сервисов Платформы.
А DevOps для наших тестовых контуров настроили интеграцию с Kibana.
Сервисы Платформы публикуют сообщение с максимально возможной информацией о выполненном действии. Это сообщение проходит парсинг и доступно в Kibana в структуре название_элемента:значение.
Там вы прочтете захватывающую историю о цепочке выполнения кода, которая привела к текущему состоянию.
Стандартным шагом было бы перейти на страница просмотра логов (Discover), выбрать контур, выбрать период проведения работ и далее начать искать истину в куче сообщений.
Более продвинутые пользователи, могут использовать регулярные выражения или фильтры самой Kibana.
👉 найти все ошибки за выбранный период => в строке поиска ввести error
👉 найти все сообщений от сервиса => log.serviceName:api-proxy
👉 найти все сообщения с 404 статус кодом => log.ctx.res.status:404
👉 найти все ошибки, за исключением сообщений содержащих "Не найдено значение настройки LogomarkForPersonalAccount" => log.level:error and NOT "Не найдено значение настройки LogomarkForPersonalAccount"
Посмотреть другие правила фильтрации сообщений можно в официальной документации Kibana. 😉
Для менеджеров и релизных инженеров вероятно будет удобнее использовать стандартные фичи Kibana dashboard.
Доска расскажет о самочувствии бизнес-приложения по итогам выполненных работ и проверок.
Например, перед выпуском релиза с крохотной фичей запускается прогон автотестов регресса (UI).
Релизный инженер и QA проверяет доску контура и видят что в DevTools сыпался водопад ошибок и предупреждений. А запросы, фоном отправленные в смежные сервисы (для заполнения полей на форме), вернули ошибку. И автотесты этого не поймали.
Доска отобразит "невидимые" 👻 в БП ошибки, которые в перспективе могут привести к крупному сбою уже на "бою".
У нас готовы типовые шаблоны досок, которые можно копировать и дополнять или пере-использовать сами шаблоны.
📍В будущем релизе мы запланировали расширить сообщения, чтобы пользователи понимали суть ошибки и добавить логирование там где его не еще не было.
📎 Поделитесь своими кейсами поиска сообщений или "фишками" работы с Kibana.
Самые часто используемые будут включены в шаблон Kibana dashboard и могут быть использованы уже широким кругом!