高版本IIS下Advanced Logging替代方案及模式过滤问题咨询

方案1：Azure Monitor工作区侧处理（改造成本最低，无需调整现有采集链路） #

所有日志已经全量上传到Azure Monitor工作区，可直接在查询或入库环节实现过滤：

• 临时查询场景：直接在KQL查询语句中加后缀匹配规则即可
  仅筛选.asp结尾请求示例：

  W3CIISLog
  | where csUriStem endswith ".asp"
  

  排除.png结尾请求示例：

  W3CIISLog
  | where csUriStem !endswith ".png"
  

• 长期存储场景：配置*数据收集规则(DCR)*的转换逻辑，日志入库前自动过滤不符合规则的条目，直接降低存储成本，转换逻辑语法和上述KQL查询规则完全一致。

方案2：IIS端原生过滤（从源头减少冗余日志生成） #

不需要依赖Azure侧功能，直接在IIS本地实现日志过滤：

• 如果允许拦截不符合规则的请求：直接使用IIS自带的请求筛选功能，添加对应后缀的允许/拒绝规则，被拦截的请求默认不会写入IIS本地日志。
• 如果不允许拦截请求仅需过滤日志：可以配置IIS Failed Request Tracing 规则，或者开发轻量自定义日志模块，仅将符合后缀规则的请求写入日志文件，再由Microsoft Monitoring Agent采集上传。

方案3：Agent采集端过滤（在本地完成过滤后再上传） #

不需要修改IIS配置也不需要调整Azure侧入库规则，直接配置Microsoft Monitoring Agent的自定义日志采集规则，设置仅采集匹配对应后缀的日志行，过滤完成后再上传到Azure Monitor工作区。 #

三种方案可根据实际场景灵活选择，均无需额外安装第三方IIS日志工具即可实现需求。

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