Методологически мониторинг производства (общение с транскрипцией)

Это стенограмма из разговора Мониторинг производства методологически что мы дали в Деспагаре 11 июня 2020 года. В течение последних 5 лет мы работали вместе над различными проектами, в которых, помимо нашей работы в качестве разработчиков, мы пробовали различные инструменты и методы для мониторинга приложений в производстве. Этот разговор включает в себя много уроков и методов, извлеченных в эти годы.

Для испанской версии перейдите по этой ссылке

Дата: 06/11/2020 Авторы:

Диего

Кристиан Спинетта

Это Отредактировано и синтезирован Стенограмма разговора Мониторинг производства методологически Мы дали в Despegar 11 июня 2020 года. За последние 5 лет мы работали вместе над различными проектами, как разработчики, и по пути мы исследовали и протестировали различные инструменты и методы для мониторинга приложений. Этот разговор включает в себя много уроков и методов, извлеченных в эти годы.

Стенограмма:

Это разговор о аспектах и уроках, которые следует учитывать при создании системы мониторинга.

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

Идеи, которыми мы делимся в этом выступлении, желательный , то есть руководящие принципы для достижения успешной системы мониторинга. Тогда каждый должен будет проанализировать и решить, как наиболее удобный способ перенести его в свою систему.

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

И возможно, что после больших усилий нам удалось ответить на все вопросы, и даже на этом пути добавилось еще много показателей. Как в этом примере, в котором «Просто, потому что мы можем …» , мы добавили погоду и прогноз погоды.

Хотя эта приборная панель может показаться очень полной, насколько эффективна решение проблем в производстве? Полезно ли для устранения неполадок или понимания, что происходит не так?

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

Так какие вопросы действительно имеют значение? Какие из них мы должны ответить нашей системой мониторинга?

Есть 2 ключевых вопроса, на которые вы должны ответить: Что сломано и Почему Анкет

Эти два вопроса должны направлять нашу систему мониторинга.

Когда мы пытаемся ответить Что сломано , мы говорим о Симптомы что наша система представляет, что эквивалентно удар что мы генерируем для пользователей (будучи людьми или другими приложениями).

Когда мы пытаемся ответить Почему этот симптом произошел , мы говорим о причине.

Синди Шридхаран , в посте о Мониторинг и наблюдение Говорит, что наша система мониторинга должна сделать видимым или очевидным, какое влияние мы оказываем на наших пользователей ( Что сломано ), а также влияние любого развертываемого исправления.

Здесь мы оставляем ссылку на Глава 6 из книги Google, откуда мы извлекли это первое руководство, относительно Что и Почему Анкет И затем давайте сосредоточимся на том, как эти два вопроса могут направлять проектирование нашей системы мониторинга.

Для ясности, давайте посмотрим на 3 простых примера Симптомы Против. Причины Анкет

• В первом случае у нас есть API это отвечает 500S Анкет Симптом, то есть то, что воспринимается извне, и, следовательно, то, как мы влияем на пользователя, является фактом возвращения 500 с . Хотя причина в этом случае заключается в том, что база данных отвергает соединения.
• Во втором случае API отвечает, но медленнее, чем ожидалось. Это симптом, который можно наблюдать извне. Хотя причина в том, что запросы находятся в очереди. Это промежуточная причина, было бы необходимо проанализировать, почему они стоят в очереди.
• В третьем случае симптом является то, что пользователи не могут войти в систему, и причина заключается в том, что клиент аутентификации получает 503 Анкет

Те, кто захватывает симптомы, называются «Мониторинг черного ящика» , поскольку мы получаем внешний вид системы. В то время как те, которые захватывают внутренние события системы, называются «Мониторинг белой коробки» , и они обычно позволяют нам понять причину.

* Различие между тем, что и почему позволяет нам проектировать системы мониторинга с более четкими сигналами и меньшим шумом * Анкет Эта цитата взята из Google SRE Book Анкет

Кто -то мог бы заметить, что причины нашей системы может быть одним симптомом в другой. Это случай третьего примера, когда у нас есть клиент, который получает 503 , что является причиной в нашей системе и симптомом на другой стороне, в службе, которая обрабатывает эти запросы.

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

В случае Черный ящик :

• Мониторинг должен быть продуман с точки зрения пользователя (или из бизнес -требований). Например, такие вопросы, как Как быстро пользователи ожидают, что мой API ответит на них? , заставит нас сделать график времени отклика.
• Они обычно контролируются через Slis и SLOS (Позже мы увидим, что они значат).
• Их относительно легко узнать, поскольку в целом требования, которые служба пытается удовлетворить, известны заранее.
• Этот тип системы позволяет нам визуализировать активные проблемы То есть они уже встречаются и влияют на пользователя.
• Это означает, что Мы должны действовать реактивно : Когда проблема уже влияет на пользователей.
• В целом, оповещения от системы мониторинга черного ящика, как правило, последними, которые будут увольнения.
• Они обычно решаются людьми, которые на вызове.
• И они, как правило, состоят из нескольких метрик, поскольку пользователи обычно не ожидают очень сложных вещей от наших услуг, они просто хотят, чтобы они работали в соответствующее время отклика, соответствующее, без ошибок и т. Д.

В случае Белая коробка :

• Мониторинг должен быть продуман с очень технической точки зрения, основываясь на архитектуре нашего сервиса.
• Как правило, они контролируются порогами, в рамках которых мы можем подтвердить, что наши компоненты будут работать хорошо.
• В целом, более трудно понять, что мы заинтересованы в мониторинге, и как, поскольку это зависит от технических знаний и опыта в отношении компонентов системы.
• Они обнаруживают неизбежные проблемы То есть, они, возможно, еще не принесли никаких последствий, но если они продолжат таким образом, они скоро.
• Они позволяют вам действовать активно , поскольку они позволяют вам предвидеть симптомы, которые собираются возникнуть. Например, если мы увидим, что дисковое пространство прошло пороговое значение, мы можем подтвердить, что если мы продолжим таким образом, у нас скоро закончится диск, который может быть чем -то, что дает некоторое влияние на пользователя, и поэтому мы можем отреагировать Раннее, предотвращая проблему кончика диска.
• В целом, он имеет тенденцию иметь раннюю тревогу, которая может предотвратить инциденты.
• Обычно существуют автоматические решения, например, автомассалирование, автоматический откат, выключатель схемы и т. Д.
• И здесь мы хотим иметь столько метрик, сколько система должна убедиться, что она находится в приемлемом состоянии.

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

Оба типа мониторинга важны и дополняют друг друга.

Вот несколько хороших практик, которые мы включали.

1. Простота является основной оптимизацией любой системы . Система мониторинга похожа на любую другую программную систему, она может легко стать сложной и неуправляемой, среди прочих недостатков. Поддержание простых вещей помогает облегчить понимание, поддержание и модификацию.
2. Это должно быть легко читать и понять. Другими словами, должен быть выразительным Анкет
3. Не разжигайте излишне. Например, если я измеряю время, выберите соответствующим образом 3 или 4 процентиля, если я хочу измерить ошибки, выберите их считать, либо подсчитывая количество ошибок, либо подсчитывая успех, и подсчитывать только один и т. Д.
4. Держите диаграммы чистыми и аккуратными.
5. Метрики и оповещения, которые мы редко используем, являются кандидатами на удаление. Или мы должны подумать о том, какие изменения необходимо внести, чтобы сделать его более актуальным.
6. Если возможно, имейте немного метрик и не дублируйте их. Иногда у нас есть одинаковая метрика, взятая с разными системами. Избегайте избыточности, или вы можете не знать, на что смотреть.
7. Обратите особое внимание на то, как мы измеряем. В целом, использование временных рядов, которые разрешают графики непрерывных строк, предпочтительнее проведения дискретных проверок, как мы бы сделали с Нагиос Например.
8. Избегайте средних значений Анкет В основном, когда мы измеряем время отклика. Предпочтительно сохранить время в ведрах и визуализировать распределение, например, процентиль 50/75/90/99/99,9/и т. Д. Также имейте в виду, как настраиваются ведра, и если они в соответствии с временами, которые мы хотим записать.
9. Следите за выбросами, например, на 99,9 процентиля или 99,99 процентиля (или больше, что зависит от услуги, которую мы анализируем). Важно не забывать об этих пиках, которые в зависимости от количества трафика могут быть значимыми.
10. Соответственно выберите разрешение в соответствии с тем, что мы измеряем. В большинстве случаев по умолчанию, которые приносят инструменты, не соответствует нашим потребностям.

Теперь мы собираемся показать две наиболее используемые методологии для мониторинга.

Используйте метод это методология, созданная Брендан Грегг , отраслевой эксперт в области вычислительных показателей. Это методология, ориентированная на анализ производительности, ориентированную на анализ 3 аспектов каждого ресурса: U Тилизация, S БОЛЬШЕ И E rrors. Он говорит, что анализируя эти 3 аспекта каждого ресурса, мы можем решить 80% случаев.

• Использование — это среднее время, когда ресурс был занят обслуживанием.
• Насыщение можно рассматривать как очередь задач, которые будут отправлены ресурсом. Количество задач, которые находятся в очереди, представляет собой степень насыщения ресурса.
• Ошибки, то есть количество сбоев ресурсов. Это может быть подсчитано как отношение типа Ошибки/общие запросы Анкет

Хотя эта методология была создана для анализа производительности, ее можно использовать в качестве руководства для создания нашей системы мониторинга белых коробок, поскольку мы могли бы проанализировать эти 3 характеристики в каждом компоненте/ресурсе, которые нас заинтересованы в мониторинге.

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

Это методология для разработки мониторинга черного ящика.

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

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

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

Конечно, SRE — это гораздо больше, чем мониторинг приложений, не говоря уже о том, если мы учитываем, как Google применяет его. Зная, что мы не Google, ни Twitter, ни Netflix, мы считаем, что мы можем взять некоторые идеи из этих практик и довести их до нашей реальности.

Одна из главных целей SRE — измерить, насколько хорошо ожидаются ожидания пользователей. Чтобы иметь возможность объективно определить его, они выбирают серию ключевых индикаторов, называемых SLI (индикатор уровня обслуживания) , чтобы измерить, выполняется ли качество обслуживания, которое предназначено для предоставления.

В Google есть «SLI Menu» , который имеет список Slis Чтобы применить к каждому типу сервиса, в зависимости от того, как служба взаимодействует с пользователями. Например, в службе, где пользователи взаимодействуют через Запрос/Ответ Схема, 3 ключа Slis было бы доступность , задержка и качество ответов . Качество может быть интересной метрикой, если у нас есть немного Изящная деградация механизм. Точно так же, если у нас есть услуга, которая работает как Трубопровод данных Если пользователи выдвигают событие для его обработки и доступного, нас заинтересовано в наблюдении за другими типами индикаторов и так далее.

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

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

1. Первый шаг — выбрать подходящее Slis Для обслуживания я хочу контролировать.
2. Второй шаг — указать, какие события мы собираемся рассмотреть Действительно для Sli и какое условие они должны встретиться, чтобы считаться успешный или хороший События.
3. Наконец, в третьем шаге мы должны указать, где мы собираемся получить эти события, в основном, насколько близко к пользователю или насколько близко к приложениям мы будем.

Вот пример того, как мы могли бы добавить 2 Slis Чтобы измерить доступность и задержка услуги, которая раскрывает пользовательскую информацию.

В случае Доступность , мы можем указать, что мы хотим наблюдать процент Получает которые завершены успешно, и в качестве реализации мы можем указать, что мы будем записывать в качестве действительных событий все запросы, которые возвращают 200 -е или 500S как код статуса и как успешные события, те, которые возвращаются 200 -е . Итак, мы можем сделать соотношение количества 200s Через количество 200S + 500S , получение процент Получает завершен успешно Анкет

Для задержки мы можем указать, что мы заинтересованы в измерении процента запросов, которые возвращают A 200s как код статуса, менее чем в 500 миллисекундах Анкет В качестве реализации мы можем указать, что все действительные события — все 200s и успешные события 200s Это разрешается менее чем за 500 миллисекунд.

Оказывается, определяя действительные события и успешные события для каждого Линейный , мы можем провести все измерения в общей единице, в процентах. Затем, поскольку они проценты, мы можем легко установить цели на них. Эти цели называются SLO (цель уровня обслуживания) , и у них должно быть временное окно, в котором они будут измерены. Например, для доступности мы можем установить SLO из 99,9% , измеряется через все серверы, которые выставляют услугу, и во времена окнах 24 часа. Точно так же мы можем определить другой SLO Для задержки, определяя, что мы хотим, по крайней мере, 95% из запросов GET, которые заканчиваются 200s , чтобы быть завершенным менее чем 500 мс , измеряется через все серверы, которые обнажают сервис, в 24 -часовые временные окна.

Это пример одного из наших приложений. Он раскрывает услугу для получения событий и обработки их асинхронно. В этой службе мы выбираем 3 Слава : доступность , задержка и прошедшее время с момента появления события, пока оно не завершит обработку Анкет

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

Очень важной темой в нашей системе мониторинга является оповещения. При использовании неправильного использования они могут создавать больше проблем, чем если бы у нас их не было.

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

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

• Привыкайте иметь ложные срабатывания и не увидеть важную тревогу вовремя.
• Тратить время. Как говорится в книге SRE, Paging a Cans — это довольно дорогое использование времени сотрудника. Если сотрудник работает, страница прерывает их рабочий процесс, и если сотрудник находится дома, страница прерывает их личное время.
• Деморализовать, демотивировать, генерировать плохую предрасположенность к мониторингу.

Мы оставляем некоторые вопросы, которые мы в основном отвечаем из книги Google SRE, которые, по нашему мнению, могут служить руководством по настройке сигналов:

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

Что мы делаем с нерарочных оповещениями? Например, узел в кластере не работает. Другой канал связи может быть использован для этого типа уведомления. Тот, который проверяется в рабочее время, и это является частью задач по техническому обслуживанию, а не охраны.

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

Ну, теперь давайте посмотрим на это для всех остальных, есть Наблюдаемость инструменты. И мы будем кратко рассмотреть самые важные из них, поскольку они дополняют нашу систему мониторинга, чтобы помочь в Устранение неполадок и отладка Анкет

Цели Наблюдаемость отличаются от мониторинга. Наблюдаемость направлена на то, чтобы позволить нам узнать на самом высоком уровне детализации, поведение и внутреннее состояние нашей системы, с богатым контекстом .

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

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

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

Затем мы кратко рассмотрим наиболее широко используемые инструменты наблюдения в контексте распределенных систем.

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

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

Некоторые предложения, которые следует иметь в виду при добавлении журналов:

• Генерировать журналы с контекстом. Либо идентификатор по запросу, либо что -то, что позволяет нам удобно коррелировать журналы.
• Стандартизируйте журналы, чтобы иметь одинаковый тип информации на каждом уровне журнала.
• Когда это возможно, используйте структурированные журналы, чтобы они не ограничивались чтением человеком, но также могут быть обработаны программно. Затем вы можете легко сгруппировать, собирать, генерировать метрики на лету, индекс по определенным полям и т. Д.

Что касается структурированных журналов, мы оставили изображение, представленное в говорить в Графанакон этого года. Вы можете увидеть, как через некоторые строки журналов это может легко генерировать метрику о количестве запросов по конечной точке и коде состояния, которые могут быть очень полезны в середине инцидента в производстве. В этом случае они делают это с запросом на Локи , используя Logql , язык запросов, похожий на Promql от Прометей Анкет

Вот пример того, как мы перечислим журналы приложения, в этом случае приложение называется Data-Stream-in И мы используем Локи Анкет

Вот еще один пример, отфильтровывать только Предупреждения .

А вот еще один пример, генерируя метрику количества журналов в минуту, сгруппированной по уровню. В этом случае мы видим, что у нас есть журналы Информация и в Предупреждение уровень.

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

В дополнение к показателям самой системы, таких как задержка, пропускная способность, ошибки и насыщение, важно учитывать другие аспекты, лежащие в основе системы. Аспекты, подобные Икота на VMS , использование ЦП и количество пауз, введенных GC являются некоторые из тех, которые также должны быть замечены, чтобы лучше понять производительность нашей системы.

Вот пример системных метрик, которые мы принимаем на нашу виртуальную машину.

Трассировка — это еще один очень полезный инструмент, который позволяет вам не только анализировать и отвечать на вопросы о конкретном приложении, но и отвечать на вопросы, связанные с взаимодействием набора приложений вдоль потока, который выполняется одним запросом.

A трассировка это набор отдельных событий (называемый span ), которые создаются родительским событием. Часто корневой пролет — это запрос. Интересно, что он легко показывает Причинность событий которые связаны с определенной трассой и могут быть визуализированы на одном изображении. На некоторые интересные вопросы, на которые можно ответить:

• Какой путь пошел по запросу?
• Где узкое место, которое замедляет все выполнения?
• Сколько времени он производит по сдержке сети?
• Что происходит в каждой службе, для конкретного запроса?

Это слайд взят из Разговор о распределенной трассировке Что мы дали несколько лет назад, мы оставили ссылку на презентацию.

Это пример распределенного отслеживания между двумя приложениями. Вы можете легко визуализировать пространство во времени, которое имело каждое применение, и ряд интересных деталей в каждом Span , например, Заголовки , времена , Код статуса , так далее.

В итоге:

• Используйте Четыре золотого сигнала и Используйте метод контролировать наши услуги.
• Прикажите ваши услуги как можно скорее.
• Комбинация Профилирование , журналы и следы , как вспомогательные инструменты для устранения неполадок.
• Итатерация Анкет Это итеративный процесс. Начните с нескольких метрик и нескольких вопросов, как мы сказали, сохраняют это простым, и итеративно развивайте вашу систему мониторинга.

После разработки всех этих тем, некоторых открытых вопросов и других, не настолько открытых, что мы можем думать:

Некоторые из предыдущих вопросов доставят нас к линии мысли, где управляемость — это окончательный конец наблюдения , и в системе, которая контролирует себя от его динамизма и где она не одинока во вселенной, но общается, посылая и получая сигналы, которые влияют друг на друга, и что со временем помогает выводить состояние других и состояния себя.

Если мы следуем этой идее управляемость Мы попадаем в Теория контроля Это 2000 лет назад использовалось египтянами в водных часах ( clepsydra ), или позже, во Второй мировой войне, где было разработано некоторые оружия на основе этой идеи, такой как зенитное оружие.

Он интенсивно используется в:

• Контроль процесса.
• Электроника.
• Аэрокосмическая промышленность.
• Производственная автоматизация.

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

Если мы думаем в коде, внутри while (true) У нас есть текущее и желаемое состояние, и мы всегда стараемся достичь желаемого значения, применяя исправления с петлей обратной связи.

while (true) {
    currentState = getCurrentState()
    desiredState = getDesiredState()
    makeConform(currentState, desiredState)
}

Некоторые известные примеры, где он уже используется:

• Скорость управления автомобилем.
• CPU Cooler, где метрика, которую он отслеживает, является температурой, и то, что он регулирует, является напряжением, приложенным к охладителю.
• Kubernetes и автоматическое использование Pid (Пропорциональная, интегральная, производная) петля с некоторыми проверками и другими гаджетами.
• Плоскость управления от Amazon Анкет

Спасибо!!

Оригинал: «https://dev.to/dpsoft/monitoring-production-methodologically-talk-with-transcript-80g»