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

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

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

Хочешь научиться автоматически разворачивать и поддерживать высоконагруженные проекты? Тогда рекомендую познакомиться с онлайн курсом " Infrastructure as a code." в OTUS. Актуально для системных администраторов и devops инженеров. Подробности по .

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

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

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

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

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца. Что даст вам этот курс:
  • Познакомитесь с Terraform.
  • Изучите систему управления конфигурацией Ansible.
  • Познакомитесь с другими системами управления конфигурацией - Chef, Puppet, SaltStack.
  • Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
  • В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins
Смотрите подробнее программу по .

Автор Zerox

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

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

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

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.