培训
模块
引导式项目 - 使用 KQL 分析 Azure Monitor 中的日志 - Training
编写日志查询,深入了解你的业务、IT 运营和性能。 使用 Kusto 查询语言 (KQL) 提取 Azure Monitor Log Analytics 中的日志数据。
你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure Monitor 日志使用 Azure 数据资源管理器来存储日志数据,并运行查询来分析这些数据。 它为你创建、管理和维护 Azure 数据资源管理器群集,并针对你的日志分析工作负载优化它们。 运行查询时,将对其进行优化,并将其路由到存储着工作区数据的相应 Azure 数据资源管理器群集。
Azure Monitor 日志和 Azure 数据资源管理器使用许多自动查询优化机制。 虽然自动优化已提供了显著的性能提升,但在某些情况下,你还可以显著提高查询性能。 本文介绍了性能注意事项和解决相关问题的几种方法。
大多数方法对于直接在 Azure 数据资源管理器和 Azure Monitor 日志上运行的查询是通用的。 我们也会探讨一些独特的 Azure Monitor 日志注意事项。 如需更多的 Azure 数据资源管理器优化技巧,请参阅查询最佳做法。
优化的查询具有以下特点:
请特别注意反复使用的和同时使用的查询,例如涉及仪表板、警报、Azure 逻辑应用和 Power BI 的查询。 在这些情况下,无效查询的影响是巨大的。
下面是一个关于优化查询的详细视频演练。
在 Log Analytics 中运行查询后,选择屏幕右下角的“查询详细信息”,打开“查询详细信息”窗格。 此窗格显示查询的多个性能指标的结果。 下一部分介绍了这些性能指标。
针对所执行的每个查询提供了以下查询性能指标:
在所有查询处理节点中处理此查询而投入的实际计算 CPU。 由于大多数查询是在大量节点上执行的,因此总时间通常会比查询执行的持续时间长得多。
使用超过 100 秒 CPU 的查询被视为消耗过多资源的查询。 使用超过 1,000 秒 CPU 的查询被视为滥用查询,可能会受到限制。
查询处理时间花费在:
除了查询处理节点花费的时间外,Azure Monitor 日志还会在以下方面花费时间:
此时间不包括在查询总 CPU 时间内。
某些查询命令和函数的 CPU 消耗很高。 对于分析 JSON 和 XML 或提取复杂的正则表达式的命令尤其如此。 这种分析可以通过 parse_json() 或 parse_xml() 函数显式地进行,也可以在引用动态列时隐式地进行。
这些函数使用的 CPU 与它们正在处理的行数成正比。 最有效的优化是提前在查询中添加 where
条件。 这样可以在执行 CPU 密集型函数之前筛选出尽可能多的记录。
例如以下查询会生成完全相同的结果。 但第二个查询的效率最高,因为其中的 where 条件在分析之前排除了许多记录:
//less efficient
SecurityEvent
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32" // Problem: irrelevant results are filtered after all processing and parsing is done
| summarize count() by FileHash, FilePath
//more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32" // exact removal of results. Early filter is not accurate enough
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before
如果查询包含的 where 子句基于某个计得列而不是数据集中实际存在的列,则查询的效率会降低。 在处理大型数据集时,针对计得列进行筛选会妨碍某些系统优化。
例如以下查询会生成完全相同的结果。 但第二个方法效率更高,因为 where 条件引用了内置列:
//less efficient
Syslog
| extend Msg = strcat("Syslog: ",SyslogMessage)
| where Msg has "Error"
| count
//more efficient
Syslog
| where SyslogMessage has "Error"
| count
在某些情况下,计算列由查询处理引擎隐式创建,因为筛选不只是在字段上完成的:
//less efficient
SecurityEvent
| where tolower(Process) == "conhost.exe"
| count
//more efficient
SecurityEvent
| where Process =~ "conhost.exe"
| count
部分聚合命令(例如 max()、sum()、count() 和 avg())因为逻辑方面的原因而对 CPU 的影响较低。 其他命令则较复杂,包括试探方法和估算,这使它们能够高效地执行。 例如,dcount() 使用 HyperLogLog 算法提供对大型数据集的非重复计数的近似估算,而不对每个值进行实际计数。
百分位函数使用最近的秩百分位算法执行类似的粗略估算。 多个命令包括了可选参数来降低其影响。 例如,makeset() 函数使用一个可选参数来定义最大集大小,该大小会显著影响 CPU 和内存。
Join 和 summarize 命令在处理大型数据集时可能会导致 CPU 使用率较高。 它们的复杂性与在 summarize
中用作 by
或用作 join
属性的列的可能值的数量(称为“基数”)直接相关。 有关对 join
和 summarize
的说明和优化,请参阅它们的文档文章和优化技巧。
例如,下面的查询产生完全相同的结果,因为 CounterPath
始终一对一映射到 CounterName
和 ObjectName
。 第二个查询更为高效,因为聚合维度较小:
//less efficient
Perf
| summarize avg(CounterValue)
by CounterName, CounterPath, ObjectName
//make the group expression more compact improve the performance
Perf
| summarize avg(CounterValue), any(CounterName), any(ObjectName)
by CounterPath
CPU 消耗还可能会受 where
条件或需要密集计算的扩展列的影响。 所有琐碎的字符串比较(例如 equal == 和 startswith)对 CPU 的影响大致相同。 而高级文本匹配则影响更大。 具体而言,has 运算符比 contains 运算符更高效。 由于使用的字符串处理技术,查找长度超过四个字符的字符串比查找短字符串更高效。
例如,下面的查询将产生类似的结果,具体取决于 Computer
命名策略。 但第二个查询更高效:
//less efficient – due to filter based on contains
Heartbeat
| where Computer contains "Production"
| summarize count() by ComputerIP
//less efficient – due to filter based on extend
Heartbeat
| extend MyComputer = Computer
| where MyComputer startswith "Production"
| summarize count() by ComputerIP
//more efficient
Heartbeat
| where Computer startswith "Production"
| summarize count() by ComputerIP
备注
此指标仅显示来自紧邻群集的 CPU。 在多区域查询中,它仅显示其中一个区域。 在多工作区查询中,它可能不包括所有工作区。
完全分析某个 XML 或 JSON 对象可能会消耗大量 CPU 和内存资源。 在许多情况下,当只需要一两个参数并且 XML 或 JSON 对象很简单时,可以将它们分析为字符串,这样更简单。 使用 parse 运算符或其他文本分析技术。 随着 XML 或 JSON 对象中的记录数增加,性能提升会更明显。 当记录的数量达到数千万时,这一点至关重要。
例如,下面的查询返回与上文的查询完全相同的结果,而无需执行全部 XML 分析。 查询对 XML 文件结构做了一些假设,例如 FilePath
元素位于 FileHash
之后,并且它们都没有属性:
//even more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before
在处理查询的过程中,一个重要因素是经扫描后用于查询处理的数据量。 与其他数据平台相比,Azure 数据资源管理器使用严格的优化,大大减少了数据量。 尽管如此,查询中也存在一些重要因素,这些因素可能会影响所使用的数据量。
处理超过 2,000KB 数据的查询被视为消耗过多资源的查询。 处理超过 20,000KB 数据的查询被视为滥用查询,可能会受到限制。
在 Azure Monitor 日志中,TimeGenerated
列用作为数据编制索引的方式。 将 TimeGenerated
值限制至尽可能小的范围,可以提高查询性能。 较小的范围能很好地限制需要处理的数据量。
增加处理数据的另一个因素是使用大量的表。 使用 search *
和 union *
命令时通常会发生这种情况。 这些命令强制系统对工作区中所有表的数据进行评估和扫描。 在某些情况下,工作区中可能有数百个表。 请避免使用 search *
或未将范围限定为特定表的任何搜索。
例如,下面的查询生成完全相同的结果,但最后一个查询最高效:
// This version scans all tables though only Perf has this kind of data
search "Processor Time"
| summarize count(), avg(CounterValue) by Computer
// This version scans all strings in Perf tables – much more efficient
Perf
| search "Processor Time"
| summarize count(), avg(CounterValue) by Computer
// This is the most efficient version
Perf
| where CounterName == "% Processor Time"
| summarize count(), avg(CounterValue) by Computer
减少数据量的另一种方法是在查询中提前使用 where 条件。 Azure 数据资源管理器平台包含一个缓存,该缓存可让它知道哪些分区包含与特定 where
条件相关的数据。 例如,如果查询包含 where EventID == 4624
,则它只将查询分布到对包含匹配事件的分区进行处理的节点。
下面的示例查询生成完全相同的结果,但第二个查询更高效:
//less efficient
SecurityEvent
| summarize LoginSessions = dcount(LogonGuid) by Account
//more efficient
SecurityEvent
| where EventID == 4624 //Logon GUID is relevant only for logon event
| summarize LoginSessions = dcount(LogonGuid) by Account
如果查询包含多个使用 join 或 union 运算符合并的子查询,则每个子查询会分别扫描整个源。 然后合并结果。 该操作就会导致扫描数据的次数倍增,这对于大型数据集是个至关重要的因素。
要避免这种情况,有一种方法是使用条件聚合函数。 在 summarize 运算符中使用的大多数聚合函数都有一个带条件的版本,你可以将该版本与多个条件配合用于单个 summarize 运算符。
例如,下面的查询显示了每个帐户的登录事件数以及进程执行事件数。 它们返回相同的结果,但第一个查询会扫描数据两次。 第二个查询仅扫描一次:
//Scans the SecurityEvent table twice and perform expensive join
SecurityEvent
| where EventID == 4624 //Login event
| summarize LoginCount = count() by Account
| join
(
SecurityEvent
| where EventID == 4688 //Process execution event
| summarize ExecutionCount = count(), ExecutedProcesses = make_set(Process) by Account
) on Account
//Scan only once with no join
SecurityEvent
| where EventID == 4624 or EventID == 4688 //early filter
| summarize LoginCount = countif(EventID == 4624), ExecutionCount = countif(EventID == 4688), ExecutedProcesses = make_set_if(Process,EventID == 4688) by Account
另一种不必使用子查询的情况是,对 parse 运算符进行预筛选以确保它只处理符合特定模式的记录。 这样做是不必要的,因为 parse 运算符和其他类似的运算符在模式不匹配时会返回空结果。 以下两个查询返回的结果完全相同,但第二个查询仅扫描一次数据。 在第二个查询中,每个 parse 命令只与其事件相关。 extend
运算符会在之后显示如何引用空数据情况:
//Scan SecurityEvent table twice
union(
SecurityEvent
| where EventID == 8002
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| distinct FilePath
),(
SecurityEvent
| where EventID == 4799
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" *
| distinct CallerProcessName1
)
//Single scan of the SecurityEvent table
SecurityEvent
| where EventID == 8002 or EventID == 4799
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" * //Relevant only for event 8002
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" * //Relevant only for event 4799
| extend FilePath = iif(isempty(CallerProcessName1),FilePath,"")
| distinct FilePath, CallerProcessName1
当上述查询无法避免使用子查询时,另一种方法是通过使用 materialize() 函数来提示查询引擎:有一个在这些子查询中的每一个都用到的源数据。 当源数据来自在查询中多次用到的某个函数时,适合使用这种方法。 当子查询的输出比输入小得多时,Materialize
是有效的。 查询引擎将在所有匹配项中缓存和重用输出。
因为 Azure 数据资源管理器是一个列式数据存储,所以对每一列的检索都独立于其他列。 检索的列数直接影响总体数据量。 只应在输出中包含对结果进行汇总或对特定列进行投影所需的列。
Azure 数据资源管理器采取了多项优化来减少检索的列的数量。 如果它确定不需要某个列(例如,如果在 summarize 命令中没有引用该列),它将不会检索该列。
例如,第二个查询可能会处理三倍的数据,因为它需要获取的不是一列而是三列:
//Less columns --> Less data
SecurityEvent
| summarize count() by Computer
//More columns --> More data
SecurityEvent
| summarize count(), dcount(EventID), avg(Level) by Computer
Azure Monitor 日志中的所有日志都根据 TimeGenerated
列进行分区。 访问的分区数与时间跨度直接相关。 减小时间范围是确保快速执行查询的最有效方法。
时间跨度超过 15 天的查询被视为消耗过多资源的查询。 时间跨度超过 90 天的查询被视为滥用查询,可能会受到限制。
可以使用 Log Analytics 屏幕中的时间范围选择器设置时间范围,如 Azure Monitor Log Analytics 中的日志查询范围和时间范围中所述。 这是推荐使用的方法,因为选定的时间范围将通过使用查询元数据传递到后端。
另一种方法是在查询中显式地包含针对 TimeGenerated
的 where 条件。 你应当使用此方法,因为它可以确保时间跨度是固定的,即使查询是从不同的接口使用的。
确保查询的所有部分都有 TimeGenerated
筛选器。 当查询有子查询从不同的表或同一个表中获取数据时,每个查询都必须包含自己的 where 条件。
例如以下查询将仅扫描最后一天的 Perf
表。 而 Heartbeat
表的所有历史记录都会被扫描,可能涉及长达两年的记录:
Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
Heartbeat
//No time span filter in this part of the query
| summarize IPs = makeset(ComputerIP, 10) by Computer
) on Computer
出现这种错误的一种常见情况是使用 arg_max() 查找最近的匹配项。 例如:
Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
Heartbeat
//No time span filter in this part of the query
| summarize arg_max(TimeGenerated, *), min(TimeGenerated)
by Computer
) on Computer
通过在内部查询中添加时间筛选器,可以轻松地纠正此问题:
Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
Heartbeat
| where TimeGenerated > ago(1d) //filter for this part
| summarize arg_max(TimeGenerated, *), min(TimeGenerated)
by Computer
) on Computer
此错误的另一个示例是在对多个表进行 union 之后执行时间范围筛选。 在执行 union 运算时,应确定每个子查询的范围。 可以使用 let 语句来确保范围的一致性。
例如,以下查询将扫描 Heartbeat
和 Perf
表中的所有数据,而不是仅仅扫描最后一天:
Heartbeat
| summarize arg_min(TimeGenerated,*) by Computer
| union (
Perf
| summarize arg_min(TimeGenerated,*) by Computer)
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated) by Computer
修复查询:
let MinTime = ago(1d);
Heartbeat
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer
| union (
Perf
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer)
| summarize min(TimeGenerated) by Computer
度量值始终大于指定的实际时间。 例如,如果查询上的筛选器为 7 天,则系统可能会扫描 7.5 或 8.1 天。 该变体源于系统将数据分成不同大小的块。 为了确保扫描所有相关记录,系统会扫描整个分区。 该分区可能涵盖几个小时甚至不止一天的数据。
在某些情况下,系统无法提供对时间范围的准确测量。 在大多数情况下,如果查询范围少于一天或者是查询为多工作区查询,就会出现这种现象。
重要
此指标仅显示在紧邻群集中处理的数据。 在多区域查询中,它仅显示其中一个区域。 在多工作区查询中,它可能不包括所有工作区。
Azure 数据资源管理器使用多个存储层:内存中、本地 SSD 磁盘,以及速度慢得多的 Azure Blob。 数据越新,越有可能存储在性能更高且延迟更小的层中,这能减少查询持续时间和 CPU 占用。 除了数据本身以外,系统还有元数据的缓存。 数据越旧,其元数据在缓存中的可能性就越小。
处理超过 14 天的数据的查询将被视为其使用过多资源。
有些查询需要使用旧数据,但也有误用旧数据的情况。 执行查询时,如果没有在其元数据中提供时间范围并且不是所有表引用都包含针对 TimeGenerated
列的筛选器,则会发生这种情况。 在这些情况下,系统将扫描该表中存储的所有数据。 当数据保留时间较长时,它可能会涵盖较长的时间范围。 因此会扫描在存在时间上与数据保留期一样长的数据。
下面是这种情况的示例:
请参阅上一部分中的示例和注释,因为它们在本例中也相关。
在以下情况下,可能会跨不同的区域执行单个查询。 例如:
跨区域执行查询要求系统在后端序列化和传输通常比查询最终结果大得多的大块中间数据。 它还限制了系统执行优化和试探法以及使用缓存的能力。
如果没有必要扫描所有这些区域,则应调整范围以减少涵盖的区域。 如果资源范围已最小化,但仍使用了许多区域,则可能是因配置错误而导致的。 例如,审核日志和诊断设置发送到不同区域中的不同工作区,或者存在多个诊断设置配置。
涵盖的区域数量超过三个的查询被视为消耗过多资源的查询。 涵盖的区域数量超过六个的查询被视为滥用查询,可能会受到限制。
重要
当查询跨多个区域运行时,CPU 和数据度量将不准确,并且将仅显示其中一个区域上的度量。
工作区是用于隔离和管理日志数据的逻辑容器。 后端会优化选定区域内物理群集上的工作区放置。
以下情况可能会导致实例使用多个工作区:
跨区域和跨群集执行查询要求系统在后端序列化和传输通常比查询最终结果大得多的大块中间数据。 它还限制了系统执行优化和试探法以及使用缓存的能力。
涵盖的工作区数量超过五个的查询被视为消耗过多资源的查询。 查询不能跨越 100 个以上的工作区。
重要
Azure Monitor 日志使用 Azure 数据资源管理器的大型群集来运行查询。 这些群集的规模各不相同,且可能具有多达数十个计算节点。 系统会根据工作区放置逻辑和容量自动缩放群集。
为了高效地执行查询,系统会根据处理查询时所需的数据将查询分区并分布到不同的计算节点上。 在某些情况下,系统无法有效地执行此步骤,这可能会导致查询持续时间较长。
可能会降低并行度的查询行为包括:
dcount
函数可选参数来降低精度。shuffle join
作为替代方法。培训
模块
引导式项目 - 使用 KQL 分析 Azure Monitor 中的日志 - Training
编写日志查询,深入了解你的业务、IT 运营和性能。 使用 Kusto 查询语言 (KQL) 提取 Azure Monitor Log Analytics 中的日志数据。