Да, так и есть. Ошибка с зависимостью — это один из вариантов. Вопрос в том, что делать дальше с этой ошибкой: показывать клиенту совсем плохо — незачем их пугать, писать в логи можно, но кто-то должен отслеживать логи. Наилучшее решение: давайте придумаем как сделать так, чтобы оно само разбиралось, а мы потом посмотрим статистику и решим что и как исправить.
мы держали Graphite до 20М метрик/минуту. Дальше уже не имело смысла. Там хранилище очень неэффективное + при выпадении одного из серверов появляются случайные провалы при запросах данных.
Prometheus вот прямо хорош, особенно с новым хранилищем. Но нужно сильно постараться, чтобы построить правильную систему перекачки метрик между инстансами. А еще очень хотелось бы писать данных на ceph или hdfs вместо локального диска.
Elastic совсем не может держать нашу нагрузку — мы пытались.
Мы не используем kubernetes autoscaler, обычно нагрузка заранее известных пределах. Я делал проект когда автоскуйлинг работал через prometheus — метрики сливались в prometheus, а от туда через алерты уже вызывались API для scale up/down. стандартный автоскейлер очень простой для реальной жизни — не все измеряется в CPU.
Про утилизацию CPU/RAM прямо не знаю что написать. Где-то больше, где-то меньше.. На хостах с apache zookeeper все практически в 0, но там другие ограничения.
Мы и снаружи проверяем. Из разных регионов и все такое. Но снаружи бессмысленно проверять асинхронные процессы или системы которые занимаются обработкой данных
Дорого, но это бизнесу решать, что им лучше: прилечь или потратиться.
Собираем кучу данных, алертим то что важно. А самое главное мы можем быстро понять, что проблемы не у нас, пнуть виновных и отправиться спать дальше.
Я не сильно вдавался в детали, но продукт состоит из 10 видов сервисов, в реальности это тысячи инстансов этих сервисов работающих в датацентрах по всему миру. Добавьте к этому 50 внешних зависимостей, которые тоже умножаются на количество датацентров и каждая зависимость — это много серверов и сервисов.
Просто невозможно построить модель описывающую этот муравейник, а очень нужно. Вот и придумываем как упростить мир и таки решить проблему.
Статья о том как выжить в мире хаоса и при этом хорошо спать ночью.
Сервисы, в большинстве своем, это Java
для сбора данных с хостов используется CollectD
сами сервисы чаще всего используют Dropwizard-metrics,
мы используем push-модель для передачи метрик, т.е. дальше метрики пишутся по REST в Kafka, переправляются в другой датацентр, а там записываются в Argus (наша доморощенная система — github.com/salesforceeng/Argus).
Есть и kubernetes — именно от сюда растут ноги требования, что мы хотим делать RCA без доступа к хостам.
В общем система мониторинга прокачивает 100М+ метрик в минуту и продолжает расти экспоненциально. 3 года назад было 3М в минуту.
99.9% обеспечить вполне возможно: DR + полная автоматизация любых процессов + проактивный мониторинг. Чаще всего проблемы не возникают мгновенно, а накапливаются со временем. Соответственно рецепт — это надежный и продуманный мониторинг с ранней диагностикой. Самолеты летают и мосты стоят со значительно более высокой надежностью.
Ну есть варианты: пнуть владельцев того сервиса который начал тормозить, пока проблема решается наш сервис может или возвращать ошибку или какие-то закешированные значения/значения по умолчанию. Circuit breaker как раз о такой ситуации. Еще вариант: когда время ответа доходит превышает 90ую персентиль — перепослать запрос еще раз.
Все зависит от конкретного сервиса.
Хуже когда хозяева сервиса на знают о проблеме, или когда они не готовы к этому
Мы используем логи как 3й уровень информации для поиска проблем. 4й — код. Первые два уровня базируются на числовых метриках — их проще собирать и значительно проще анализировать.
Сергей, а вы как-то выстраиваете корреляцию логов между разными частями системы чтобы проще вытаскивать последовательность всех событий в пределах одного запроса или сессии?
Так о том и пост. Делать метрики из логов достаточно сложно технологически при больших объемах логов. Мы стараемся использовать метрики вначале, а логи уже как запасной вариант.