日志分析查询优化

时间:2019-04-04 22:47:11

标签: azure-log-analytics kusto

我在日志分析上运行此查询

                                        Perf
                                        | where TimeGenerated >= ago(5m) 
                                        | join kind = inner
                                            ( 
                                                Heartbeat  
                                                | where TimeGenerated >= ago(5m)
                                                | summarize arg_max(TimeGenerated, *) 

                                                by SourceComputerId
                                            ) on Computer
                                        | summarize arg_max(TimeGenerated, *) by SourceComputerId, CounterName
                                        | extend  Indicator = strcat(ObjectName,'-', CounterName)
                                        | summarize dict = make_dictionary
                                        (   
                                            pack
                                            (      
                                                  'WorkspaceId' 
                                                ,  TenantId
                                                ,  Indicator       
                                                ,  CounterValue
                                                ,  'TimeGenerated'   
                                                ,  TimeGenerated
                                                ,  'Computer'
                                                ,  Computer
                                            )
                                        )  by SourceComputerId
                                        | evaluate bag_unpack(dict)

但是有点慢。有什么方法可以对其进行优化,我想以最快的速度获得相同的结果。

1 个答案:

答案 0 :(得分:1)

要说出join每条支路的数据大小(例如记录数)和SourceComputerId列的基数,要说出某种挑战性。

我建议您翻阅query best practices文档,其中涵盖了几种优化技术,看看是否有帮助

更新:明确提及可能对您有用的最佳做法:(供您验证)

  • 使用联接运算符时-将行数较少的表选为第一个(最左侧)。
  • 当左侧较小(最多100,000条记录)而右侧较大时,建议使用hint.strategy = broadcast。
  • 当连接的两端都太大并且连接密钥具有高基数时,建议使用hint.strategy = shuffle。
  • 当summary运算符的group by键具有高基数(最佳实践:超过100万)时,建议使用hint.strategy = shuffle。