Неплохие доклады о мониторинге с Youtube
Почему важно для разработчика? Лаг получения обратной связи до разработчика может быть очень большим (доходило до недели). Сведения для разбора проблемы могут быть очень скудными, неразборчивыми, искажены, проходя через несколько служб (в том числе и служба безопасности). Кроме того, при разборе, для разработчика важно что предшествовало критической ситуации, детали состоянии системы в момент инцидента. Конечно, разработчик и сам должен предусмотреть качество сообщения об ошибке (м.б. вывести в лог состояние переменных системы, версии, какие-то критичные системные параметры). Еще раз: не просто stacktrace, но и состояние переменных. Даже если система и не упала, но возможно, разработчик посчитает ситуацию критической и будет нужно получить какие-то сведения.
Кратко о докладе:
8:00 введение… 36:00 начало 41:50 observability. Уровни мониторинга 43:30 методологии сбора метрик 47:10 типы логов 50:20 инструменты логирования 50:50 тресинг 53:10 инструменты трейсинга 54:00 алертинг 1:01:37 внедрение 1:05:30 только часть запросов покрываются готовыми решениями 1:06:10 health check 1:09:45 restarts 1:11:40 употребление ресурсов 1:13:15 реплики и инстансы 1:15:40 коммуникации между прил 1:18:45 CI/CD 1:22:10 мониторинг приложения как бизнес продукта 1:25:30 ссылки библиотек 1:28:00 ВОПРОСЫ 1:39:10 тех.диры в мониторинге 1:40:40 тех.дир работает в 3х основных командах (технари, тимлиды, бизнес) 1:46:01 бизнес мониторинг начинается с одной главной метрики, под которую подстраиваются остальные (!)-1:47:30 функционал проектируется вместе с мониторингом 1:49:40 любая новая срочная задача мониторинга "блочит" разработку 1:51:10 transaction cost - то количество внимания/денег, которое готов потратить клиент для удовлетворения потребности (иногда его не хватает, чтоб одовл.потребность) (!)-1:52:30 задача техподдержки - спасать сервис, чтобы он мог удовлетворить потребность, а не справляться с ошибками 1:54:00 техподдержка узнала, что transaction cost превышает возможный - это задача мониторинга 1:55:40 техподдержка узнает о желаемый фичах от пользователей - помогает этому мониторинг 1:56:50 ИТОГИ 2:07:00 когда алертов слишком много 2:12:30 severity - важность алертов 2:22:00 практика алертов в авиации 2:31:10 ЛИТЕРАТУРА по алертингу 2:42:00 организация мониторинга со стороны команды и процессов
5:18 обзор тем 27:40 опыт selectel - что мониторим, и зачем (доклад СТО) 59:00 мониторинг бизнес метрик в приложениях 1:12:40 отображение данных 1:18:50 ИТОГО 1:24:00 организация дежурных и grafanaOnCall (CTO CORE 24/7) 1:35:00 объединенте алертов 1:55:00 сбор логов Grafana Loki 2:29:17 Мультитенанси мониторинг 2:59:00 инциденты, коммуникация в команде и роли в техподдержке 3:41:00 эргономичный мониторинг на практике 4:09:30 кастомизация zabbix 4:29:00 мониторинг бэкапов
5:20 обзор тем 30:20 мониторинг и скорость развития продукта 51:40 выводы (мониторинг должен быть связан с резкльтатом бизнеса) 1:03:15 мониторинг маркетинговых показателей 1:22:00 когортный анализ 1:30:20 мониторинг по real-time данным 1:58:00 мониторинг фин.показателей 2:34:00 оценка предполагаемого ущерба инцидента 2:44:00 имидживые потери 3:04:30 Пирамида продуктовых метрик (как правильно выбрать метрику) 3:42:00 важность мониторинга продукта для бизнеса 4:10:30 мониторинг удовлетворенности пользователей