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

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курcе по администрированию MikroTik. Автор курcа, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу ссылке.

Автор Zerox

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

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

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

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