Когда я пришёл на проект, всё было похоже на нескончаемый пожар. В продакшене сыпались алерты один за другим, CI/CD-пайплайны (GitLab и Jenkins) постоянно фейлили, а релизы проходили хаотично — каждый новый билд мог «уложить» сервис. Я пил кофе в три ночи, когда прозвучал очередной звонок на мобильник: «сервис упал — немедленно разбирайся!». MTTR (Mean Time To Recovery)Читать полностью »
Чем сложнее система, тем больше она обрастает всевозможными алертами. И возникает потребность на эти самые алерты реагировать, агрегировать их и визуализировать. Думаю, ситуация, знакомая многим до нервного тика.
Решение, о котором пойдёт речь, не самое неожиданное, но полноценной статьи по этой теме поиск не выдаёт.
Поэтому я решил поделиться опытом FunCorp и рассказать о том, как выстроен процесс дежурств, кто звонит, почему и как на это всё можно смотреть.
Дзииииииинь! На часах 3 утра, вы смотрите чудесный сон, и вдруг — звонок. На этой неделе вы дежурите, и, видимо, что-то случилось. Автоматизированная система зовет разобраться, в чем дело. Это важный момент управления современными компьютерными системами, но давайте посмотрим, как сделать уведомления удобнее для людей.
Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).
Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.
Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:
В этой статье я хочу показать, как легко и бесплатно можно сделать failover схему для веб-сайта (или любого другого интернет-сервиса) на комбинации мониторинга okerr и динамического DNS сервиса. То есть, в случае любых проблем с основным сайтом (начиная от проблемы с «PHP Error» на странице, и до нехватки места или просто подозрительно малом числе заказов в случае интернет-магазина), новые посетители будут направлены на второй (третий, и так далее) заведомо работающий сервер, или же на «Sorry» страничку, где им вежливо объяснят, что «есть проблема, мы уже в курсе и уже чиним, скоро починим» (а вы в этом случае на самом деле будете уже в курсе и сможете чинить).
Читать полностью »
Ранее мы писали, как можно загрузить логи в Splunk из каталога или с помощью syslog, рассказывали как забирать стандартные виндовые и линуксовые события, но что если нам необходимо получать более гранулярную информацию о работе наших систем?
В таком случае на помощь приходят скрипты!
Когда, какие и как можно использовать скрипты в Splunk для получения данных — вы можете узнать под катом.
Читать полностью »
Мы продолжаем тему алертинга в Splunk. Ранее мы говорили о том, как настроить отправку оповещений на электронную почту, а сегодня покажем Вам, как отправлять уведомления в мессенджеры, такие как Telegram и Slack.
В статье вы найдете пошаговую инструкцию по настройке.
Читать полностью »
Сколько времени проходит с момента возникновения какого-то важного события до реакционных действий? Зачастую очень много! Одним их факторов влияющих на время реакции служит несвоевременное информирование персонала, отвечающего за принятие решений.
Сегодня мы расскажем вам о том, как получать уведомления о возникновении важных инцидентов безопасности, критическом состоянии IT систем, существенных отклонениях от нормы различных показателей или о других интересных для вас событиях в режиме реального времени и в удобном формате, в частности по электронной почте.
Реализовывать алерты, или иначе говоря оповещения, будем в Splunk, продукте, специализирующемся на анализе машинных данных, о котором мы писали ранее.
Читать полностью »
Сотни контейнеров. Миллионы внешних запросов. Миллиарды внутренних транзакций. Мониторинг и нотификации проблем. Простое масштабирование. 99% up time. Деплои и откатывание релизов.
Kubernetes как решение всех проблем! «Быть или не быть?» — вот в чем вопрос!
Читать полностью »
Одной из важнейших задач при разработке приложений с микросервисной архитектурой является задача мониторинга. Слежение за состоянием сервисов и серверов позволяет не только вовремя реагировать на неисправности, но и анализировать их работу. Наличие такой информации трудно переоценить, ведь она предоставляет дополнительные возможности по улучшению производительности и качества работы Вашего ПО.
К счастью, существует множество решений задачи мониторинга, как платных, так и бесплатных. Я же хочу поделиться опытом практического использования open source системы мониторинга Prometheus.
Читать полностью »
Контур делает несколько десятков продуктов, каждый из которых состоит из нескольких десятков микросервисов, каждый из которых запущен на десятках серверов.
Эта инфраструктура порождает метрики на всех технологических уровнях — нагрузка на железо, состояние ОС, метрики приложений. Исходные данные собираются в один большой кластер Graphite. Сейчас у нас есть миллион уникальных метрик, по которым суммарно генерируется 20 тысяч значений в секунду.
Ясно, что за миллионом метрик не уследить глазами на телевизорах и дашбордах — нужна система отправки уведомлений о нештатных ситуациях. Перед тем как написать свою систему Moira, мы использовали для этой задачи Seyren.
Читать полностью »
