Microsoft AZ-700: Мониторинг сети и устранение неполадок — Руководство по подготовке
Часть Microsoft Azure Network Engineer AZ-700 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.
Инструменты и источники данных для наблюдаемости
Наблюдаемость в сетях Azure сосредоточена вокруг Network Watcher, Azure Monitor (Log Analytics) и параметров диагностики, которые передают телеметрию от ресурсов в центральную рабочую область или учетную запись хранения. Network Watcher предоставляет функции захвата пакетов, проверки потоков IP, определения следующего перехода, устранения неполадок с подключениями и Монитор подключений (Connection Monitor); Connection Monitor v2 поддерживает тесты с несколькими конечными точками и протоколами, а также сохраняет результаты в рабочей области Log Analytics для запрашиваемой телеметрии. Журналы потоков NSG включаются через Network Watcher и записывают JSON-записи в учетную запись хранения; включение Traffic Analytics (для которой требуются журналы потоков и рабочая область Log Analytics) обогащает эти журналы данными о приложениях/геолокации и визуализацией. Параметры диагностики для Azure Firewall, Application Gateway/WAF, Front Door и балансировщиков нагрузки следует направлять в одну и ту же рабочую область Log Analytics для корреляции сигналов. Распространенные ловушки включают правила брандмауэра учетной записи хранения, блокирующие запись журналов потоков, забывчивость включить Network Watcher для каждого региона в старых клиентах (tenants) и несогласованные политики хранения для учетных записей хранения и Log Analytics. Компромиссы между стоимостью и возможностями очевидны: запись необработанных журналов в учетную запись хранения для дешевого архивирования в сравнении с приемом данных в Log Analytics для выполнения запросов и оповещений (более высокая стоимость, но значительно большая диагностическая ценность). Управление доступом на основе ролей (роли Monitor Reader и, где требуется, Storage Blob Data Reader) должно быть настроено так, чтобы конвейеры диагностики могли записывать журналы, а аналитики — их читать.
Захват пакетов, Connection Monitor и глубокая диагностика
Для устранения неполадок на уровне пакетов функция захвата пакетов Network Watcher (через портал/CLI/PowerShell) создает файлы PCAP в учетной записи хранения или в локальном файле на ВМ. Настройте фильтры захвата пакетов (протокол, IP-адреса источника/назначения, порты) и ограничения по размеру/времени, чтобы избежать избыточного использования хранилища и влияния на производительность. Для ВМ с высокой пропускной способностью и ускоренной работой в сети видимость пакетов на стороне хоста может быть ограничена; используйте VNet TAP для зеркалирования трафика на ВМ-сборщик или NVA, чтобы не пропустить разгруженные (offloaded) пакеты. Connection Monitor следует использовать для активных синтетических тестов: определите начальную и конечную точки (IP, FQDN, порт), выберите частоту тестирования и включите захват задержки на каждом переходе и пути для диагностики многосегментных соединений. Используйте проверку потоков IP (IP Flow Verify), чтобы проверить, разрешен или запрещен конкретный 5-кортеж правилами NSG/UDR, и функцию следующего перехода (Next-hop) для подтверждения эффективной маршрутизации. Остерегайтесь подводных камней: захват пакетов на ВМ Windows может требовать повышенных разрешений и на него могут влиять механизмы разгрузки ОС; захват пакетов может интенсивно использовать ЦП/диск, поэтому предпочтительнее использовать целевые фильтры и временные рамки. Для непрерывного анализа пакетов в большом масштабе используйте VNet TAP в паре с устройством анализа пакетов или облачным SIEM, способным принимать потоки PCAP.
Журналы потоков NSG, Traffic Analytics и диагностика безопасности
Журналы потоков NSG (версия 2) предоставляют записи о потоках с временными метками, 5-кортежем, количеством байтов/пакетов и решением (разрешено/запрещено). Они не содержат полезной нагрузки, деталей сеанса на уровне приложений или расшифрованного TLS. Traffic Analytics обогащает журналы потоков данными о самых активных узлах (“top talkers”), ASN и гео-сопоставлениями, для чего требуется рабочая область Log Analytics. Azure Firewall, Application Gateway/WAF и Azure Front Door создают собственные диагностические данные; их необходимо направлять в Log Analytics для унифицированного выполнения запросов. Важные ловушки при проектировании: правила NSG, применяемые на уровне сетевого интерфейса (NIC), имеют приоритет над правилами на уровне подсети; существуют правила по умолчанию (например, для AzureLoadBalancer, правила для интернета), которые нельзя удалить, а можно только переопределить правилами с более высоким приоритетом. Полезность журналов потоков напрямую зависит от стратегии их хранения и приема — длительное хранение в Log Analytics стоит дорого, в то время как короткий срок хранения несет риск потери данных для криминалистического анализа. Комбинируйте журналы потоков NSG с диагностическими журналами Firewall и правилами оповещений на основе запросов Kusto для обнаружения бокового перемещения или эксфильтрации данных. При планировании мер по устранению неполадок рассмотрите возможность добавления выделенных публичных IP-адресов в Azure Firewall для смягчения проблемы истощения портов SNAT и используйте DiagnosticSettings для маршрутизации в Event Hubs для интеграции с SIEM, если затраты на Log Analytics слишком высоки.
← Балансировка нагрузки и управление трафиком · Все домены · Azure Virtual WAN и Hub-Spoke →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →