Мониторинг сложных систем

Посмотрел крайне интересное выступление Евгения Потапова (ITSumma) - Мониторинг сложных систем в 2019 году. Мне близка тема мониторинга, поэтому я с удовольствием прослушал доклад опытного и очень компетентного человека. В видео нет каких-то конкретных технических советов и решений, но даны фундаментальные, базовые подходы к мониторингу сложных систем.

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Сразу же законспектировал доклад после просмотра и делюсь с вами основными тезисами, на которые обратил внимание лично я.

  1. Мониторинг инфраструктуры с помощью Zabbix и т.д. последнее, с чего надо начинать построение полноценной системы мониторинга. Наблюдение за инфрой можно вообще вывести в отдельную подсистему. Это самое простое и настраивается чаще всего автоматически.
  2. Начинать мониторить нужно с элементов, с которыми взаимодействует пользователь (например, авторизация в ЛК, работа корзины и т.д.). Вы должны раньше него узнать о проблемах. Дальше опускаетесь на уровень сервисов (прохождение заказов, работа доставки и т.д.), api, базы данных и в самом низу кластерная и железная инфраструктура.
  3. Мониторить кластер изнутри кластера абсурд. Мониторинг должен быть внешним по отношению к наблюдаемому объекту. Я лично об этом подумал на обучении по kubernetes, где рассматривали мониторинг кластера установкой prometheus внутри кластера. Когда все упадет, мониторинг даже не предупредит вас об этом.
  4. Мониторинг современного программного проекта сам по себе программный проект. И им должны заниматься разработчики. Это объемная работа, съедает примерно 30% их времени. Но без этого полноценного мониторинга и, как следствие, стабильной работы сервисов не будет. Никакой сисадмин или devops в одиночку его не построит. Они не понимают внутреннюю кухню сервисов и их взаимодействие.
  5. Уведомления должны быть строго по делу и персонифицированы. Их не должно быть много и они не должны повторяться много раз. Проблемы по триггерам надо локализовывать и исправлять.

❗️ Как обычно удивился рассказам на тему того, как и когда надо будить людей по ночам, если сработает критически важный триггер. Поражаюсь, что люди соглашаются работать (а они соглашаются) на таких условиях. Это не нормально и так быть не должно. Если сервис важный и не терпит простоя, должна быть всегда дежурная смена в том числе и программистов, способных все исправить. Не позволяйте бизнесу экономить на вас и будить по ночам. Это происходит с вашего согласия.

Источник - мой канал: https://t.me/srv_admin/497.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar