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

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

• Перед выполнением дальнейших операций с ним потребуется ввести данные. Например, если существует столбец с именем Perf1Sec_i а также свойство в AdditionalFields с именем Perf2Sec, и вы хотите вычислить общую производительность путем добавления обоих значений, используйте следующее: AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | .....
• Используйте предложения where , чтобы уменьшить объем данных до минимально возможного перед написанием сложной логики, чтобы значительно повысить производительность. TimeGenerated — это один столбец, который всегда должен быть сокращен до наименьшего возможного окна. В случае AzureDiagnostics в верхней части запроса всегда должен быть включен дополнительный фильтр для типов ресурсов, запрашиваемых с помощью столбца ResourceType .
• При запросе очень больших объемов данных иногда эффективнее выполнять фильтр по AdditionalFields в целом, а не анализировать их. Например, для больших объемов данных 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 1-го поколения
• Службы подготовки устройств
• Digital Twins
• Разделы Сетки событий
• Центры событий
• Каналы ExpressRoute
• Front Door
• Учетные записи интеграции
• Key Vault
• Службы Kubernetes
• подсистемы балансировки нагрузки;
• Logic Apps
• Службы мультимедиа
• Сетевые интерфейсы
• группы сетевой безопасности;
• VPN-шлюзы типа P2S
• Power BI Embedded
• Общедоступные IP-адреса
• Хранилища служб восстановления(Site Recovery)
• Службы поиска
• Cлужебная шина
• базы данных SQL;
• Управляемые экземпляры SQL
• Серверы SQL Server
• Задания Stream Analytics
• Профили диспетчера трафика
• Виртуальные сети
• Шлюзы виртуальной сети
• VPN-шлюзы;

режим Диагностика Azure или режим для конкретных ресурсов

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

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

Категории

• Ресурсы Azure
• Безопасность
• Сеть

Решения

• LogManagement

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

• Шлюзы приложений
• Профили CDN
• Azure Cosmos DB
• Разделы Сетки событий
• Центры событий
• Брандмауэры
• Хранилища ключей
• Службы Kubernetes
• Хранилища служб восстановления
• Cлужебная шина
• Гибкие серверы Базы данных Azure для MySQL
• гибкие серверы База данных Azure для PostgreSQL
• Службы мультимедиа
• Службы Analysis Services
• Учетные записи пакетной службы
• Cognitive Services
• Пространства имен партнера Сетки событий
• Партнерские разделы Сетки событий
• Системные разделы Сетки событий
• 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

Столбцы

Столбец	Type	Описание
action_id_s	Строка
action_name_s	Строка
action_s	Строка
ActivityId_g	Guid
AdditionalFields
AdHocOrScheduledJob_s	Строка
application_name_s	Строка
audit_schema_version_d	Double
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	Double
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	Double
cpu_time_d	Double
database_name_s	Строка
database_principal_name_s	Строка
DatabaseName_s	Строка
db_id_s	Строка
direction_s	Строка
dop_d	Double
duration_d	Double
duration_milliseconds_d	Double
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	Double
executionInfo_endTime_t	Дата и время
executionInfo_exitCode_d	Double
executionInfo_startTime_t	Дата и время
host_s	Строка
httpMethod_s	Строка
httpStatus_d	Double
HttpStatusCode_d	Double
httpStatusCode_s	Строка
httpVersion_s	Строка
id_s	Строка
identity_claim_appid_g	Guid
identity_claim_ipaddr_s	Строка
instanceId_s	Строка
interval_end_time_d	Double
interval_start_time_d	Double
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
Level	Строка
log_bytes_used_d	Double
logical_io_reads_d	Double
logical_io_writes_d	Double
LogicalServerName_s	Строка
macAddress_s	Строка
matchedConnections_d	Double
max_cpu_time_d	Double
max_dop_d	Double
max_duration_d	Double
max_log_bytes_used_d	Double
max_logical_io_reads_d	Double
max_logical_io_writes_d	Double
max_num_physical_io_reads_d	Double
max_physical_io_reads_d	Double
max_query_max_used_memory_d	Double
max_rowcount_d	Double
max_time_s	Строка
mean_time_s	Строка
Сообщение	Строка
min_time_s	Строка
msg_s	Строка
num_physical_io_reads_d	Double
object_id_d	Double
object_name_s	Строка
OperationName	Строка
OperationVersion	Строка
partitionKey_s	Строка
physical_io_reads_d	Double
plan_id_d	Double
policy_s	Строка
policyMode_s	Строка
primaryIPv4Address_s	Строка
priority_d	Double
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	Double
query_max_used_memory_d	Double
query_plan_hash_s	Строка
query_time_d	Double
querytext_s	Строка
receivedBytes_d	Double
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	Double
resultCode_s	Строка
ResultDescription	Строка
ResultDescription	Строка
resultDescription_ChildJobs_s	Строка
resultDescription_ErrorJobs_s	Строка
resultMessage_s	Строка
ResultSignature	Строка
ResultType	Строка
ResultType	Строка
rootCauseAnalysis_s	Строка
routingRuleName_s	Строка
rowcount_d	Double
ruleName_s	Строка
RunbookName_s	Строка
RunOn_s	Строка
schema_name_s	Строка
sentBytes_d	Double
sequence_group_id_g	Guid
sequence_number_d	Double
server_principal_sid_s	Строка
session_id_d	Double