Чем больше метрика тем

Объяснение функции автоматической метрики для маршрутов IPv4

В этой статье описывается функция Automatic Metric, которая используется в Windows для маршрутов IPv4 протокола Интернета.

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2012 R2, Windows Server 2008 R2 Пакет обновления 1
Исходный номер КБ: 299540

Дополнительные сведения

Метрика — это значение, назначенное маршруту IP для определенного сетевого интерфейса. Он определяет затраты, связанные с использованием этого маршрута. Например, метрика может быть оценена с точки зрения скорости ссылок, хмеля или задержки времени. Автоматическая метрика — это новая функция в Windows, которая автоматически настраивает метрику для локальных маршрутов, основанных на скорости ссылок. Функция Automatic Metric включена по умолчанию, а также может быть настроена вручную для назначения определенной метрики.

Функция Automatic Metric может быть полезна, если в таблице маршрутов содержится несколько маршрутов для одного и того же назначения. Например, если у вас есть компьютер с сетевым интерфейсом 10 мегабит (Мб) и сетевым интерфейсом 100-Мб, а на компьютере установлен шлюз по умолчанию, настроенный на обоих сетевых интерфейсах, функция Automatic Metric назначает более высокую метрику более медленному сетевому интерфейсу. Эта функция может заставить весь трафик, предназначенный для Интернета, использовать самый быстрый доступный сетевой интерфейс.

Как правило, Корпорация Майкрософт не рекомендует добавлять шлюзы по умолчанию в разных сетях. Например, для подключения двух или более несогласоваемых сетей, таких как сетевой перевод адресов (NAT) и прокси-серверы, обычно настроены две или несколько несогласоваемых сетей: общедоступный Интернет и одна или несколько частных интрасетей. В этой ситуации не следует назначать шлюзы по умолчанию на частных интерфейсах, так как это может привести к неправильной маршрутике в сети.

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

В следующей таблице перечислены скорости ссылок и назначены метрики для компьютеров, Windows XP Пакет обновления 2 и более новых версий Windows операционных систем.

В следующей таблице перечислены скорости ссылок и назначены метрики для компьютеров, Windows 10 и более новых версий Windows операционных систем:

Для интерфейсов с физическими средними типами NdisPhysicalMediumWirelessLan, NdisPhysicalMediumWirelessWan, NdisPhysicalMediumNative802_11:

Для других типов интерфейсов:

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

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

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

Функция Automatic Metric отличается от функции обнаружения мертвых шлюзов, которая может заставить сеть переключать шлюзы по умолчанию, основанные на ретрансляции протокола управления передачей (TCP). Кроме того, функция маршрутного и удаленного доступа не активирует функцию обнаружения мертвых шлюзов. Эта активация выполняется Стеком TCP/IP на компьютере, который инициирует сеанс TCP.

Чтобы настроить функцию Automatic Metric:

Источник

Windows. Выбрать подключение для интернета

Компьютер может быть одновременно подключён к нескольким сетям и любую из них использовать для Интернет-доступа. При этом для выхода в глобальную сеть, на самом деле, используется только одна сеть, а другая (или другие) находятся в резерве. Операционная система выбирает то подключение, которое обладает лучшими характеристиками.

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

Смотрим таблицу маршрутизации

Открываем PowerShell и выполняем команду:

Особое внимание надо обратить на строки, выделенные красным и зеленым. Сетевой адрес 0.0.0.0 и маска сети 0.0.0.0 это обозначение маршрута по умолчанию (default route). Это тот маршрут, куда отправляется трафик, для которого явно не прописан другой маршрут.

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

Для выбора Интернет-подключения по умолчанию нужно изменить маршрут по умолчанию.

Изменение маршрута по умолчанию

Вернёмся к ранее полученным данным о маршруте по умолчанию:

Есть два способа изменить маршрут по умолчанию. Первый — изменить значение метрики так, чтобы приоритетным стал другой маршрут. Второй — удалить другие маршруты, оставив только один.

Как установить метрику

Для начала удалим все маршруты по умолчанию:

Теперь добавляем тот, который нужно сделать маршрутом по умолчанию:

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

Чтобы в качестве резервного было активно и второе подключение, но по умолчанию не использовалось — добавляем еще один маршрут по умолчанию:

Здесь 192.168.110.1 — IP-адрес шлюза «резервного» интерфейса. Здесь важно знать, что значение метрики 100 является не абсолютным, а относительным. Указанная величина добавляется к тому значению метрики, которое рассчитывает операционная система. Это значение нужно выбрать так, чтобы в сумме с рассчитанной метрикой получилось больше, чем метрика подключения, которое должно использоваться по умолчанию.

Проверяем, что получилось в итоге:

Создание постоянных маршрутов

Источник

Как обложить сервис метриками и не облажаться

Меня зовут Евгений Жиров, я разработчик в инфраструктурной команде Контур.Экстерна. Этот пост — текстовая версия моего доклада с недавнего митапа Perm Tech Talks.

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

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

Я расскажу о нескольких примерах из своей работы и поделюсь советами.

Какие бывают метрики?

Количественные метрики. Самая простая метрика для любого веб-сервиса — это число запросов, которые влетают в него в единицу времени. Обычно эту метрику называют RPS, requests per second.

Вот пример. У этого сервиса три реплики, и суммарно в них влетает почти 400 запросов в секунду. Этот график очень простой, но даёт много информации. Видно, что нагрузка равномерно распределяется по репликам сервиса, каждая реплика получает примерно равное количество запросов. Значит, с настройками балансировщиков всё в порядке.

Интервалы времени. Это более интересные метрики. Обычно их отображают в перцентилях. Например, этот график читается так: 99% запросов на поиск выполняются быстрее, чем 25 мс; а 95% запросов — быстрее, чем 3 мс.

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

На графике метрики одного из кластеров Cassandra — значение load average, поделённое на количество процессорных ядер. По ним можно определить, проседает ли наш кластер по CPU и нужно ли добавить больше железа. Здесь видно, что сейчас значение около 12% и пока CPU хватает.

Ещё на графике виден профиль нагрузки. Здесь день, ночь, снова дневной пик активности и спад к вечеру. Важно знать, когда у приложения пиковая нагрузка. Часто бывает, что приложение в среднем не нагружено, а потом в него прилетает 10 000 запросов, и всё тормозит.

Зачем нужны метрики?

Метрики — это наши «глаза». Без метрик невозможно судить о нагрузках, производительности и отказоустойчивости приложения.

Как начать собирать метрики?

Чтобы хранить собранные метрики, вам нужна база данных. А чтобы рисовать графики — интерфейс для визуализации метрик. Мы в Контуре используем общепринятые Graphite и Grafana.

Вы всё настраиваете, разворачиваете своё приложение, но однажды понимаете, что облажались. Например, не смогли предвидеть поломку. Или просто не понимаете, что значат числа, которые вы собираете. Вот несколько примеров из моей работы.

Пример 1. Cargo programming

Все истории начинаются одинаково. Утром, примерно в 2 часа дня, я прихожу на работу. Смотрю на графики и внезапно вижу ошибки от любимого сервиса.

Огромный пик! Хотя нет. Высота пика по вертикальной оси — всего 4×10 –17 ошибок в минуту. При этом с сервисом всё в порядке, в логах чисто. Начинаю разбираться.

Смотрю, что было с сервисом 15 часов назад. Здесь пик побольше и значения более адекватные. Но какая метрика отображается на графике? Errors per minute. Только вдумайтесь: 0,4 ошибки в минуту. Это немножко странно, потому что приложение отправляет количество ошибок каждую минуту. Это должно быть целое число: 0, 1, 2 или 100, но никак не 0,4. Здесь что-то не так. Как часто бывает при первой встрече с чем-то странным, решаю проигнорировать. Иду дальше писать код.

Правда, проблема не отпускает и преследует на других графиках.

Вот график с временем чтения и записи в Cassandra. Синие линии — ошибки записи в базу данных. Эти метрики отправляет даже не мой код, а сама Cassandra. Получается, что в 10:10 начались ошибки и кончились в 10:35. Целых 25 минут Cassandra не работала.

А сколько минут на самом деле была проблема? Вот клиентские метрики, то есть метрики сервисов, которые пишут в эту базу. Совершенно другая картина: в одну минуту было 50 тыс. проваленных записей, а потом всё снова стало хорошо.

Когда что-то происходит во второй, третий, четвёртый раз — пора разобраться, что происходит. Как проще всего сделать? Нужен лабораторный эксперимент. Пишем тривиальный счётчик, который потокобезопасно считает количество событий, а потом в бесконечном цикле отправляет значение в Graphite и спит минуту.

Пишем два теста. В одном используем свой Counter, который работает понятным образом. В другом используем счётчик из популярной библиотеки. В моём случае это Meter из Metrics.NET, у него похожий интерфейс.

Какую нагрузку считаем? Пусть 2 минуты будет 10 RPS, потом в течение 10 секунд — 100 RPS, а потом снова 10 RPS в течение 2 минут. Вот график:

Зелёная линия — то, что на самом деле происходило с сервисом. А жёлтое — то, что даёт популярная библиотека. Не очень-то похоже.

Вот ещё один пример. Для реального значения метрики 100 получается 54 путём взвешенного сложения всех предыдущих точек. Коэффициенты уменьшаются в геометрической прогрессии, и получается странное сглаженное значение.

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

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

Наверняка многие из вас видели утилиту top в *nix. Она показывает три числа load average (за 1 минуту, 5 минут и 15 минут), сглаженные похожим образом. По ним нельзя судить о точном значении, но хорошо виден тренд. Например, можно увидеть, что за 15 минут нагрузка процессора серьёзно выросла. Тут сглаживание помогает, потому что с ним шумная метрика меняется гладко, а не болтается от 0 до 100.

Пример 2. Сonsolidation

Ещё бывают проблемы с визуализацией метрик.

Прихожу я опять на работу, смотрю на графики. Вот 95-й перцентиль времени поиска. Видно, что утром поиск тормозил: 550 мс у одной из точек, есть и другие пики. Может быть, это нормальное поведение сервиса? Надо изменить масштаб и посмотреть, сколько таких пиков было за неделю.

Здесь тоже много пиков. Но тот самый, в 6 утра, поменял своё значение! Теперь 276 мс. Как такое может быть?

Причина в стратегии объединения точек — consolidate by в Graphite. Когда вы изменяете временной масштаб, и все точки не помещаются на экран, Graphite объединяет их с помощью выбранной функции. Бывают разные, но по умолчанию это среднее, которое плохо подходит для этого графика. Обычно в случае перцентилей интересуют максимумы, иногда хочется взять сумму.

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

Пример 3. Графики врут

Опять прихожу на работу, открываю график, а там совсем всё плохо. Уже сутки сервис стабильно возвращает 503 ошибки каждую минуту. Здесь-то в чём проблема? Она очень простая и забавная: просто недостаточно данных для визуализации.

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

Что делать? Писать в метрики нули, если ошибок не было, или использовать другой тип графика — например, столбики.

Пример 4. Физический смысл метрик

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

В моём случае одно из приложений начало падать из-за access violation. Я понял, что причина именно в нехватке памяти, но по метрикам всё было отлично — подумаешь, 40 МБ, ничего страшного.

На самом деле, конечно, нет такой метрики — «сколько памяти использует приложение». Метрик для оперативной памяти много. Например, у каждого процесса в Windows есть working set и private bytes. Если грубо, working set — это объём занятой физической памяти, а private bytes — сколько памяти вообще выделило приложение. У приложения может быть куча данных в файле подкачки, но почти ничего в физической памяти. Приложению будет плохо, и оно развалится.

Надо помнить, что нет таких простых метрик как «память» или «загрузка процессора». Метрик больше, и они все значат что-то конкретное.

Выводы

А как вы собираете и визуализируете метрики? Какие сложности со сбором метрики и их отображением были у вас?

Источник

Какие бывают метрики. Дизайнер и метрики, 2 часть

Вы читаете вторую статью из серии «Дизайнер и метрики». В первой статье я пытался ответить на вопрос, нужны ли дизайнеру метрики. Ее можно найти тут.

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

Retention — метрика, на которую я смотрю чаще всего

Предлагаю не вдаваться в теорию, а сразу взять конкретную метрику и посмотреть, что это такое и как она работает.

Начнем с retention — метрика, которая показывает возвращаемость пользователей. То есть, если сегодня наше приложение скачало 100 новых пользователей, то retention ответит на вопрос, сколько из них к нам вернется завтра, через месяц и так далее.

Допустим, что retention второго дня равен 60% — это значит, что на второй день приложение запустят 60 пользователей из 100 скачавших.

Эту метрику можно посчитать на любой день жизни пользователя. Допустим, retention 7 дня равен 30% — это означает, что на 7 день с момента скачивания в нашем приложении останется 30 человек из 100 скачавших.

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

В итоге мы берем каждого пользователя, смотрим на его «второй день», и считаем, зашел он в сервис или нет. Затем смотрим, какой процент все-таки зашел — это и будет показатель retention второго дня.

Допустим, наше приложение скачали 1000 раз за неделю. Во второй день из этой тысячи зашли 600 пользователей, а в седьмой — 300. Используя эти данные, мы можем посчитать retention второго дня — 600/1000 = 60%, и retention седьмого дня — 300/1000 = 30%

Чем полезна эта метрика?

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

Если retention какого-то дня составляет 0%, значит, из всех, кто когда-то скачивал приложение, никто в нем не остался, и приложение никому не нужно. Может, стоит его закрыть?

Хочу сразу отметить, что в некоторых приложениях retention нужно трактовать иначе — допустим, дейтинг. Пользователь нашел пару — больше условный «Тиндер» ему не нужен.

Но чаще всего цель разработки приложения — найти пользователей, которые будут пользоваться им в течение длительного времени. То есть, с какого-то дня retention должен перестать убывать — retention 90 дня должен быть равен retention 180 дня и так далее. В таком случае аналитики говорят, что retention вышел на плато.

Если у продукта большая и постоянно растущая аудитория, это свидетель того, что продукт вышел на плато retention — как Facebook, Telegram, Google Maps и так далее.

Метрики роста и метрики продукта

Отойдем на шаг назад и посмотрим, какие вообще бывают метрики. Выделяют 2 типа: метрики роста и метрики продукта

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

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

А метрика роста — это то, что получается после этой «переработки», например выручка компании за год.

Как думаете, retention — это метрика роста или метрика продукта?

Определить это поможет очень простое правило: увеличьте в разы количество пользователей, скачавших приложение. Если показатели метрики при этом не изменятся, значит, это метрика продукта.

Допустим, мысленно сравняйте количество пользователей своего приложения с количеством пользователей Facebook. Retention приложения при этом останется неизменным. Как был 30% на седьмой день, так и останется. А значит, Retention — это метрика продукта.

А что произойдет с выручкой? Выручка при увеличении аудитории заметно взлетит. Если один пользователь приносил нам 10₽, то 100 пользователей принесут нам 1 000 ₽, а 1 000 000 пользователей — 10 000 000 ₽. Получается, что выручка (или revenue) — это метрика роста.

Итак, метрики роста отвечают на вопросы:

— Растет или падает дневная аудитория нашего приложения?

— Сколько зарабатывает наш продукт?

А метрика продукта:

— Сколько денег нам приносит один средний пользователь?

— Какая часть пользователей остается с нами спустя месяц после установки приложения?

Зачем разбираться в метриках роста и продукта

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

Конечно, проще всего было бы ответить на эти вопросы, посмотрев на метрики роста. Мол, если мы стали больше зарабатывать — значит, все не зря, а если начали зарабатывать меньше, то что-то идет не так.

Но в этом подходе кроется ошибка, которая может стоить продукта.

Чтобы лучше разобраться, почему при оценке дизайна или редизайна не стоит опираться на метрики роста, давайте разберем следующий кейс:

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

Команда выкатывает эту фичу — и она оказывается неудачной. Метрики продукта — то есть, retention, возвращаемость пользователей — летят вниз. Продукт начинает хуже удерживать пользователей, доход на нового пользователя уменьшается.

Но из-за того, что в продукт было привлечено намного больше трафика, новые пользователи маскируют ухудшение в метриках продукта и компания начинает зарабатывать больше. Потому что на метрики роста влияет 2 составляющих — сам продукт и его продвижение.

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

Такой случай — не редкость в компаниях.

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

Подытожим

Что дальше

Это была 2 статья из серии «Дизайнер и метрики». В следующей статье я планирую рассказать как сравнивать изменение метрик что было до релиза и что стало после, как понять улучшили мы продукт или нет. Подписывайтесь, чтобы не пропустить.

Источник