AzureDiagnostics

Хранит журналы ресурсов для служб Azure, использующих режим Диагностика Azure. Журналы ресурсов описывают внутреннюю операцию ресурсов Azure.

журнал ресурсов для каждой службы Azure имеет уникальный набор столбцов. Таблица AzureDiagnostics содержит наиболее типичные столбцы, используемые службами Azure. Если журнал ресурсов содержит столбец, которого еще нет в таблице AzureDiagnostics, то этот столбец добавляется при первом сборе данных. Если достигнуто максимальное число столбцов (500), то данные для дополнительных столбцов добавляются в динамический столбец.

Службы Azure, использующие данные, относящиеся к ресурсам, хранят данные в таблице, относящуюся к этой службе, и не используют таблицу AzureDiagnostics. Дополнительные сведения см. в разделе "Типы ресурсов" для служб, использующих каждый метод. Дополнительные сведения о различиях см . в журналах ресурсов Azure.

Столбец AdditionalFields

В отличие от других таблиц, AzureDiagnostics гораздо более уязвим к превышению ограничения на 500 столбцов, введенных для любой таблицы в рабочей области Log Analytics из-за широкого ассортимента ресурсов Azure, способных отправлять данные в эту таблицу. Чтобы гарантировать, что данные не будут потеряны из-за количества активных столбцов, превышающих это ограничение в 500 столбцов, создание столбца AzureDiagnostics обрабатывается по-другому.

Таблица AzureDiagnostics в каждой рабочей области будет содержать не менее 200 столбцов. Для рабочих областей, созданных до 19 января 2021 г., таблица также будет содержать все столбцы, которые уже были созданы до этой даты. Когда данные отправляются в столбец, не выполняющийся:

• Если общее количество столбцов в AzureDiagnostics в текущей рабочей области не превышает 500, новый столбец будет создан так же, как и любая другая таблица.
• Если общее число столбцов равно или более 500, то в столбец динамического контейнера свойств с именем AdditionalFields добавляется избыточные данные.

Пример

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

Столбец 1	Столбец 2	Столбец 3	...	Столбец 498
abc	def	123	...	456
...	...	...	...	...

Ресурс, который отправляет данные в AzureDiagnostics , затем добавляет новое измерение в их данные, которые они вызывают NewInfo1. Так как таблица по-прежнему имеет менее 500 столбцов, при первом возникновении события, содержащего данные для этого нового измерения, будет добавлен новый столбец в таблицу:

Столбец 1	Столбец 2	Столбец 3	...	Столбец 498	NewInfo1_s
abc	def	123	...	456	xyz
...	...	...	...	...	...

Эти новые данные можно вернуть в простом запросе:

AzureDiagnostics | where NewInfo1_s == "xyz"

На более позднюю дату другой ресурс отправляет данные в AzureDiagnostics , который добавляет новые измерения с именем NewInfo2 и NewInfo3. Так как таблица достигла 500 столбцов в этой рабочей области, новые данные будут переходить в столбец AdditionalFields :

Столбец 1	Столбец 2	Столбец 3	...	Столбец 498	NewInfo1_s	AdditionalFields
abc	def	123	...	456	xyz	{"NewInfo2":"789","NewInfo3":"qwerty"}
...	...	...	...	...	...	...

Вы по-прежнему можете запрашивать эти данные, но его необходимо извлечь из контейнера свойств с помощью любого из операторов динамического свойства в KQL:

AzureDiagnostics
| where AdditionalFields.NewInfo2 == "789" and AdditionalFields.NewInfo3 == "qwerty"

Советы по использованию столбца AdditionalFields

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

• Перед выполнением дальнейших операций с ним необходимо вводить данные рассылки. Например, если столбец существует под названием Perf1Sec_i, а также свойство в AdditionalFields с именем Perf2Sec, и вы хотите вычислить общее значение, добавив оба значения, используйте примерно следующее: AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | ....
• Используйте предложения, чтобы уменьшить объем данных до наименьшего возможного до написания сложной логики, чтобы значительно повысить производительность. TimeGenerated — это один столбец, который всегда должен быть сокращен до наименьшего возможного окна. В случае AzureDiagnostics дополнительный фильтр также должен быть включен в верхней части запроса вокруг типов ресурсов, запрашиваемых с помощью столбца ResourceType .
• При запросе очень больших объемов данных иногда эффективнее выполнять фильтр в Дополнительных Полях в целом, а не анализировать их. Например, для больших объемов данных AzureDiagnostics | where AdditionalFields has "Perf2Sec" чаще всего эффективнее AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec)).

режим Диагностика Azure

Следующие службы используют режим azure диагностика для журналов ресурсов и отправляют данные в таблицу Диагностика Azure.

• Службы Analysis Services
• Шлюзы приложений
• Учетные записи службы автоматизации
• Серверы Базы данных Azure для MariaDB
• Серверы Базы данных Azure для MySQL
• Серверы службы "База данных Azure для PostgreSQL"
• Серверы службы "База данных Azure для PostgreSQL версии 2"
• Учетные записи пакетной службы
• Профили CDN
• Службы Cognitive Services
• Data Lake Analytics
• DataLake Storage 1-го поколения
• Службы подготовки устройств
• Digital Twins
• Разделы Сетки событий
• Event Hubs
• Каналы ExpressRoute
• службы Front Door.
• Учетные записи службы интеграции
• Key Vault
• Службы Kubernetes
• Подсистемы балансировки нагрузки
• Logic Apps
• Службы мультимедиа
• Сетевые интерфейсы
• группы сетевой безопасности;
• VPN-шлюзы типа P2S
• Power BI Embedded
• общедоступные IP-адреса;
• Хранилища служб восстановления (Site Recovery)
• Службы поиска
• Cлужебная шина
• базы данных SQL;
• Управляемые экземпляры SQL
• Серверы SQL
• Задания Stream Analytics
• Профили диспетчера трафика
• Виртуальные сети
• Шлюзы виртуальной сети
• VPN-шлюзы;

режим Диагностика Azure или режим, зависящий от ресурса

Следующие службы используют режим azure диагностика или режим, зависящий от ресурсов, для журналов ресурсов в зависимости от конфигурации. Если они используют режим, зависящий от ресурсов, они не отправляют данные в таблицу AzureDiagnostics. Дополнительные сведения об этой конфигурации см . в журналах ресурсов Azure.

• Службы Управление API
• Azure Cosmos DB
• Фабрики данных (версии 2)
• Центр Интернета вещей
• Хранилища служб восстановления (резервное копирование)
• Брандмауэры

Категории

• ресурсов Azure
• Безопасность
• Network

Решения

• LogManagement

Типы ресурсов

• Шлюзы приложений
• Профили CDN
• Azure Cosmos DB
• Разделы Сетки событий
• Event Hubs
• Брандмауэры
• Хранилища ключей
• Службы Kubernetes
• Хранилища Служб восстановления
• Cлужебная шина
• Гибкие серверы Базы данных Azure для MySQL
• гибкие серверы База данных Azure для PostgreSQL
• Службы мультимедиа
• Службы Analysis Services
• Учетные записи пакетной службы
• Службы Cognitive Services
• Партнерские пространства имен в Сетке событий Azure
• Партнерские разделы Сетки событий
• Системные разделы Сетки событий
• Kubernetes с поддержкой Azure Arc
• Подготовленные кластеры Azure Arc
• Центр Интернета вещей
• Logic Apps
• Службы управления API
• Учетная запись службы автоматизации
• Фабрики данных
• Azure Data Lake Storage 1-го поколения
• Data Lake Analytics
• Power BI Embedded
• Управляемые экземпляры SQL
• Серверы SQL Server
• Базы данных SQL
• серверы База данных Azure для MySQL
• Серверы базы данных Azure для PostgreSQL
• серверы База данных Azure для PostgreSQL версии 2
• серверы База данных Azure для MariaDB
• Службы подготовки устройств
• Каналы ExpressRoute
• службы Front Door.
• Сетевые интерфейсы
• группы сетевой безопасности;
• Общедоступные IP-адреса
• профили диспетчера трафика;
• Шлюзы виртуальной сети
• Шлюзы виртуальной частной сети
• Виртуальные сети
• службы поиска;
• Задания Stream Analytics

Столбцы

Column	Type	Описание
action_id_s	Строка
action_name_s	Строка
action_s	Строка
ActivityId_g	GUID
AdditionalFields
AdHocOrScheduledJob_s	Строка
application_name_s	Строка
audit_schema_version_d	Двойной
avg_cpu_percent_s	Строка
avg_mean_time_s	Строка
backendHostname_s	Строка
Caller_s	Строка
callerId_s	Строка
CallerIPAddress	Строка
calls_s	Строка
Категория	Строка
client_ip_s	Строка
clientInfo_s	Строка
clientIP_s	Строка
clientIp_s	Строка
clientIpAddress_s	Строка
clientPort_d	Двойной
code_s	Строка
collectionName_s	Строка
conditions_destinationIP_s	Строка
conditions_destinationPortRange_s	Строка
conditions_None_s	Строка
conditions_protocols_s	Строка
conditions_sourceIP_s	Строка
conditions_sourcePortRange_s	Строка
CorrelationId	Строка
count_executions_d	Двойной
cpu_time_d	Двойной
database_name_s	Строка
database_principal_name_s	Строка
DatabaseName_s	Строка
db_id_s	Строка
direction_s	Строка
dop_d	Двойной
duration_d	Двойной
duration_milliseconds_d	Двойной
DurationMs	BigInt
ElasticPoolName_s	Строка
endTime_t	Дата/время
Environment_s	Строка
error_code_s	Строка
error_message_s	Строка
errorLevel_s	Строка
event_class_s	Строка
event_s	Строка
event_subclass_s	Строка
event_time_t	Дата/время
EventName_s	Строка
execution_type_d	Двойной
executionInfo_endTime_t	Дата/время
executionInfo_exitCode_d	Двойной
executionInfo_startTime_t	Дата/время
host_s	Строка
httpMethod_s	Строка
httpStatus_d	Двойной
HttpStatusCode_d	Двойной
httpStatusCode_s	Строка
httpVersion_s	Строка
id_s	Строка
identity_claim_appid_g	GUID
identity_claim_ipaddr_s	Строка
instanceId_s	Строка
interval_end_time_d	Двойной
interval_start_time_d	Двойной
ip_s	Строка
is_column_permission_s	Строка
isAccessPolicyMatch_b	Bool
JobDurationInSecs_s	Строка
JobFailureCode_s	Строка
JobId_g	GUID
jobId_s	Строка
JobOperation_s	Строка
JobOperationSubType_s	Строка
JobStartDateTime_s	Строка
JobStatus_s	Строка
JobUniqueId_g	GUID
Уровень	Строка
log_bytes_used_d	Двойной
logical_io_reads_d	Двойной
logical_io_writes_d	Двойной
LogicalServerName_s	Строка
macAddress_s	Строка
matchedConnections_d	Двойной
max_cpu_time_d	Двойной
max_dop_d	Двойной
max_duration_d	Двойной
max_log_bytes_used_d	Двойной
max_logical_io_reads_d	Двойной
max_logical_io_writes_d	Двойной
max_num_physical_io_reads_d	Двойной
max_physical_io_reads_d	Двойной
max_query_max_used_memory_d	Двойной
max_rowcount_d	Двойной
max_time_s	Строка
mean_time_s	Строка
Message	Строка
min_time_s	Строка
msg_s	Строка
num_physical_io_reads_d	Двойной
object_id_d	Двойной
object_name_s	Строка
OperationName	Строка
OperationVersion	Строка
partitionKey_s	Строка
physical_io_reads_d	Двойной
plan_id_d	Двойной
policy_s	Строка
policyMode_s	Строка
primaryIPv4Address_s	Строка
priority_d	Двойной
properties_enabledForDeployment_b	Bool
properties_enabledForDiskEncryption_b	Bool
properties_enabledForTemplateDeployment_b	Bool
properties_s	Строка
properties_sku_Family_s	Строка
properties_sku_Name_s	Строка
properties_tenantId_g	GUID
query_hash_s	Строка
query_id_d	Двойной
query_max_used_memory_d	Двойной
query_plan_hash_s	Строка
query_time_d	Двойной
querytext_s	Строка
receivedBytes_d	Двойной
Region_s	Строка
requestCharge_s	Строка
requestQuery_s	Строка
requestResourceId_s	Строка
requestResourceType_s	Строка
requestUri_s	Строка
reserved_storage_mb_s	Строка
Ресурс	Строка
resource_actionName_s	Строка
resource_location_s	Строка
resource_originRunId_s	Строка
resource_resourceGroupName_s	Строка
resource_runId_s	Строка
resource_subscriptionId_g	GUID
resource_triggerName_s	Строка
resource_workflowId_g	GUID
resource_workflowName_s	Строка
ResourceGroup	Строка
_ResourceId	Строка	Уникальный идентификатор ресурса, с которым связана запись.
ResourceProvider	Строка
ResourceProvider	Строка
ResourceType	Строка
ResourceType	Строка
response_rows_d	Двойной
resultCode_s	Строка
ResultDescription	Строка
ResultDescription	Строка
resultDescription_ChildJobs_s	Строка
resultDescription_ErrorJobs_s	Строка
resultMessage_s	Строка
ResultSignature	Строка
ResultType	Строка
ResultType	Строка
rootCauseAnalysis_s	Строка
routingRuleName_s	Строка
rowcount_d	Двойной
ruleName_s	Строка
RunbookName_s	Строка
RunOn_s	Строка
schema_name_s	Строка
sentBytes_d	Двойной
sequence_group_id_g	GUID
sequence_number_d	Двойной
server_principal_sid_s	Строка
session_id_d	Двойной