Является ли Istio metri c "istio_requests_total" количеством обслуженных запросов? - PullRequest
2 голосов
/ 08 мая 2020

Istio имеет несколько показателей по умолчанию, например istio_requests_total, istio_request_bytes, istio_tcp_connections_opened_total. Прокси-сервер Istio envoy вычисляет и предоставляет эти показатели. На веб-сайте Istio он показывает, что istio_requests_total - это СЧЕТЧИК, увеличиваемый для каждого запроса, обрабатываемого прокси-сервером Istio.

Мы провели несколько экспериментов, в ходе которых мы пропускали множество запросов go через посланника Istio, чтобы достичь микросервиса, стоящего за посланником Istio, и в то же время мы отслеживали метри c от посланника Istio. Однако мы обнаружили, что istio_requests_total не включает запросы, которые прошли через Istio envoy к серверной микросервисе, но их ответы не поступили в Istio envoy от внутренней микросервиса. Другими словами, istio_requests_total включает только количество обслуженных запросов и не включает запросы в полете.

Мой вопрос: правильно ли наше наблюдение? Почему istio_requests_total не включает запросы в полет?

1 Ответ

1 голос
/ 11 мая 2020

Как упоминалось здесь

Метрики по умолчанию представляют собой стандартную информацию о запросах и ответах HTTP, gRP C и TCP. О каждом запросе сообщается также исходным прокси и целевым прокси, и они могут предоставлять различное представление о трафике c. О некоторых запросах может не сообщать место назначения (если запрос вообще не достиг места назначения), но некоторые метки (например, connection_security_policy) доступны только на стороне назначения. Вот некоторые из наиболее важных HTTP-метрик:

istio_requests_total - это СЧЕТЧИК, который агрегирует итоги запросов между рабочими нагрузками Kubernetes и группирует их по кодам ответа, флагам ответа и политике безопасности.

Как упоминалось здесь

Когда Mixer собирает метрики от Envoy, он назначает измерения, которые нижестоящие серверные ВМ могут использовать для группировки и фильтрации. В конфигурации Istio по умолчанию измерения включают атрибуты, указывающие, где в вашем кластере перемещается запрос, например имя службы происхождения и назначения. Это дает вам видимость c трафика в любом месте вашего кластера.

Метри c для просмотра: requests_total

Метрич. Счетчика запросов c указывает общую пропускную способность запросов между службами в вашем me sh и увеличивается каждый раз, когда сопроводительный файл Envoy получает HTTP или gRP C запрос. Вы можете отслеживать этот метрич c как по службе отправления, так и по службе назначения. Если количество запросов между одной службой и другой резко упало, либо источник прекратил отправку запросов, либо пункт назначения не смог их обработать. В этом случае вам следует проверить конфигурацию Pilot, компонента Istio, который направляет трафик c между службами. Если наблюдается рост спроса, вы можете соотнести этот показатель c с увеличением показателей ресурсов, таких как загрузка ЦП, и убедиться, что ваши системные ресурсы масштабируются правильно.

Возможно, стоит проверить документацию envoy об этом, из-за того, что написано здесь

В приведенных выше запросах используется метрика istio_requests_total c, которая является стандартной метрикой Istio c. Вы можете наблюдать и другие показатели, в частности, Envoy (Envoy - дополнительный прокси Istio). Вы можете увидеть собранные метрики во вставке метрики c в раскрывающемся меню курсора.

Основываясь на приведенных выше документах, я согласен с тем, что @Joel упомянул в комментариях

Я думаю, что вы правы, и я предполагаю, что «почему» связано с флагами ответа, которые, как ожидается, будут находится на этикетках метри c. Это может быть записано только при получении ответа . Если бы они захотели поступить иначе, я полагаю, это означало бы наличие двух разных счетчиков, один для отправленного запроса и один для полученного ответа.

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