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

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

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

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

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом "«Administrator Linux. Professional» в OTUS. Вы научитесь делать профессиональный подбор конфигурации, управлять процессами, обеспечивать безопасность, выполнять развертывание, настройку и обслуживание сетей. Проверьте себя на вступительном тесте и смотрите подробнее программи ссылке.

Автор Zerox

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

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

Ваш адрес email не будет опубликован.

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