技能介绍

你在查什么、为什么容易踩坑

Kusto 查询语言（KQL）是 Azure Data Explorer、Fabric EventHouse、Azure Monitor Log Analytics、Microsoft Sentinel 等服务的原生查询语言。写法是管道式：数据从左向右经过 | 链上的运算符。和 SQL 习惯不同，查询平面（从表名、let、print 开始）与管理平面（以 .show、.create 开头）不能混用——第一个 token 带点号就是管理命令。

工程里常见失败点包括：在 summarize by、order by、join on 里直接用 dynamic 列；联接只支持 == 等值；extract_all 必须带捕获组 ()；窗口函数前未 serialize；大表先聚合后过滤导致 E_LOW_MEMORY_CONDITION 或联接基数爆炸触发 E_RUNAWAY_QUERY。

技能如何组织能力与步骤

本技能按「能写对、能控成本、能自救」展开：

语法与约束：管道语义、查询 vs 管理；dynamic 在 by/on/order by 中需 tostring() / tolong() / todouble()。
联接：范围联接用 bin() 预分桶；on 两侧只能是列实体；大联接前用基数检查（例如两侧行数、dcount）。
正则与文本：extract、extract_all、parse、matches regex、replace_regex，避免为简单匹配退回 Python。
内存与结果大小：大表先 | count，summarize 前 | where；探索用 | take N；宽表/向量列用 | project；多次引用的子查询考虑 materialize()。
时间与字符串：datetime() 字面量格式、bin/ago/between；计算字符串比较时两侧显式 tostring()。
错误恢复：对照「错误消息 → 原因 → 修复」表逐项改语法，同一查询修复失败两次再换思路；复杂 summarize by 表达式先 extend 再按列聚合。

文档中的 ✅ 示例可在公共集群 help.kusto.windows.net 的 Samples 库（如 StormEvents、SimpleGraph、nyctaxi）上直接验证。

适用边界

技能侧重查询编写与排错模式，不是集群 provisioning 或权限治理的完整手册。部分运算符、插件在不同引擎/集群上可能不可用（错误里会出现 not recognized 或 plugin doesn't exist），需查该环境支持或换等价写法。高级向量相似度、地理、图、时间序列等细节在引用文档 references/advanced-patterns.md 中展开，本介绍不重复罗列全部 API。

截图预览

使用场景

在 Log Analytics 工作区排查告警，需要用管道式 `where`、`summarize` 按时间窗统计事件量，并避免全表扫描触发内存错误。
在 Microsoft Sentinel 中关联身份表与登录日志，编写仅等值 `==` 的 join，并在联接前检查两侧基数以防 E_RUNAWAY_QUERY。
在 ADX 集群上从半结构化 Message 字段提取字段，用 `parse` 或带捕获组的 `extract_all`，而不是导出到 Python 再处理。
在 Fabric EventHouse 做探索性查询时，先 `count` 与 `where` 过滤分区键，结果用 `take`/`top` 限制行数并 `project` 去掉向量列。

适合人员

负责 Azure Monitor / Sentinel 检测规则的 SOC 分析师，需要把 KQL 写稳并读懂 dynamic、join 与内存类报错。
维护 ADX 或 Fabric Real-Time Intelligence 的数据工程师，要在亿级表上先过滤再聚合，并掌握 materialize 与子查询复用模式。
用 Log Analytics 做 incident 时间线还原的 SRE，需要 `bin`、`ago`、`between` 分桶过滤，以及窗口函数前的 serialize 要求。
从 SQL 转到 Kusto 的可观测性开发，需要区分查询平面与管理命令，并查错误对照表做针对性修语法而非整段重写。