На компьютере Windows с несколькими сетевыми адаптерами (Ethernet, Wi-Fi, VPN) для корректной маршрутизации трафика иногда нужно вручную настраивать приоритеты сетевых подключений. Например, при наличии одновременного подключений к сети через Wi-Fi и Ethernet, вы можете изменить приоритеты сетевых адаптеров так, чтобы по-умолчанию трафик всегда отправлялся через проводное подключение.
Windows автоматически назначает приоритеты сетевым адаптерам в зависимости от скорости подключения. Чем выше скорость подключения, тем более высокий приоритет такого сетевого адаптера (меньше значение метрики). Обычно Windows использует следующий порядок приоритетов для различных типов сетевых интерфейсов:
- Ethernet
- Wi‑Fi
- Мобильные подключения
Если компьютер подключен к 100 Мб Ethernet порту и высокоскоростному Wi-Fi роутеру, может оказаться, что беспроводное подключение будет иметь более высокий приоритет.
Вывести информацию о доступных IPv4 сетевых адаптерах в Windows:
Get-NetIPinterface | where AddressFamily -eq "IPv4"
Приоритет сетевого интерфейс определяется значением InterfaceMetric. Чем меньше значение InterfaceMetric, тем выше приоритет сетевого подключения.
Ниже представлены результаты команды с двух разных компьютеров. На первом скриншоте видно, что у Ethernet подключения выше приоритет чем у беспроводного Wi-Fi адаптера. На втором скриншоте два Ethernet интерфейса с одинаковыми приоритетами.
Значение InterfaceMetric это метрика, которая задает приоритет IP маршрута через этот сетевой адаптер в таблице маршрутизации Windows:
route print
В этой таблице маршрутизации видно, что по умолчанию сетевой трафик будет отправлен через интерфейс с меньшей метрикой.
С помощью PowerShell можно проверить, какой сетевой адаптер будет использоваться для доступа в Интернет согласно текущей таблицы маршрутизации:
Get-NetRoute -DestinationPrefix 0.0.0.0/0
В данном случае есть два маршрута с одинаковыми метриками. Это означает, что вы не может гарантировать какой адаптер будет использоваться для доступа в Интернет.
Можно изменить метрики сетевых интересов и назначать приоритеты вручную с помощью PowerShell командлета Set-NetIPInterface. Чтобы уменьшить приоритет одного из интерфейсов, нужно указать его название (
InterfaceAlias
) или индекс интерфейса (
ifIndex
) и новое значение метрики:
Set-NetIPInterface -ifIndex 14 -InterfaceMetric 26
или
Set-NetIPInterface -InterfaceAlias Ethernet1 -InterfaceMetric 26
Проверьте, что значение в таблице маршрутизации изменилась метрика для этого адаптера.
Также вы можете изменить приоритет (метрику) сетевого интерфейса в свойствах сетевого адаптера в панели управления Network Connections (
ncpa.cpl
).
Откройте свойства IPv4 протокола адаптера -> кнопка Advanced -> измените значение в поле Interface metric и примените изменения.
По умолчанию здесь включена опция Automatic metric, которая указывает, что приоритет сетевого адаптера устанавливается автоматически в соответствии со скоростью подключения среды.
В версиях до Windows 10 и Windows Server 2016 можно было изменить приоритет сетевых адаптеров в настройках привязки адаптеров (Adapters and Bindings). В более новых версиях эту опцию убрали.
Время на прочтение5 мин
Количество просмотров3.9K
Привет! Уже довольно продолжительное время занимаюсь метриками в windows. Процесс сбора уже отлажен, и из памяти начинают уходить детали, а поэтому пора перенести полученные знания, так скажем, на бумагу. Статья будет про то, что было, что завезли, как с этим работать, какие будут грабли и костыли к ним. Попутно затронем .net clr, asp.net, wcf, iis, signalr, etw и что-нибудь еще. Статейка для тех кто в теме, ну или почти…
На данный момент метрики в windows можно разделить на две системы: performance counters (пускай будет legacy) и event counters (модно-молодежно).
Performance counters представляет собой не просто бутерброд, а целый салат различных компонентов и кучи точек входа для работы с ними.
И как видно по схеме, все сводится в одну точку PDH, хотя опросить компоненты можно на любом уровне: будь-то advapi, registry или perflib.
Для того, чтобы выдрать данные по метрике, нужно знать ее категорию, счетчик (не путать с типом в prometheus), и (если работать через PDH) тип возвращаемого значения — берете тулзу, передаете параметры, и все вроде бы красиво, даже автоматизация какая-то есть… И вот у вас метрики летят, grafana рисует, картина ясна, но конкретики нет, потому что в инстансах вы видите такое: w3wp#101, _LM_W3SVC_1001_ROOT, —62, C400001640000001, Service@||Service.svc. Но проблески есть — в самом лучшем случае инстанс совпадает по имени с процессом. Красауцы-индусы снова что-то перемудрили. Правда, сообщество предлагает чудо лекарство от этой болезни:
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance
On the Edit menu, click New , and then click DWORD Value .
Right-click New Value #1 , click Rename , and then type ProcessNameFormat to name the new value.
Right-click ProcessNameFormat , and then click Modify .
In the Data value box, type one of the following values, and then click OK :
1 : Disables PID data. This value is the default value.
2 : Enables PID data.
Right-click New Value #1 , click Rename , and then type ProcessNameFormat to name the new value. Right-click ProcessNameFormat , and then click Modify.
1 : Disables PID data. This value is the default value.
2 : Enables PID data.
После этих действий инстанс должен прекрасно читаться: PID_ProcessName. Только не было упомянуто, что распространяется фикс не на все категории метрик, к тому же это может повлиять на какие-нибудь инструменты сбора (могут перестать работать), так что все делается на свой страх и риск. Решение ну очень «ниочень».
Пробежимся по категориям и посмотрим, где и что можно подпереть…
Process
В этой категории инстанс имеет формат имени запускаемого бинаря без расширения, и, если этого бинаря много, например процесс IIS (w3wp), то к нему приклеивается порядковый номер через решетку — w3wp#101 и др. К счастью разработчики кое-что предусмотрели и завезли нам счетчик ID Process, который должен решить задачу сопоставления PID`a к инстансу метрики. Но тут есть подводные камни…
Во-первых, перечитывать соответствие надо будет постоянно (процессам свойственно перезапускаться), а если не перечитывать то инстанс может принадлежать не тому процессу, который вы ожидаете, я бы даже сказал пачка инстансов: допустим у вас выпал 100 экземпляр из 150, так вот все, что после ста, сдвинется на позицию назад, т.е. 150 станет 149 (w3wp#149).
Во-вторых, чтение конкретно этой метрики запускает сбор всего performance по процессу через NtQueryInformationProcess (пациент оказался на столе у профилировщика), а эта вещь очень дорогая и знатно так может подгрузить процессор, и пока вы будете читать, инстансы могут измениться — надо будет снова перечитывать.
В документации по PDH есть функция, которая позволяет получить все доступные метрики нужной категории без чтения значений через wildcard «(*)» (решает проблему производительности)
[
"\\\\localhost\\Process(w3wp#100)\\ID Process",
"\\\\localhost\\Process(w3wp#101)\\ID Process",
...
] Из пути можно взять инстанс и сопоставить его с запущенным процессом, а лучше всего это делать в момент его запуска, но перед этим реактивно обновить список выше. Отслеживание перезапуска процесса с реактивностью можно реализовать с помощью классов .net для работы с ETW. Но тут выскакивает еще один момент, если бинарь ни разу не запускался в системе, то его инстанс в категории будет создан не сразу после первого запуска (это касается всех категорий, которые будут в этой статье). А поэтому не плохо бы следить еще и за изменением инстансов в категории.
ASP.NET Applications
Формат инстанса выглядит следующим образом _LM_W3SVC_1001_ROOT, где 1001 — это идентификатор сайта IIS. К этой категории, как и всем последующим, применим тот же механизм соответствия, за исключением того, что в этот раз необходимо найти не PID, а ID сайта. Способов несколько, но я напишу с чего начал и чем закончил (не все отложилось в памяти).
Для работы с IIS есть относительно неплохая либа, но не для активного использования, во время которого она плюется всевозможными исключениями , для которых нет ни описания, ни решения (смысла в профилировании я не видел), к тому же у нее долго не было апдейтов, и она перестала проходить тесты безопасности — этой поделке место на помойке.
В конце пути единственным надежным и быстрым способом сопоставить метрику к сайту оказалось чтение файла конфигурации IIS. Но не без нюансов: конфигурация вроде бы в xml, а вроде и не совсем стандарт — несколько библиотек не смогло работать с его форматом, активно ругаясь на ошибки в нем. Методом перебора выбор пал на XmlDocument. Пример…
const string section = "/configuration/system.applicationHost/sites/site"
XmlNodeList nodes = doc.DocumentElement.SelectNodes(section);
foreach (XmlNode node in nodes)
{
w3svcs.TryAdd($"_LM_W3SVC_{node.Attributes["id"].Value}_ROOT", node.Attributes["name"].Value);
}ServiceModelService 4.0.0.0
В документации WCF есть описание формата инстанса, но как показала практика он может слегка отличаться — сейчас я вряд ли найду пример, и вам придется поверить мне на слово. Но даже если следовать описанному паттерну, то для формирования инстанса из конфига SVC нужно вычитать имя сервиса, контракт и его эндпоинт. А программисты — народ ленивый, берут чужой конфиг, добавляют свое, и на выходе получаем из одного конфига несколько сервисов. Идентификация инстанса к запущенному сервису не представляется возможным. Было принято решение слать метрики из этой категории как есть, но предоставить визуальную идентификацию на стороне grafana.
HTTP Service Url Groups
Инстанс этой категории по истине экзотический — C400001640000001. Даже предположить сложно, как это можно привязать к процессу. Но частично решение есть — прям самый жирный костыль из всего, что описано выше. Этот инстанс можно подсмотреть, выполнив команду:
netsh http show servicestate view=requestq verbose=noRequest queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs:
33800
URL groups:
URL group ID: C400001640000001
State: Active
Request queue name: Request queue is unnamed.
Number of registered URLs: 1
Registered URLs:
HTTP://+:80/health/
Server session ID: EF00001020000031
Version: 2.0
State: ActiveЗдесь уже есть нужная информация: URL group ID (наш инстанс) и Process IDs, по которому и можно сделать привязку к метрике.
Немного покопавшись в интернете, можно найти API для работы с URL groups, но выйти на процесс можно только через сессию (Server session ID), а его интерфейс, к сожалению, закрыт для использования.
Практика показала, что значения групп с перезапуском процесса меняется редко. И единственный, способ, который я смог применить, это банальная регулярка «@»Process\sIDs:[^\d]?(\d+).?URL\sgroup\sID:\s([a-zA-Z0-9]+)», которая применяется к выхлопу команды — не быстро и не надежно, но что есть, то есть.
SignalR
Этой категории нет по умолчанию в системе performance counters. Чтобы она появилась, нужно пнуть ее по вот этому мануалу. Но «пиналка» у меня стабильно не заработала: метрики то появлялись, то исчезали. Костыль подобрать я не смог.
Система performance counters полна загадок и тайн. Работать с ней не легко, и, к сожалению, многие новые продукты (собственно, как и сам microsoft) продолжают ее активно использовать. Статья получилась не маленькой, многие вещи могут показаться непонятными, а детали реализации не раскрытыми.
Event Counters я решил перенести в другую часть… Вопросы приветствуются!!!
Что такое Метрика сети или маршрута
В локальный сетях есть такое понятие Метрика сетевого интерфейса или Метрика Сети — это специальное цифровое значение, означающее число переходов (так называемых «хопов» или «прыжков»), которое влияет на выбор маршрута в сети. В таблице маршрутизации из двух одинаковых предпочтительным является тот маршрут, у которого лучшая метрика маршрута.
На сегодняшний день в операционных системах Windows, Linux, MAC OSX, Android, iOS по умолчанию используется автоматическое назначение метрики сетевого интерфейса. В Windows 10 эту опцию можно отключить или включить в Дополнительных параметрах протокола TCP/IP v4.
Посмотреть текущие значения этого параметра для каждого динамического маршрута можно через командную строку, введя команду route print. Пример вывода директивы Вы можете видеть ниже:
При использовании статической маршрутизации возможно прописать значения параметра вручную при указании статического маршрута.
При этом все устройства в локальной сети считаются одним промежуточным звеном, а маршрутизатор, который встретится на пути к точке назначения — дополнительным устройством.
Метрика сети может выставляться не только исходя из числа переходов, но и на основе информации о скорости соединения сетевых интерфейсов.
У самого медленного интерфейса будет самое большое значение параметра и низший приоритет, а у самого быстрого — наименьшее и высший приоритет.
| Скорость интерфейса | Значение метрики сети |
| Менее 500 Кбит/с | 50 |
| от 500 Кбит/с до 4 Мбит/с | 40 |
| от 4 Мбит/с до 20 Мбит/с | 30 |
| от 20 Мбит/с до 80 Мбит/с | 25 |
| от 80 Мбит/с до 200 Мбит/с | 20 |
| от 200 Мбит/с до 2 Гбит/с | 10 |
| от 2 Гбит/с и выше | 5 |
Кстати, надо учитывать что в операционных семействах на основе UNIX (Linux, Android и т.п.) метрика сети используется только для протоколов динамической маршрутизации и особо замарачиваться не стоит, так как при выборе маршрута ядро Линукса игнорирует этот параметр.
windowMetrics
Windows Metrics is a Java Based service that logs what process/windows you have active. It is intended to include a GUI for analysis and categorization. Currently, only the logging portion is working.
Building Window Metrics
Window Metrics uses the Gradle build system. You should just be able to checkout a branch of the repo and then run
- gradle oneJar — This will create a Jar located at build/libs/windowMetrics-0.1-SNAPSHOT-standalone.jar
Additionally, an IntelliJ Project file has been included.
Running Window Metrics
Once you have a jar from the build, you will need to src/dist/config.yml to your needs. Most likely your database configuration will change. TODO: Add example DB configs for common DBSs
You can now launch the service using your config like so
java -jar windowMetrics-0.1-SNAPSHOT-standalone.jar server /path/to/config.yml
IP routing involves metrics. This is the cost of each route. If there are multiple routes to a destination then the route with lowest metric/ cost is chosen.
In the context of Windows OS there are two metrics that come into play.
One is the metric of the interface/ NIC itself (that’s the “Automatic metric” checkbox above). By default its set to automatic, and this determines the cost of using that interface itself. For example if both your wireless and wired connection can access the Internet, which one should the machine choose? The interface metric is used to make this decision. You can assign a value to this metric if you want to force a decision.
Each interface can have multiple gateways to various networks it knows of. Could be that it has more than one gateway to the same network – say, your wired connection can connect to the Internet from two different routers on your network, which one should it choose? Here’s where the gateway metric comes into play (circled in the screenshot above). By default when you add a gateway its metric is set to automatic, but here too you can assign a value.
So far so good. Now how does all this come into play together?
The first thing to know is that gateway metrics have a value of 256 by default (when set to “Automatic metric”). So if you have more than one gateway to a particular destination, and the metric is set to automatic, then by default both gateways have a metric value of 256 and hence equal preference. Remember that.
The next thing to know is that interface metrics have a value ranging from 5 to 50 (when set to “Automatic metric”) based on the speed of the interface. Lower numbers are better than higher numbers. See this KB article for the numbers, here’s a screenshot from that article.
So if you have two wired connections for instance, one of speed 1 GB and other of speed 10 GB, then the 1 GB interface has a metric of 10 and the 10 GB interface has a metric of 5 – thus making the latter preferred.
To view the interface & gateway metrics assigned to your interfaces use the netsh interface ip show address command:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
C:\WINDOWS\system32>netsh interface ip show address Configuration for interface «Local Area Connection* 2» DHCP enabled: Yes InterfaceMetric: 5 Configuration for interface «Ethernet» DHCP enabled: Yes IP Address: 10.136.20.16 Subnet Prefix: 10.136.20.0/24 (mask 255.255.255.0) InterfaceMetric: 10 Configuration for interface «Ethernet 2» DHCP enabled: Yes IP Address: 10.171.1.6 Subnet Prefix: 10.171.1.4/30 (mask 255.255.255.252) Gateway Metric: 5 InterfaceMetric: 20 |