Kusto（Application Insights）字符串查询异常：日志匹配问题排查

核心原因：KQL like 操作符的使用误区 #

在Azure Monitor的KQL查询语言中，like 操作符只有在包含通配符（*/?/[]）时才会执行模糊匹配。如果未添加通配符，like 等价于精确匹配（==）。

你之前的查询：

traces
| where message like "Acting on order. OrderId: 1"

实际是在查找完全等于该字符串的日志条目，但你的日志消息实际是 "Acting on order. OrderId: 1, OrderChargeId: 1"，长度更长，自然无法匹配。同理，like "Acting on order. O" 也是在找完全等于该字符串的条目，同样不匹配。

正确的查询方式 #

方式1：使用 contains 做包含匹配（推荐） #

contains 操作符专门用于检查字符串是否包含指定子串，无需通配符：

traces
| where message contains "Acting on order. OrderId: 1"

方式2：给 like 添加通配符 #

如果坚持使用 like，需要在字符串末尾添加 * 来匹配后续任意字符：

traces
| where message like "Acting on order. OrderId: 1*"

或者前后都加*匹配任意位置的子串：

traces
| where message like "*Acting on order. O*"

方式3：利用结构化日志的自定义属性查询（最优） #

你的代码使用了ILogger的结构化日志写法（占位符{orderId}/{orderChargeId}），这些参数会被自动存入Application Insights的customDimensions字段中。直接查询这些属性不仅更高效，还能避免字符串匹配的误差：

traces
| where message contains "Acting on order."
| where customDimensions.orderId == "1"

注意：如果orderId是数字类型，去掉引号即可。

日志写法验证 #

你的日志代码写法是正确的：

_logger.LogInformation("Acting on order. OrderId: {orderId}, OrderChargeId: {orderChargeId}", orderId, orderChargeId);

这种结构化日志的写法是官方推荐的，既方便后续的属性查询，也能避免日志注入风险。

内容的提问来源于stack exchange，提问作者BenjiFB