Посмотрел крайне интересное выступление Евгения Потапова (ITSumma) - Мониторинг сложных систем в 2019 году. Мне близка тема мониторинга, поэтому я с удовольствием прослушал доклад опытного и очень компетентного человека. В видео нет каких-то конкретных технических советов и решений, но даны фундаментальные, базовые подходы к мониторингу сложных систем.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Сразу же законспектировал доклад после просмотра и делюсь с вами основными тезисами, на которые обратил внимание лично я.
- Мониторинг инфраструктуры с помощью Zabbix и т.д. последнее, с чего надо начинать построение полноценной системы мониторинга. Наблюдение за инфрой можно вообще вывести в отдельную подсистему. Это самое простое и настраивается чаще всего автоматически.
- Начинать мониторить нужно с элементов, с которыми взаимодействует пользователь (например, авторизация в ЛК, работа корзины и т.д.). Вы должны раньше него узнать о проблемах. Дальше опускаетесь на уровень сервисов (прохождение заказов, работа доставки и т.д.), api, базы данных и в самом низу кластерная и железная инфраструктура.
- Мониторить кластер изнутри кластера абсурд. Мониторинг должен быть внешним по отношению к наблюдаемому объекту. Я лично об этом подумал на обучении по kubernetes, где рассматривали мониторинг кластера установкой prometheus внутри кластера. Когда все упадет, мониторинг даже не предупредит вас об этом.
- Мониторинг современного программного проекта сам по себе программный проект. И им должны заниматься разработчики. Это объемная работа, съедает примерно 30% их времени. Но без этого полноценного мониторинга и, как следствие, стабильной работы сервисов не будет. Никакой сисадмин или devops в одиночку его не построит. Они не понимают внутреннюю кухню сервисов и их взаимодействие.
- Уведомления должны быть строго по делу и персонифицированы. Их не должно быть много и они не должны повторяться много раз. Проблемы по триггерам надо локализовывать и исправлять.
❗️ Как обычно удивился рассказам на тему того, как и когда надо будить людей по ночам, если сработает критически важный триггер. Поражаюсь, что люди соглашаются работать (а они соглашаются) на таких условиях. Это не нормально и так быть не должно. Если сервис важный и не терпит простоя, должна быть всегда дежурная смена в том числе и программистов, способных все исправить. Не позволяйте бизнесу экономить на вас и будить по ночам. Это происходит с вашего согласия.
Источник - мой канал: https://t.me/srv_admin/497.