ym104432846
Вставьте ссылку на видео из Youtube, Rutube, VK видео
Задайте вопрос по видео
Что вас интересует?
00:00:00
Важность логирования:
  • 1. Обсуждалась важность наличия логов в приложениях любого размера (даже небольших)
  • 2. Поднимался вопрос увлекательности изучения приложения через логирование
  • 3. Не принимались конкретные решения или договоренности по данной теме
00:00:31
Использование логов для отслеживания ошибок:
  • 1. Для отслеживания проблем с добавлением брони предложено фиксировать ошибки в формате JSON, чтобы облегчить группировку и обработку большого количества одинаковых ошибок
  • 2. Рассматривается использование сервиса Sentry для мониторинга и анализа ошибок, включая просмотр стека вызовов и значений переменных на момент возникновения ошибки
  • 3. Обсуждается необходимость отправки уведомлений (алертов) о критичных ошибках через электронную почту, Telegram или Slack, с возможностью ограничения частоты отправляемых сообщений во избежание перегрузки каналов связи
00:07:02
Хранение и сбор логов:
  • 1. Разработан способ сбора логов из консоли в формате JSON, которые передаются в elasticsearch
  • 2. В elasticsearch логи индексируются для быстрого поиска и возможной визуализации
  • 3. Рассматривается использование кибаны для визуализации собранных логов
00:07:33
Визуализация логов и мониторинг ошибок:
  • 1. Рассматриваются инструменты кибан и графана для мониторинга и логирования ошибок и функций, важных для бизнеса
  • 2. Предлагается обязательная регистрация всех критичных функций и отслеживание ошибок, связанных с бизнес-логикой
  • 3. Необходимо обеспечить доступ к логам и мониторингу ошибок для разработчиков и менеджеров компании
0: Вот мы и дошли до темы логирования. Кому-то из вас может это показаться неинтересным, неприятным, но я постараюсь вас переубедить и показать, что это прикольно, классно и можно интересно изучать наше приложение через логи и обязательно
1: Естественно, логи в любом коммерческом, среднем большом приложении, да, даже в маленьком очень важно их иметь. Поехали. Зачем нужны логи. Понятное дело, что если мы хотим узнать, работает ли наша программа, правильно? Нам нужна какая
2: Информация, например, что пользователь зарегистрировался. И таким образом мы знаем, что пользователь может зарегистрироваться или там совершён платёж, или что ни 1 ошибки не высвечивается. Это значит, что, скорее всего, их нету. Либо мы плохо настроили отображение ошибок.
3: Это уже другой вопрос. Дальше, если случилась какая-то ошибка, и мы хотим, ну, срочно пофиксить, чтобы у нас приложение работало, чтобы мы не теряли деньги на этом, мы можем в логи помещать важную информацию о
4: Наших данных, какие они были на тот момент, почему там, например, в словарике не было какого-то ключа, откуда мы знаем. Но если мы поместим данные, то мы сможем как-то отследить, на каком этапе там этот ключ не был добавлен и так далее. Ну, понятное дело, мы можем находить
5: Слабые места оптимизировать код. Если у нас какие-то запросы, например, выполняются, там 2 3 секунды, а у нас таргет полторы секунды или секунда, значит где то что-то не так работает или при больших нагрузках у нас падает конкретный какой-то endpoint.
6: Заполняется очередь задач слишком сильно и так далее, что мы будем логировать 1 мы посмотрим, как работать с middle ware, что это такое, как обрабатываются запросы пользователя в фастапи и как мы можем с этим работать и вычислять.
7: Время обработки запроса. Далее мы, конечно, при старте приложения хотим видеть, что он успешно подключился ко всем нужным базам, ко всем нужным редисам и так далее, что соединения установлены, они поддерживаются и
8: И для примера да, можно, например, пинговать ту же самую там базу или redis там раз в 10:15 секунд, чтобы проверять, что все хорошо работает, и также мы будем использовать формат Логов json давайте посмотрим, у нас есть 2 типа Логов.
9: Можно сделать вот такой не удаётся добавить бронь в алтай да, при ошибке брони с 12 по 20 июня можно добавить бронь в формате json, например, вот так сообщение не удаётся добавить бронь, там location, дейт дром дей ту ну, здесь для примера 12 и 20.
10: Понятно, что там 12 июня 23 года будет указано или что-то подобное. В чем разница? Да, в том, что если у нас много таких ошибок, не удаётся добавить бронь, не удаётся добавить бронь там в алтай, Сыктывкар, в адлер, то если они у нас в формате вот так
11: Строки без разделения параметров локейшн дейт Фром дейту их очень сложно, их можно, но сложно группировать. Если у нас огромное количество ошибок 1000, мы хотим их группировать по конкретной ошибке.
12: Например, там ошибка добавления брони, ошибка регистрации пользователя мы не хотим, чтобы они все были как разные ошибки, и мы дальше посмотрим, что json форматом удобно работают многие технологии.
13: Собирание Логов и хранение их и дальше давайте посмотрим уровни логирования. Это важно знать, наверное, всем разработчикам. Давайте пробежимся по тем уровням, которые нам предлагает пайтон в разных языках, в разных программах они по разному отображаются, существуют, но тем не менее,
14: В пайтоне 1 дибаг используется обычно при разработке. Мы можем просто все в дибаг запихивать там все данные, которые мы хотим на каждый, через каждую строчку, чтобы проверять, что все хорошо работает и в продакшене он обычно не используется дальше.
15: Это информация о каком-то полезном действии, о каком-то подключении, например, к базе данных, что мы успешно подключились к базе. Это не debug, но и не ошибка. Как мы посмотрим, это промежуточный какой-то уровень, например, инфо, да, регистрация юзера, создание брони, ну вот.
16: Любые такие операции. Дальше ворнинг это предупреждение. Ничего, скорее всего, плохого не произошло, ошибки нет. Программа продолжает работать, но, например, куда-то наш скрипт завёл в такое условие, которое там должно редко выполняться и нам
17: Нужно смотреть там, правильно ли все обработалось, например, что это какой-то редкий краевой случай, да, он случился, правильно ли он был обработан, например. То есть для нас какое-то внимание нужно уделить этой ошибке или уделить, точнее, этому фрагменту кода. Далее эррар это
18: Серьёзная ошибка, которая нарушает работу программы, но программа продолжает работать, ну, как-то там с горем пополам, но она обрабатывает запросы. Например, у нас случилась ошибка. Мы не смогли зарегистрировать пользователя, и мы никак не обработали эту ошибку. То есть мы нигде её не залоги.
19: У нас просто случился эксепшен, который у нас, у нас нету там трай эксепт, и мы не обработали эту ошибку. Вот такое тоже бывает. И критикал. Это такая ошибка, которая является поводом встать в 3 ночи и начать что-то чинить, чтобы все к утру уже
20: Работала критичные ошибки, они, скорее всего, связаны с полным выходом программы из строя и невозможностью дальнейшей работы.
21: Как трёкать ошибки? Давайте посмотрим сначала не просто на все логи, а на ошибки. Мы будем пользоваться сервисом сентри. Давайте взглянем на обычную ошибку в пайтон. Вот, например, такой трейсбэк какой-то у нас есть словарик ордер и в нём есть
22: Lots. И нам высвечивается ошибка, что нету ключа лоттс. Откуда мы знаем, почему его нету? На каком этапе там случилась ошибка? Может, он удалился? Может он не добавился, что не так, какие ещё может, соседние переменные? Какие у них
23: Значение мы можем воспользоваться сервисом сентри и здесь в удобном формате наблюдать ошибки, да, вот здесь они сгруппированы, например, там ошибка декодирования джейсона, ошибка ключа, вот этот самый лоттс, который мы сейчас смотрели, и
24: Увидеть, что вот в этой строчке, да, случилась ошибка. И увидеть, какие у нас были на тот момент, например, лоты, и что с ними вообще было. Были ли такие ключи, как все у нас работает. И помимо этого сентри отдаёт ещё некоторые другие перемены.
25: Которые в этой функции, например, использовались. Мы посмотрим с вами на это, интегрировав в центре в наш проект. Ну, конечно же стоит посылать алерты, какие-то пятисотые ошибки, которые у нас просто все валится. Мы не знаем, что произошло на сервере какая-то
26: Ошибка. Лучше их куда-то отправлять. Тут же на почту, в телегу. Или, например, как я раньше делал. В slack. Очень удобно слать ошибки. Причём главное постараться не спамить сильно ошибками. Если она часто возникает, как-то там, 10, 20 секунд паузы выдерживать, если ошибка постоянно сыпется, чтоб
27: У вас ну не засыпало этими ошибками, также посмотрим на стек елк, мы сейчас только его обсудим, не будем применять, но вы должны о нём знать обязательно итак тут немножко не в порядке, у нас есть lock стэш.
28: Он собирает логи из нашей просто консоли вот у нас стд аут есть, мы в консоли что-то печатаем, какие-то логи, и он их собирает, причём в формате json дальше логстеш только собирает логи, он их не хранит, дальше они хранятся в эластик серч.
29: Возможно, известное вам название и elasticsearch хранит, индексирует эти логи, чтобы можно было по ним очень быстро искать. Можно было их визуализировать. И если мы хотим визуализировать. А скорее всего, мы хотим логи, то мы используем кибана. Это.
30: Довольно известный стек. Вы можете встретить его где-то в требованиях к вакансиям, и вы должны понимать примерно, ну что происходит, что это за стек, как он нам помогает? Да, например, вот так могут отображаться ошибки в кибане. Такой дашбордик, да, вы также
31: Могли слышать про графану графана тоже используется, но она не относится, например, к этому стеку. Так, мы посмотрели на логгирование. Это очень важная тема. Мы точно 100% должны отслеживать большую часть ошибок, логировать их и затем иметь возможность
32: Посмотреть на них, чтобы и разработчики могли смотреть на них, и какие-то менеджеры, и все, кому не безразличен бизнес, и то, чтобы компания росла. Очень важно логировать все функции, все критичные функции, которые
33: Отвечают за бизнес логику. Когда мы хотим зарегистрировать клиента. Если что-то пошло не так, мы не смогли зарегистрировать юзера макси.