可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载SkyWalking OAP 的 Log Analyzer 模块承载了原生日志数据的接入、结构化解析、持久化与指标化全链路它通过领域专用语言Log Analysis LanguageLAL对日志内容进行解析parsing、抽取extracting与保存saving并复用Meter Analysis LanguageMAL引擎对日志中提取的指标做进一步计算。读完本文你将掌握log-analyzer模块的完整配置方式lalFiles/malFiles、LAL 脚本的核心语法parser / extractor / sink / sampler、内置脚本的使用方法以及日志与 Trace、指标体系相互关联的底层实现原理。Log Analyzer 在 OAP 中的定位日志分析是 OAP 后端指标Metrics、链路Traces、日志Logs三支柱之一。官方文档 log-analyzer.md 明确了该模块的职责支持native log dataSkyWalking 原生日志协议数据也兼容 OTLP 日志等来源使用LAL将非结构化的原始日志解析为结构化字段抽取服务名、实例名、端点、Trace ID 等元数据并决定日志的保存与否使用MAL 引擎即log-mal-rules目录下的 MAL 规则对从日志中产生的指标继续做聚合计算例如按日志级别统计条数、计算响应时间百分位等。从源码结构看该模块位于 oap-server/analyzer/log-analyzer其模块定义与配置项解析入口分别为 LogAnalyzerModule.java 与 LogAnalyzerModuleConfig.javaLAL 词法/语法定义在 LALLexer.g4 与 LALParser.g4可确认这是一套基于 ANTLR 编译的 DSL 体系。模块配置application.yml 中的 log-analyzer 段Log Analyzer 是标准的 SkyWalking 模块化配置。log-analyzer配置段的核心内容如下完整文件见 application.ymllog-analyzer: selector: ${SW_LOG_ANALYZER:default} default: lalFiles: ${SW_LOG_LAL_FILES:envoy-als,mesh-dp,mysql-slowsql,pgsql-slowsql,redis-slowsql,k8s-service,nginx,envoy-ai-gateway,miniprogram,ai-agent,default} malFiles: ${SW_LOG_MAL_FILES:nginx,miniprogram-wechat,miniprogram-alipay}各配置项含义如下配置项环境变量默认值含义selectorSW_LOG_ANALYZERdefault选择器指定启用哪个实现default即内置实现lalFilesSW_LOG_LAL_FILESenvoy-als,mesh-dp,mysql-slowsql,pgsql-slowsql,redis-slowsql,k8s-service,nginx,envoy-ai-gateway,miniprogram,ai-agent,default逗号分隔的 LAL 规则文件名不含目录文件位于lal目录malFilesSW_LOG_MAL_FILESnginx,miniprogram-wechat,miniprogram-alipay逗号分隔的 MAL 规则文件名不含目录文件位于log-mal-rules目录用于对日志产生的指标做进一步计算从 LogAnalyzerModuleConfig.java 的源码可以看到两个固定目录常量lalPath lalLAL 脚本目录malPath log-mal-rules日志 MAL 规则目录。配置解析时lalFiles()与malConfigs()都会用逗号Splitter拆分、去空并 trim 结果MAL 文件通过Rules.loadRules(getMalPath(), files)加载为Rule列表加载失败会抛出ModuleStartException导致 OAP 启动失败——这保证了错误规则在启动期即被发现。在 OAP 发行包中这两个目录实际位于 oap-server/server-starter/src/main/resources/lal 与 oap-server/server-starter/src/main/resources/log-mal-rules。提示默认lalFiles中始终包含default即 lal/default.yaml。该脚本的作用是兜底保存所有日志——它只有一个空的sink {}行为等价于 8.5.0 之前的全量落盘逻辑rules: - name: default layer: GENERAL dsl: | filter { sink { } }LAL 脚本的加载与运行机制lalFiles中每个文件对应一套 LAL 规则集。模块启动时LogAnalyzerModuleProvider.java 的start()阶段会执行两步初始化将malFiles中每个 MAL 规则编译为MetricConvert以log-mal-rules:name为 key 注册进内存中的活跃转换器表调用LogFilterListener.Factory.loadStaticRules()编译全部静态 LAL 脚本并注册为日志分析监听器工厂。在运行期日志接收器如 SkyWalking 原生日志接收器、OTLP 日志接收器把解析后的LogMetadata与原始输入交给 LogAnalyzer.java 的doAnalysis()其执行流程为校验日志服务名为空则直接忽略Layer 无效则告警并放弃根据日志的layer为空时先尝试layer: auto规则全部abort后回落到GENERAL创建对应的分析监听器调用parse()将元数据与输入绑定到已编译的 LAL 脚本调用build()真正求值脚本中的 extractor 与 sink完成字段抽取与持久化决策。LAL 的完整语言规范见 docs/en/concepts-and-designs/lal.md下面按核心构件逐一展开。LAL 核心概念Layer 路由每条 LAL 规则都隶属于一个Layer层用于声明日志的分析范围。LAL 规则按 layer 路由——只有与日志 layer 匹配的规则才会被求值。规则中的layer字段可以声明为具体层名如layer: NGINX、layer: MYSQLlayer: auto匹配service.layer缺失的日志OTLP 来源常见脚本需在 extractor 中用layer XXX显式设定abort {}表示不是我的日志交给其他规则drop {}表示是我的日志但被采样丢弃。LAL 文件还可以通过顶层layerDefinitions:块声明自定义 Layer要求大驼峰大写命名、ordinal 唯一且建议 1000使一个 LAL 文件即可自描述一个全新监控目标无需修改 OAP 源码枚举。自定义 Layer 的存储编码为 ordinal 整数因此同一套layerDefinitions必须一致地部署到所有 OAP 节点。内置 Layer 定义可参考 Layer.java。LAL 核心概念Filter、全局函数与 Parser一个filter是 parser、extractor、sink 的编组一条规则可以包含多个 filter每条日志会被发送到规则内的所有 filter各组件按声明顺序顺序执行。日志在 LAL 中以log属性暴露可通过log.service等访问log的完整字段定义见 日志数据协议。全局函数abort快速失败机制从声明处终止剩余 filter 链。例如filter { if (log.service TestingService) { // 不为测试服务浪费资源 abort {} } // ... parsers, extractors, sinks }注意在if中使用regexp时需写成regexp(the expression)形式。tag便捷读取日志标签键的值配合if做条件分流filter { if (tag(TEST_KEY) TEST_VALUE) { ... } }sourceAttribute读取非持久化的源上下文属性OTLP 资源属性如os.name、device.model.identifier。与tag()不同这些值不会持久化到tagsRawData仅在 LAL 处理期间可用若需持久化用tag key: sourceAttribute(attr)选择性写入。三种 ParserParser 负责把原始日志解析为结构化数据解析结果注入parsed属性json/yaml时是键值 Maptext时是捕获组 Map。所有 parser 共享abortOnFailure选项默认true解析失败即中止 filter 链filter { json { abortOnFailure true // 可选这是默认行为 } }json解析 JSON 格式日志体。当 JSON 体为空但存在纯文本体时例如 OTLP 接收器会把所有字符串体都按文本传输会自动尝试把文本体当作 JSON 解析解析成功后该规则会把日志规范化为 JSON 内容类型持久化yaml解析 YAML 格式日志体用法与json一致text含regexp面向非结构化日志使用正则捕获组解析filter { text { abortOnFailure true regexp (?timestamp\\d{8}) (?thread\\w) (?level\\w) (?traceId\\w) (?msg.) } extractor { tag level: parsed.level // 把捕获的 level 写入标签 traceId parsed.traceId // 抽取 traceId用于与 Trace 关联 } }LAL 核心概念Extractor 与指标抽取Extractor 负责从parsed结果中抽取元数据服务名、实例名、端点名、Trace ID 等写回LogData以关联既有 Trace 与指标。标准字段包括标准字段作用service抽取服务名instance抽取服务实例名endpoint抽取端点名traceId/segmentId/spanId抽取 Trace / Segment / Span ID将日志与链路关联timestamp抽取时间戳参数可为毫秒值或带格式的日期字符串如timestamp parsed.time as String, yyyy-MM-dd HH:mm:sslayer抽取 Layer 并写入LogDatatag抽取标签形如tag level: parsed.level, (parsed.statusCode): parsed.statusMsgmetrics从日志生成指标并发送到 Meter 系统metrics是日志通往指标体系的关键桥梁。例如从日志中产生两个指标filter { // ... extractor { service parsed.serviceName metrics { name log_count timestamp parsed.timestamp labels level: parsed.level, service: parsed.service, instance: parsed.instance value 1 } metrics { name http_response_time timestamp parsed.timestamp labels status_code: parsed.statusCode, service: parsed.service, instance: parsed.instance value parsed.duration } } }随后在log-mal-rules目录配置 MAL 规则即可做进一步计算例如按日志级别统计计数、计算响应时间百分位metrics: - name: log_count_debug exp: log_count.tagEqual(level, DEBUG).sum([service, instance]).increase(PT1M) - name: log_count_error exp: log_count.tagEqual(level, ERROR).sum([service, instance]).increase(PT1M) - name: response_time_percentile exp: http_response_time.sum([le, service, instance]).increase(PT5M).histogram().histogram_percentile([50,75,90,95,99])在 nginx.yaml 内置脚本中可以看到真实的生产用法nginx-error-log规则先用regexp解析时间、级别再通过metrics生成nginx_error_log_count指标标签含level、service、service_instance_id该指标由默认启用的log-mal-rules/nginx.yaml继续聚合。LAL 核心概念Sink、Sampler、Dropper 与 EnforcerSink 是 LAL 的持久化层只有显式声明sink {}块日志才会被保存空sink {}表示无条件保存全部日志。sink 内可组合三类控制器Sampler采样器按策略抽样保存。rateLimit(SamplerID) { rpm 1800 }每分钟最多采样 n 条相同 ID 的 sampler 共享同一个实例与重置逻辑possibility(80) {}每条日志有 80% 的伪随机概率被采样。若指定多个 sampler以最后一个为准。Dropper丢弃器无条件丢弃所有日志常用于丢弃 DEBUG 级日志或在一个 filter 已持久化后、另一个仅用于产出指标的 filter 中做收尾dropper {}避免重复落盘。Enforcer强制器无视采样策略强制保存典型场景是即使配置了采样也强制保存 ERROR 级日志或特定用户的日志filter { sink { sampler { // ... sampler configs } if (parsed.level ERROR || parsed.userId TestingUserId) { enforcer { } } } }采样器的实现类位于 oap-server/analyzer/log-analyzer/src/main/java/org/apache/skywalking/oap/log/analyzer/v2/dsl/spec/sink/sampler包括RateLimitingSampler、PossibilitySampler与Sampler接口。内置脚本实战解析lalFiles默认启用的 11 个脚本覆盖了常见的日志分析场景可分别作为模板参考脚本层典型场景default.yamlGENERAL全量保存日志的兜底规则nginx.yamlNGINXNginx 访问日志与错误日志解析状态码、级别产出错误计数指标mysql-slowsql.yamlMYSQL慢 SQL 日志转DatabaseSlowStatement见下文 outputTypepgsql-slowsql.yamlPOSTGRESQLPostgreSQL 慢 SQLredis-slowsql.yamlREDISRedis 慢查询envoy-als.yaml—Envoy ALS 访问日志转采样 Trace 记录k8s-service.yaml—K8s 服务日志mesh-dp.yaml—服务网格数据面日志envoy-ai-gateway.yaml—Envoy AI 网关日志miniprogram.yaml—小程序日志ai-agent.yaml—AI Agent 日志以 mysql-slowsql.yaml 为例它演示了outputType的用法——把日志转换为DatabaseSlowStatement记录rules: - name: mysql-slowsql layer: MYSQL outputType: SlowSQL dsl: | filter { json{ } extractor{ layer parsed.layer as String service parsed.service as String timestamp parsed.time as String if (tag(LOG_KIND) SLOW_SQL) { id parsed.id as String statement parsed.statement as String latency parsed.query_time as Long } } sink { } }这里tag(LOG_KIND) SLOW_SQL是 OAP 区分慢 SQL 日志的约定标记。注意慢 SQL 采样只是把 SQL 标记进候选列表OAP 会按服务统计每topNReportPeriod由SW_CORE_TOPN_REPORT_PERIOD控制默认 10 分钟仅持久化 Top 50。进阶outputType 输出类型机制默认情况下每条 LAL 规则产出Log源对象持久化到存储。部分场景需要把日志转换为其他实体类型此时可在规则级别设置outputTyperules: - name: my-rule layer: MYSQL outputType: SlowSQL # LALOutputBuilder SPI 注册的短名也支持全限定类名 dsl: | filter { // ... }输出类型按以下优先级解析规则级 YAML 配置最高→LALSourceTypeProviderSPI接收器插件为特定 layer 注册的默认输出类型→ 回退Log.class。内置输出类型包括SlowSQLDatabase Slow Statement字段id、statement、latency需要LOG_KINDSLOW_SQL标签SampledTrace网络剖析采样 Trace 记录字段latency、uri、reason、processId、destProcessId、detectPoint、componentId需要LOG_KINDNET_PROFILING_SAMPLED_TRACE标签。开发者若要扩展自定义输出类型实现LALOutputBuilder、继承AbstractLog、注册LALSourceTypeProviderSPI 或定义自定义输入类型可参考 LAL 扩展开发者指南。源码级执行链路小结结合源码可将 Log Analyzer 的完整链路归纳如下配置加载LogAnalyzerModuleConfig 解析lalFiles/malFiles规则编译LogAnalyzerModuleProvider 在start()中加载静态 LAL 脚本与 MAL 转换器LAL 脚本经 ANTLR 语法LALLexer.g4 / LALParser.g4与运行时编译compiler/rt生成可执行脚本运行时路由与求值LogAnalyzer.doAnalysis() 按 layer 匹配规则依次执行 parse → extractor → sink指标化extractor 中的metrics通过 MetricExtractor 发送到 Meter 系统由log-mal-rules的 MAL 规则继续聚合最终进入指标存储与告警体系。通过这套机制非结构化的原始日志得以在 OAP 内被结构化、被关联Trace ID 关联链路、被指标化MAL 聚合从而支撑慢 SQL 分析、错误日志统计、网络剖析采样等场景。建议在动手配置前完整阅读 LAL 语言规范并以lal与log-mal-rules目录中的内置脚本作为起点进行修改验证。赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐SkyWalking OAP 日志分析实战log-analyzer 配置与 LAL 日志分析语言完全指南SkyWalking OAP 日志分析实战log analyzer 配置与 LAL 日志分析语言完全指南 日志分析是 APM 系统补齐可观测性最后一环的关键能可观测性后端微服务云原生SkyWalking OAP 可观测性分析平台OAL、MAL 与 LAL 三大分析语言引擎完全指南SkyWalking OAP 可观测性分析平台OAL、MAL 与 LAL 三大分析语言引擎完全指南 SkyWalking OAPObservability可观测性APM链路追踪指标监控日志分析微服务Apache SkyWalking 日志分析语言LAL完全指南从 DSL 语法到日志、链路与指标联动Apache SkyWalking 日志分析语言LAL完全指南从 DSL 语法到日志、链路与指标联动 导读 Log Analysis LanguageL可观测性后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考