Это первая серия из серии, посвященной использованию машинного обучения и статистики для моделирования сценариев отказов для сложных распределенных систем. В рамках этой серии статей мы рассмотрим пошаговый процесс создания моделей машинного обучения, способных превзойти людей в анализе первопричин и настройке производительности. Чтобы понять, как решать этот процесс с помощью автоматизации, важно сначала понять процессы, которые человек-эксперт будет использовать при устранении неполадок или анализе производительности.

Немного предыстории

Последние 10 лет я работал с крупномасштабными распределенными системами как пользователь и консультант. В моей роли консультанта я работал над более чем 500 развертываниями, обычно это некоторая комбинация Cassandra, Kafka, Spark, ElasticSearch, Solr, Kubernetes и Hadoop. Консультанты обычно выполняют две роли: помогают компании стратегией и советами при создании приложения, а также отвечают на звонки, когда что-то идет не так или возникает серьезная проблема с производительностью. В обоих случаях вы выполняете более или менее одинаковый рабочий процесс:

  1. Соберите цели и намерения пользователя;
  2. Соберите соответствующие метрики или журналы; и
  3. Систематически прорабатывайте различные рабочие нагрузки и подсистемы, чтобы определить, где может возникнуть узкое место или проблема.

Есть две опубликованные работы, в которых излагается, как лучше всего выполнить этот процесс: метод USE Брендана Грегга и книга SRE, опубликованная Google.

ИСПОЛЬЗОВАТЬ метод

Компьютер - это не монолитный объект, это совокупность подсистем, работающих совместно для достижения цели. Эти подсистемы - это ЦП, память, диски и сетевые интерфейсы. У каждой из этих систем есть свои ограничения и условия отказа. Когда у компьютерной программы возникают проблемы с производительностью или надежностью, это обычно является результатом перенапряжения или сбоя одной системы. Понять, почему система работает медленно, или избавиться от потока предупреждений и ошибок сложно и часто требует большого опыта, основанного на сопоставлении и корреляции с образцом. Чтобы облегчить этот процесс для новичков, Брендан изобрел базовую процедуру, позволяющую систематически разбивать систему на составные части и изолировать источник проблемы.

Для каждого ресурса проверьте использование, насыщение и ошибки

ИСПОЛЬЗОВАНИЕ - это аббревиатура, обозначающая Использование, Насыщенность и Ошибки, и этот метод является наполовину руководством к тому, на что обращать внимание при обнаружении ошибок и половина процедуры. Уловка состоит в том, чтобы взглянуть на вашу систему и разбить ее на все различные подкомпоненты, а затем для каждого ресурса проверить использование, насыщение и ошибки. Если вы будете делать это систематически, то сможете понять, какие системы испытывают нагрузку, какие системы испытывают ошибки, и сформировать гипотезу о том, почему система дает сбой. Когда у вас появится гипотеза, вы можете выполнить дальнейшие проверки, чтобы подтвердить свои идеи, или предложить эксперименты, такие как увеличение ввода-вывода или кеширование определенных значений для решения проблемы.

Методология USE хорошо работает, когда вы пытаетесь устранить неполадки в одном приложении на выделенном сервере, но что произойдет, если вы попытаетесь сделать это для гораздо более крупной системы, такой как распределенная база данных или приложение, состоящее из множества микросервисов?

Google, четыре золотых сигнала и длинные хвосты

В больших распределенных системах все становится немного сложнее. Например, вы имеете дело с сотнями или тысячами машин. Как узнать, какой ресурс является узким? Вы проверяете каждую машину? Как узнать, вызывает ли ошибка на одной машине всплеск задержки, наблюдаемый пользователем? Это еще больше усложняется тем фактом, что распределенные системы шумны и динамичны. В достаточно большом кластере всегда что-то идет не так. Машины регулярно выходят из строя, исключения приложений никогда не опускаются до нуля, а кластер часто меняет размер в ответ на загрузку. Если бы вы реагировали на каждое предупреждение, вас быстро ошеломило бы. Чтобы справиться с этой сложностью,

Ваше приложение больше не представляет собой единую программу, работающую на одной машине. Это совокупность сотен или тысяч машин, и вместо подсистемы, такой как диск или ЦП, вы отслеживаете характеристики базовых служб, таких как очереди или базы данных, каждая из которых может поддерживаться множеством машин. Что еще больше усложняет ситуацию, распределенные системы не являются постоянными. Машины регулярно выходят из строя, системы масштабируются вверх или вниз в ответ на нагрузку, а обмен данными между подсистемами осуществляется по сети, что создает собственный источник шума. Если бы вы предупреждали о каждой ошибке или различии в задержке, вы бы быстро не справились.

Что измерить

Глава 6 книги SRE рассматривает сложность мониторинга распределенных систем, давая указания о том, что и как измерять. Они проходят через множество тех же показателей, которые выделены в методе USE, но заменяют использование на Задержка и Пропускная способность. Задержка и пропускная способность - это конкретные концепции, которые, скорее всего, уже экспортированы вашей системой, тогда как использование в некоторой степени абстрактно и трудно измерить в системе, которая постоянно меняется. Итак, собирая все вместе, мы обычно имеем дело с 4 наборами показателей (Задержка, пропускная способность, насыщенность и ошибки), и мы будем использовать эти показатели в будущем, чтобы характеризовать работу и стресс для каждой системы. или подсистема, которую мы отслеживаем.

Беспокойство о своем хвосте

Другой важный вывод из главы о мониторинге заключается в том, что вам следует беспокоиться о своем хвосте. Что такое хвост? Хвост - это высшие процентили вероятностного распределения. Распределения - это ключ к более полному пониманию того, что делает ваша система. К сожалению, большинство людей и часто система (сборка мусора JVM, ElasticSearch) делают ошибку, сообщая метрики только по их среднему (среднему) значению, что делает практически невозможным устранение неполадок.

Речь идет о дистрибутивах

Распределения важны, потому что они описывают общее поведение вашей системы и дают вам более глубокое понимание того, что происходит.

Просто взглянув на график распределения задержки выше, я смог получить очень подробное представление о поведении моей системы. Я вижу, что средняя задержка составляет около 32 миллисекунд, и я также знаю, что 95% моих запросов выполняются примерно за 55 мс. Это очень узкое распределение с очень небольшими отклонениями в реальных условиях. Кроме того, я вижу два пика, что означает, что, вероятно, существует два разных набора поведения или распределения задержки запросов, которые охватываются этим графиком. Вся эта информация будет потеряна, если я уменьшу задержку до одной точки данных. Давайте рассмотрим несколько реальных примеров того, как мы используем эту информацию при устранении неполадок.

Привет! У кого, по вашему мнению, «толстый хвост»?

В качестве первого примера того, почему дистрибутивы важны, давайте вернемся к обсуждению длинных хвостов. При распределении запросов во времени, если вы измеряете среднюю скорость ответа в течение минуты, 90% ваших запросов могут составлять 3 миллисекунды, 10% могут составлять 300 миллисекунд, а у вас будет средняя скорость ответа 32,7 миллисекунды. . Это выглядит великолепно, но если ваш SLO равен p95 100 мс, то вы нарушите и никогда не узнаете об этом. Если вы записываете только среднее (среднее), вы теряете важную информацию, в том числе способность обнаруживать выбросы.

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

Святой s *% #, почему все горит?

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

Сдвиг в распределении дает вам подсказки, необходимые для выполнения следующего уровня анализа.

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

Подведение итогов и следующие шаги

Напомним, что мы определили, что следует измерять (пропускную способность, задержку, насыщение, ошибки), как измерять (распределения), а также примерный рабочий процесс устранения неполадок на основе методологии ЕГЭ. Однако есть еще один элемент, который необходим для реализации этого на практике, - это DAG ( направленные A циклические G рафы). В следующей части мы поговорим о том, как создавать группы DAG для известных систем, и об общих эвристиках для выявления причинно-следственных связей и объяснения сбоев в обслуживании.