Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Lead Engineer в Salesforce.com
  • Мониторинг микросервисов: разделяй и властвуй

    Так о том и пост. Делать метрики из логов достаточно сложно технологически при больших объемах логов. Мы стараемся использовать метрики вначале, а логи уже как запасной вариант.

  • Мониторинг микросервисов: разделяй и властвуй

    Да, так и есть. Ошибка с зависимостью — это один из вариантов. Вопрос в том, что делать дальше с этой ошибкой: показывать клиенту совсем плохо — незачем их пугать, писать в логи можно, но кто-то должен отслеживать логи. Наилучшее решение: давайте придумаем как сделать так, чтобы оно само разбиралось, а мы потом посмотрим статистику и решим что и как исправить.

  • Мониторинг микросервисов: разделяй и властвуй

    мы держали 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 + полная автоматизация любых процессов + проактивный мониторинг. Чаще всего проблемы не возникают мгновенно, а накапливаются со временем. Соответственно рецепт — это надежный и продуманный мониторинг с ранней диагностикой. Самолеты летают и мосты стоят со значительно более высокой надежностью.

    Підтримали: Andriy Maletsky, Sergiy Fakas
  • Мониторинг микросервисов: разделяй и властвуй

    Ну есть варианты: пнуть владельцев того сервиса который начал тормозить, пока проблема решается наш сервис может или возвращать ошибку или какие-то закешированные значения/значения по умолчанию. Circuit breaker как раз о такой ситуации. Еще вариант: когда время ответа доходит превышает 90ую персентиль — перепослать запрос еще раз.

    Все зависит от конкретного сервиса.

    Хуже когда хозяева сервиса на знают о проблеме, или когда они не готовы к этому

  • Тестирование через логирование: способы и примеры

    Мы используем логи как 3й уровень информации для поиска проблем. 4й — код. Первые два уровня базируются на числовых метриках — их проще собирать и значительно проще анализировать.

    Сергей, а вы как-то выстраиваете корреляцию логов между разными частями системы чтобы проще вытаскивать последовательность всех событий в пределах одного запроса или сессии?

← Сtrl 12 Ctrl →