Устранение проблем с агентом Log Analytics для Windows
Эта статья содержит справку по устранению ошибок, с которыми вы можете столкнуться с агентом Log Analytics для Windows в Azure Monitor и предлагает возможные решения для их устранения.
Средство устранения неполадок в Log Analytics
Агент Log Analytics для средства устранения неполадок Windows — это коллекция сценариев PowerShell, предназначенных для поиска и диагностики проблем с агентом Log Analytics. Он автоматически включается в состав агента при его установке. Запуск этого средства — рекомендуемый первый шаг по диагностике проблем.
Использование средства устранения неполадок
Откройте запрос PowerShell от имени администратора на компьютере, на котором установлен агент Log Analytics.
Перейдите в каталог, в котором находится средство:
cd "C:\Program Files\Microsoft Monitoring Agent\Agent\Troubleshooter"Выполните основной скрипт с помощью следующей команды:
.\GetAgentInfo.ps1Выберите сценарий устранения неполадок.
Следуйте указаниям, отображаемым в консоли. Обратите внимание, что действия по журналам трассировки требуют ручного вмешательства для остановки сбора журналов. На основе воспроизводимости проблемы дождитесь длительности времени и выберите "s", чтобы остановить сбор журналов и перейти к следующему шагу.
Расположение файла результатов регистрируется после завершения и открывается новое окно обозревателя.
Установка
Средство устранения неполадок автоматически включается при установке агента Log Analytics сборки 10.20.18053.0 и далее.
Рассматриваемые сценарии
Средство устранения неполадок проверяет следующие сценарии:
- Агент не сообщает данные или данные пульса отсутствуют.
- Развертывание расширения агента завершается сбоем.
- Агент завершает работу.
- Агент потребляет высокую загрузку ЦП или память.
- Сбои при установке и удалении.
- Пользовательские журналы имеют проблемы.
- Шлюз OMS имеет проблемы.
- Счетчики производительности имеют проблемы.
- Невозможен сбор журналов агента.
Примечание.
Запустите средство устранения неполадок при возникновении проблемы. Наличие журналов на начальном этапе поможет нашей группе технической поддержки быстрее устранить проблему.
Важные источники для устранения неполадок
Чтобы помочь с устранением неполадок, связанных с агентом Log Analytics для Windows, агент регистрирует события в журнал событий Windows, в частности в разделе Application and Services\Operations Manager.
Проблемы с подключением
Если агент взаимодействует с прокси-сервером или брандмауэром, ограничения могут быть на месте, которые препятствуют обмену данными с исходного компьютера и службы Azure Monitor. Если связь заблокирована из-за неправильной настройки, регистрация в рабочей области может завершиться ошибкой при попытке установить агент или настроить агент после установки для отчета в другую рабочую область. Обмен данными агента может завершиться ошибкой после успешной регистрации. В этом разделе описаны методы устранения неполадок такого рода в агенте для Windows.
Дважды проверьте, настроен ли брандмауэр или прокси-сервер, чтобы разрешить следующие порты и URL-адреса, описанные в следующей таблице. Кроме того, убедитесь, что проверка HTTP не включена для веб-трафика. Он может предотвратить безопасный канал TLS между агентом и Azure Monitor.
| Ресурс агента | Порты | Направление | Обход проверки HTTP |
|---|---|---|---|
| *.ods.opinsights.azure.com | Порт 443 | Исходящий | Да |
| *.oms.opinsights.azure.com | Порт 443 | Исходящий | Да |
| *.blob.core.windows.net | Порт 443 | Исходящий | Да |
| *.agentsvc.azure-automation.net | Порт 443 | Исходящий | Да |
Сведения о брандмауэре, необходимые для управления Azure для государственных организаций, см. в здесь. Если планируется использование Azure Automation Hybrid Runbook Worker для подключения к службе автоматизации и регистрации в ней, чтобы применить runbook или решения для управления в вашей среде, они должны иметь доступ к номеру порта и URL-адресам, описанным в разделе Настройка сети для Hybrid Runbook Worker.
Существует несколько способов проверить, успешно ли агент взаимодействует с Azure Monitor:
Включите Оценку Работоспособности агентов Azure Log Analytics в рабочей области. На панели мониторинга "Работоспособность агентов" просмотрите столбец Число агентов, не отвечающих на запросы, чтобы быстро определить, не упоминается ли в нем проверяемый агент.
Выполните следующий запрос, чтобы убедиться, что агент отправляет пульс в рабочую область, в которую он настроен для отчета. Замените
<ComputerName>на действительное имя компьютера.Heartbeat | where Computer like "<ComputerName>" | summarize arg_max(TimeGenerated, * ) by ComputerЕсли компьютер успешно обменивается данными со службой, этот запрос должен вернуть результат. Если запрос не вернул результат, сначала убедитесь, что агент настроен для отправки отчета в правильную рабочую область. Если он настроен правильно, перейдите к шагу 3 и выполните поиск в журнале событий Windows, чтобы определить, регистрирует ли агент проблему, которая может препятствовать ему взаимодействовать с Azure Monitor.
Также проблемы с подключением можно выявить, запустив инструмент TestCloudConnectivity. Этот инструмент по умолчанию устанавливается вместе с агентом в папку %SystemRoot%\Program Files\Microsoft Monitoring Agent\Agent. В командной строке с повышенными привилегиями перейдите в папку и запустите средство. Он вернет результаты и выделит тесты, которые завершились ошибкой. Например, возможно, она связана с определенным портом или URL-адресом, заблокированным.
Отфильтруйте журнал событий Operations Manager по источникам событий служба работоспособности модулям, HealthService и соединителю службы и отфильтруйте по предупреждению и ошибке уровня событий, чтобы убедиться, что он написал события из следующей таблицы. Если они есть, ознакомьтесь с действиями по устранению неполадок, приведенными для соответствующего события.
ИД события Оригинал Описание Решение 2133 и 2129 Служба работоспособности Сбой подключения к службе из агента. Эта ошибка может возникать, когда агент не может напрямую взаимодействовать или через брандмауэр или прокси-сервер со службой Azure Monitor. Убедитесь, что параметры прокси-сервера агента или брандмауэр сети или прокси-сервер разрешает TCP-трафик с компьютера в службу. 2138 Модули службы работоспособности Для прокси-сервера требуется проверка подлинности. Настройте параметры прокси-сервера агента и укажите имя пользователя и пароль, необходимые для проверки подлинности на прокси-сервере. 2129 Модули службы работоспособности Сбой подключения. Не удалось выполнить согласование TLS. Проверьте параметры TCP/IP сетевого адаптера и параметры прокси-сервера агента. 2127 Модули службы работоспособности Сбой отправки полученных данных об ошибке. Если это происходит только периодически в течение дня, это может быть случайной аномалией, которая может быть проигнорирована. Отслеживайте журнал, чтобы определить, насколько часто она возникает. Если ошибка появляется часто в течение дня, сначала проверьте конфигурацию сети и параметры прокси-сервера. Если описание включает код ошибки HTTP 404 и это первая попытка агента отправить данные в службу, будет указана ошибка 500 с кодом внутренней ошибки 404. Код ошибки 404 означает "не найдено", что означает, что область хранения для новой рабочей области по-прежнему подготавливается. В следующем повторе данные будут успешно записываться в рабочую область, как ожидалось. Ошибка HTTP 403 может указывать на проблему, связанную с разрешениями или учетными данными. Дополнительные сведения включаются в ошибку 403, чтобы помочь устранить проблему. 4000 Соединитель служб Сбой разрешения DNS-имен. Компьютер не удалось разрешить адрес Интернета, используемый при отправке данных в службу. Эта проблема может быть параметрами сопоставителя DNS на компьютере, неправильными параметрами прокси-сервера или временной проблемой DNS с вашим поставщиком. Если такая ошибка возникает периодически, она может быть вызвана временными проблемами с сетью. 4001 Соединитель служб Не удалось подключиться к службе. Эта ошибка может возникать, когда агент не может напрямую взаимодействовать или через брандмауэр или прокси-сервер со службой Azure Monitor. Убедитесь, что параметры прокси-сервера агента или брандмауэр сети или прокси-сервер разрешает TCP-трафик с компьютера в службу. 4002 Соединитель служб Служба вернула код состояния HTTP 403 в ответ на запрос. Обратитесь к администратору службы, чтобы проверить работоспособность службы. Запрос будет получен позже. Эта ошибка записывается на начальном этапе регистрации агента. Вы увидите URL-адрес, аналогичный https://< workspaceID.oms.opinsights.azure.com/AgentService.svc/AgentTopologyRequest>. Код ошибки 403 означает "запрещено" и может быть вызван неправильным идентификатором рабочей области или ключом. Дата и время также могут быть неверными на компьютере. Если время равно +/- 15 минут с текущего времени, подключение завершается ошибкой. Чтобы устранить эту проблему, обновите дату и (или) время компьютера Windows.
Проблемы при сборе данных
После установки и отправки отчетов в настроенную рабочую область или рабочие области агент может перестать получать конфигурацию и собирать или пересылать производительность, журналы или другие данные в службу в зависимости от того, что включено и нацеливает компьютер. Вам нужно определить следующее:
- Это определенный тип данных или все данные, недоступные в рабочей области?
- Тип данных указан решением или задан в составе конфигурации сбора данных для рабочей области?
- Сколько компьютеров затронуто проблемой? Это один компьютер или несколько компьютеров, отчеты в рабочую область?
- Передача данных работала, а затем прекратилась в определенный момент или данные так никогда и не собирались?
- Правильно ли используется запрос поиска по журналам?
- Получил ли агент конфигурацию Azure Monitor хотя бы один раз?
Первый шаг при устранении этих неполадок — определить, отправляет ли компьютер события пульса.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
Если запрос возвращает результаты, необходимо определить, не собирается ли определенный тип данных и пересылается в службу. Эта проблема может быть вызвана тем, что агент не получает обновленную конфигурацию из службы или какой-либо другой симптом, который не позволяет агенту работать нормально. Для дальнейшей диагностики и устранения неполадок выполните следующие шаги.
Откройте командную строку с повышенными привилегиями на компьютере и перезапустите службу агента, введя
net stop healthservice && net start healthserviceввод.Откройте журнал событий Operations Manager и найдите идентификаторы событий 7023, 7024, 7025, 7028 и 1210 из источника событий HealthService. Эти события указывают, что агент успешно получает конфигурацию из Azure Monitor, и они активно отслеживают компьютер. В описании события с идентификатором 1210 на последней строке будет также указан перечень всех решений и элементов Insight, включенных в область мониторинга на агенте.
Подождите несколько минут. Если в результатах запроса или визуализации не отображаются ожидаемые данные, в зависимости от того, просматриваете ли данные из решения или аналитики из журнала событий Operations Manager, найдите источники событий HealthService и служба работоспособности Modules. Фильтруйте по предупреждению и ошибке уровня событий, чтобы убедиться, что он написал события из следующей таблицы.
ИД события Оригинал Описание Решение 8000 HealthService Это событие указывается, если рабочий процесс, связанный с производительностью, событием или другим типом собираемых данных, не может перенаправить данные в службу для их приема в рабочую область. Идентификатор события 2136 из источника HealthService записывается вместе с этим событием и может указать, что агент не может взаимодействовать со службой. Возможные причины могут быть неправильно настроены параметры прокси-сервера и проверки подлинности, сетевой сбой или сетевой брандмауэр или прокси-сервер не разрешают tcp-трафик с компьютера в службу. 10102 и 10103 Модули службы работоспособности Рабочий процесс не удалось устранить источник данных. Эта проблема может возникнуть, если указанный счетчик производительности или экземпляр не существует на компьютере или неправильно определен в параметрах данных рабочей области. Если это счетчик производительности, указанный пользователем, убедитесь, что указанные сведения соответствуют правильному формату и существуют на целевых компьютерах. 26002 Модули службы работоспособности Рабочий процесс не удалось устранить источник данных. Эта проблема может возникнуть, если указанный журнал событий Windows не существует на компьютере. Эта ошибка может быть безопасно проигнорирована, если компьютер не зарегистрирован в этом журнале событий. В противном случае, если это журнал событий, указанный пользователем, убедитесь, что указана правильная информация.
Проблемы с закрепленными сертификатами со старыми агентами Microsoft Monitoring Agent — критическое изменение
Обзор изменений корневого ЦС
По состоянию на 30 июня 2023 г. внутренний интерфейс Log Analytics больше не будет принимать подключения из MMA, ссылающихся на исходящий корневой сертификат. Эти MMA являются более старыми версиями до выпуска Winter 2020 (агент Log Analytics) и до SCOM 2019 UR3 (SCOM). Любая версия, пакет: 10.20.18053 / Extension: 1.0.18053.0 или больше не будет иметь никаких проблем, а также любую версию выше SCOM 2019 UR3. Любой агент старше этого не будет работать и больше не будет работать и отправлять в Log Analytics.
Что именно меняется?
В рамках продолжающихся усилий по обеспечению безопасности в различных службах Azure Azure Log Analytics официально переключится с корня ЦС Балтимора CyberTrust на root DigiCert Global G2 ЦС. Это изменение повлияет на связь TLS с Log Analytics, если новый корневой сертификат ЦС DigiCert Global G2 отсутствует в ОС, или приложение ссылается на старый корневой ЦС Балтимора. Это означает, что Log Analytics больше не будет принимать подключения из MMA, которые используют этот старый корневой ЦС после выхода из эксплуатации.
Продукты решения
Возможно, вы получили уведомление о критических изменениях, даже если вы лично не установили агент Microsoft Monitoring Agent. Это связано с тем, что различные продукты Azure используют Microsoft Monitoring Agent. Если вы используете один из этих продуктов, вы можете повлиять на использование агента Windows Log Analytics. Для этих продуктов со ссылками ниже могут быть конкретные инструкции, которые потребуют обновления до последнего агента.
- Аналитика виртуальных машин
- System Center Operations Manager (SCOM)
- System Center Service Manager;
- Microsoft Defender для сервера
- Microsoft Defender для конечной точки
- Рабочая область
- гибридная рабочая роль на основе агента служба автоматизации Azure
- служба автоматизации Azure Отслеживание изменений и инвентаризация
- Управление обновлениями в службе автоматизации Azure
Определение и переидидивание критических агентов
Для развертываний с ограниченным количеством агентов настоятельно рекомендуется обновить агент на узел с помощью этих инструкций по управлению.
Для развертываний с несколькими узлами мы написали сценарий, который обнаружит все затронутые критические MMAs для каждой подписки, а затем обновите их до последней версии. Эти скрипты должны выполняться последовательно, начиная с UpdateMMA.ps1 и UpgradeMMA.ps1. В зависимости от компьютера сценарий может занять некоторое время. Чтобы избежать времени ожидания, необходимо выполнить PowerShell 7 или более поздней версии.
UpdateMMA.ps1 Этот сценарий будет проходить через виртуальные машины в подписках, проверить наличие существующих MMAs, а затем создать .csv файл агентов, которые необходимо обновить.
UpgradeMMA.ps1 Этот скрипт будет использовать . CSV-файл, созданный в UpdateMMA.ps1 для обновления всех критических MMA.
Оба этих скрипта могут занять некоторое время.
# UpdateMMA.ps1
# This script is to be run per subscription, the customer has to set the az subscription before running this within the terminal scope.
# This script uses parallel processing, modify the $parallelThrottleLimit parameter to either increase or decrease the number of parallel processes
# PS> .\UpdateMMA.ps1 GetInventory
# The above command will generate a csv file with the details of VM's and VMSS that require MMA upgrade.
# The customer can modify the csv by adding/removing rows if needed
# Update the MMA by running the script again and passing the csv file as parameter as shown below:
# PS> .\UpdateMMA.ps1 Upgrade
# If you don't want to check the inventory, then run the script wiht an additional -no-inventory-check
# PS> .\UpdateMMA.ps1 GetInventory & .\UpdateMMA.ps1 Upgrade
# This version of the script requires Powershell version >= 7 in order to improve performance via ForEach-Object -Parallel
# https://docs.microsoft.com/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.1
if ($PSVersionTable.PSVersion.Major -lt 7)
{
Write-Host "This script requires Powershell version 7 or newer to run. Please see https://docs.microsoft.com/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.1."
exit 1
}
$parallelThrottleLimit = 16
$mmaFixVersion = [version]"10.20.18053.0"
function GetVmsWithMMAInstalled
{
param(
$fileName
)
$vmList = az vm list --show-details --query "[?powerState=='VM running'].{ResourceGroup:resourceGroup, VmName:name}" | ConvertFrom-Json
if(!$vmList)
{
Write-Host "Cannot get the VM list, this script can only detect the running VM's"
return
}
$vmsCount = $vmList.Length
$vmParallelThrottleLimit = $parallelThrottleLimit
if ($vmsCount -lt $vmParallelThrottleLimit)
{
$vmParallelThrottleLimit = $vmsCount
}
if($vmsCount -eq 1)
{
$vmGroups += ,($vmList[0])
}
else
{
# split the vm's into batches to do parallel processing
for ($i = 0; $i -lt $vmsCount; $i += $vmParallelThrottleLimit)
{
$vmGroups += , ($vmList[$i..($i + $vmParallelThrottleLimit - 1)])
}
}
Write-Host "Detected $vmsCount Vm's running in this subscription."
$hash = [hashtable]::Synchronized(@{})
$hash.One = 1
$vmGroups | Foreach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$len = $using:vmsCount
$hash = $using:hash
$_ | ForEach-Object {
$percent = 100 * $hash.One++ / $len
Write-Progress -Activity "Getting VM Inventory" -PercentComplete $percent
$vmName = $_.VmName
$resourceGroup = $_.ResourceGroup
$responseJson = az vm run-command invoke --command-id RunPowerShellScript --name $vmName -g $resourceGroup --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
if($responseJson)
{
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$extensionName = az vm extension list -g $resourceGroup --vm-name $vmName --query "[?name == 'MicrosoftMonitoringAgent'].name" | ConvertFrom-Json
if ($extensionName)
{
$installType = "Extension"
}
else
{
$installType = "Installer"
}
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VM"
'Install_Type' = $installType
'Version' = $mmaVersion
"Instance_Id" = ""
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
}
}
}
function GetVmssWithMMAInstalled
{
param(
$fileName
)
# get the vmss list which are successfully provisioned
$vmssList = az vmss list --query "[?provisioningState=='Succeeded'].{ResourceGroup:resourceGroup, VmssName:name}" | ConvertFrom-Json
$vmssCount = $vmssList.Length
Write-Host "Detected $vmssCount Vmss running in this subscription."
$hash = [hashtable]::Synchronized(@{})
$hash.One = 1
$vmssList | Foreach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$len = $using:vmssCount
$hash = $using:hash
$percent = 100 * $hash.One++ / $len
Write-Progress -Activity "Getting VMSS Inventory" -PercentComplete $percent
$vmssName = $_.VmssName
$resourceGroup = $_.ResourceGroup
# get running vmss instance ids
$vmssInstanceIds = az vmss list-instances --resource-group $resourceGroup --name $vmssName --expand instanceView --query "[?instanceView.statuses[1].displayStatus=='VM running'].instanceId" | ConvertFrom-Json
if ($vmssInstanceIds.Length -gt 0)
{
$isMMAExtensionInstalled = az vmss extension list -g $resourceGroup --vmss-name $vmssName --query "[?name == 'MicrosoftMonitoringAgent'].name" | ConvertFrom-Json
if ($isMMAExtensionInstalled )
{
# check an instance in vmss, if it needs an MMA upgrade. Since the extension is installed at VMSS level, checking for bad version in 1 instance should be fine.
$responseJson = az vmss run-command invoke --command-id RunPowerShellScript --name $vmssName -g $resourceGroup --instance-id $vmssInstanceIds[0] --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmssName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VMSS"
'Install_Type' = "Extension"
'Version' = $mmaVersion
"Instance_Id" = ""
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
else
{
foreach ($instanceId in $vmssInstanceIds)
{
$responseJson = az vmss run-command invoke --command-id RunPowerShellScript --name $vmssName -g $resourceGroup --instance-id $instanceId --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmssName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VMSS"
'Install_Type' = "Installer"
'Version' = $mmaVersion
"Instance_Id" = $instanceId
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
}
}
}
}
function Upgrade
{
param(
$fileName = "MMAInventory.csv"
)
Import-Csv $fileName | ForEach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$mmaVersion = [version]$_.Version
if($mmaVersion -lt $using:mmaFixVersion)
{
if ($_.Install_Type -eq "Extension")
{
if ($_.Resource_Type -eq "VMSS")
{
# if the extension is installed with a custom name, provide the name using the flag: --extension-instance-name <extension name>
az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --force-update --vmss-name $_.Name --resource-group $_.Resource_Group --no-wait --output none
}
else
{
# if the extension is installed with a custom name, provide the name using the flag: --extension-instance-name <extension name>
az vm extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --force-update --vm-name $_.Name --resource-group $_.Resource_Group --no-wait --output none
}
}
else {
if ($_.Resource_Type -eq "VMSS")
{
az vmss run-command invoke --command-id RunPowerShellScript --name $_.Name -g $_.Resource_Group --instance-id $_.Instance_Id --scripts '@UpgradeMMA.ps1' --parameters "functionName=UpgradeMMA" --output none
}
else
{
az vm run-command invoke --command-id RunPowerShellScript --name $_.Name -g $_.Resource_Group --scripts '@UpgradeMMA.ps1' --parameters "functionName=UpgradeMMA" --output none
}
}
}
}
}
function GetInventory
{
param(
$fileName = "MMAInventory.csv"
)
# create a new file
New-Item -Name $fileName -ItemType File -Force
GetVmsWithMMAInstalled $fileName
GetVmssWithMMAInstalled $fileName
}
switch ($args.Count)
{
0 {
Write-Host "The arguments provided are incorrect."
Write-Host "To get the Inventory: Run the script as: PS> .\UpdateMMA.ps1 GetInventory"
Write-Host "To update MMA from Inventory: Run the script as: PS> .\UpdateMMA.ps1 Upgrade"
Write-Host "To do the both steps together: PS> .\UpdateMMA.ps1 GetInventory & .\UpdateMMA.ps1 Upgrade"
}
1 {
$funcname = $args[0]
Invoke-Expression "& $funcname"
}
2 {
$funcname = $args[0]
$funcargs = $args[1]
Invoke-Expression "& $funcname $funcargs"
}
}