Apache SkyWalking Redis 监控实战基于 redis-exporter 的指标采集与基于 Fluent Bit 的慢命令分析【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking本指南聚焦 Apache SkyWalking OAP 后端对 Redis 的监控方案讲解两条完整数据链路一是通过 redis-exporter OpenTelemetry Collector 采集 Redis 服务/实例级性能指标二是通过 Fluent Bit 等日志采集器收集 Redis 慢命令slow log并汇入慢 SQL 分析体系。读完本文你将掌握 Redis 监控在 SkyWalking 中的部署步骤、指标定义与 MAL/LAL 规则原理以及如何按需自定义监控面板。整体架构与数据流SkyWalking 对 Redis 的监控采用采集器 遥测传输 后端分析的分层架构监控对象在 OAP 中被建模为Layer: REDIS的Service每台 Redis 服务器对应一个Instance。指标数据流redis-exporter 链路redis-exporter 从 Redis 实例采集指标数据OpenTelemetry Collector 通过 Prometheus Receiver 抓取 redis-exporter 暴露的指标再通过 OpenTelemetry gRPC Exporter 推送给 SkyWalking OAP ServerOAP Server 使用 MALMeter Analysis Language 解析表达式对指标进行过滤、计算、聚合后存储。慢命令数据流Fluent Bit 链路周期性执行 Redis 命令如SLOWLOG GET采集慢日志并写入本地文件Fluent Bit 采集本地慢日志文件Fluent Bit 通过 HTTP 以原生 meter API 将数据发送给 SkyWalking OAP ServerOAP Server 使用 LALLog Analysis Language 解析、抽取并存储结果。两条链路分别解决宏观性能指标与微观慢命令诊断两类问题互补构成完整的 Redis 可观测能力。指标监控redis-exporter 链路搭建前置组件redis-exporter负责从 Redis 拉取指标并暴露为 Prometheus 格式OpenTelemetry Collector负责抓取 redis-exporter 指标并转发给 OAPSkyWalking OpenTelemetry ReceiverOAP 端接收 OpenTelemetry 协议数据的入口配置方式参见 OpenTelemetry receiver。参考配置OpenTelemetry Collector仓库 e2e 测试目录中提供了完整可用的 Collector 配置 otel-collector-config.yaml其核心结构如下receivers: prometheus: config: scrape_configs: - job_name: redis-monitoring scrape_interval: 5s static_configs: - targets: [redis_exporter_1:9121, redis_exporter_2:9121, redis_exporter_3:9121] labels: host_name: root[root] processors: batch: exporters: otlp: endpoint: oap:11800 tls: insecure: true service: pipelines: metrics: receivers: - prometheus processors: - batch exporters: - otlp配置要点job_name: redis-monitoring是后续 MAL 规则中filter的依据MAL 规则正是通过tags.job_name redis-monitoring来识别这批指标scrape_interval: 5s控制抓取频率可根据监控精度与资源开销权衡调整labels.host_name用于标识 Redis 主机MAL 规则会将其加工为服务名见下文exporters.otlp.endpoint: oap:11800指向 OAP 的 gRPC 端口insecure: true表示明文传输。指标定义与 MAL 规则解析指标定义与表达式规则位于 OAP 后端的/config/otel-rules/redis目录在仓库中对应 otel-rules/redis包含两个规则文件redis-service.yaml服务级与redis-instance.yaml实例级。服务级规则redis-service.yamlredis-service.yaml 的关键配置filter: { tags - tags.job_name redis-monitoring } # The OpenTelemetry job name expSuffix: tag({tags - tags.host_name redis:: tags.host_name}).service([host_name] , Layer.REDIS) metricPrefix: meter_redisfilter仅接收来自redis-monitoring任务的指标expSuffix将host_name加工为redis::host形式的服务名并声明Layer.REDISmetricPrefix: meter_redis为生成的指标统一添加meter_redis前缀因此面板上的指标名形如meter_redis_uptime。实例级规则redis-instance.yamlredis-instance.yaml 在服务级基础上增加了实例维度expSuffix: tag({tags - tags.host_name redis:: tags.host_name}).service([host_name] , Layer.REDIS).instance([host_name], [service_instance_id], Layer.REDIS)即每台 Redis 服务器由host_name与service_instance_id组合标识会作为Layer: REDIS服务下的独立Instance呈现。支持的监控指标以下是 OAP 为 Redis 服务提供的内置监控面板指标数据源均为 redis-exporter监控面板单位指标名说明Uptime天meter_redis_uptimeRedis 运行时长Connected Clientsmeter_redis_connected_clients已连接的客户端数量Blocked Clientsmeter_redis_blocked_clients被阻塞的客户端数量Memory Max BytesMBmeter_redis_memory_max_bytes内存上限Hits Rate%meter_redis_hit_rate将 Redis 用作缓存时的命中率Average Time Spend By Command秒meter_redis_average_time_spent_by_command各类命令的平均执行耗时Total Commands Trendmeter_redis_total_commands_rate命令总数趋势速率DB keysmeter_redis_evicted_keys_total / meter_redis_expired_keys_total / meter_redis_db_keys被淘汰 / 过期 / 总体的键数量Net Input/Output BytesKBmeter_redis_net_input_bytes / meter_redis_net_output_bytes网络输入 / 输出总字节数Memory Usage%meter_redis_memory_used_bytes / meter_redis_memory_max_bytes内存使用百分比Total Time Spend By Command Trendmeter_redis_commands_duration / meter_redis_commands_total命令总耗时趋势关键指标的 MAL 表达式解读在 redis-service.yaml 中几个代表性指标表达式metricsRules: - name: uptime exp: redis_uptime_in_seconds.max([host_name,service_instance_id]) - name: hit_rate exp: (redis_keyspace_hits_total * 100 / (redis_keyspace_misses_total redis_keyspace_hits_total)).sum([service_instance_id,host_name]) - name: total_commands_rate exp: redis_commands_total.sum([cmd,host_name,service_instance_id]).rate(PT1M) - name: commands_duration exp: redis_commands_duration_seconds_total.sum([host_name,cmd,service_instance_id])uptime对秒级 uptime 取最大值得到实例运行时长hit_rate由命中次数与命中 未命中之比计算得出是缓存场景下的核心健康指标total_commands_rate与commands_duration按命令类型cmd维度聚合再通过.rate(PT1M)计算每分钟速率支撑命令趋势与耗时趋势面板实例级规则如instance_memory_usage则直接以redis_memory_used_bytes * 100 / redis_memory_max_bytes计算内存使用率百分比。慢命令监控Slow Log 采集链路搭建Redis 慢日志Slow Log记录执行时间超过阈值的命令SkyWalking 借助 Fluent Bit或其他日志采集器将其纳入慢 SQL 监控体系。前置组件Fluent Bit日志采集器配置参见 fluent-bit.confRedis 慢日志配置参考 redis.conf周期性执行采集脚本参考 slowlog.sh。Redis 慢日志配置在 redis.conf 中慢日志由两个关键配置项控制slowlog-log-slower-than 1000 slowlog-max-len 1200slowlog-log-slower-than执行时间超过该值单位毫秒的命令会被记入慢日志。示例中为1000即超过 1 秒的命令会被记录slowlog-max-len慢日志文件中最多保存的慢日志条数示例中为1200条。周期采集脚本slowlog.sh 展示了核心采集逻辑len$(/usr/local/bin/redis-cli -h redis_1 slowlog len) if [[ $len -gt 0 ]]; then result$(/usr/local/bin/redis-cli -h redis_1 slowlog get $len) single_line_log$(echo $result | tr \n ) processed_result$(echo $single_line_log | sed s/\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}:[0-9]\{1,5\}/\n/g) echo $processed_result /scripts/slowlog.log fi /usr/local/bin/redis-cli -h redis_1 slowlog reset该脚本依次执行SLOWLOG LEN、SLOWLOG GET、SLOWLOG RESET先查询慢日志条数再取出全部慢日志并将多行压成单行、按IP:port时间戳切分后追加写入/scripts/slowlog.log最后重置慢日志避免重复采集。在 e2e 测试中脚本由 cron 周期性触发调度配置见 crontable.txt* * * * * /scripts/slowlog.sh即每分钟执行一次采集。Fluent Bit 采集与转换fluent-bit.conf 负责读取慢日志文件并发送给 OAP[SERVICE] flush 1 log_level info parsers_File fluent-bit-parser.conf [INPUT] name tail path /scripts/slowlog.log read_from_head true parser my-log-format [FILTER] name lua match * script fluent-bit-script.lua call rewrite_body [OUTPUT] name stdout match * format json [OUTPUT] name http match * host oap port 12800 uri /v3/logs format json[INPUT] tail以my-log-format解析器跟踪慢日志文件read_from_head true表示从头开始读取解析器正则定义在 fluent-bit-parser.conf 中用于从日志行中提取语句主体[FILTER] lua调用 fluent-bit-script.lua 中的rewrite_body函数将原始日志重组为带layerREDIS、service、query_time、statement等字段的结构化 JSON[OUTPUT] http将 JSON 通过 HTTP 发送到 OAP 的/v3/logs接口端口12800。Lua 脚本中有一行关键注释值得注意e2e 中服务名被简单设置为redis::root[root]实际生产部署时建议使用ip:port作为服务名以区分不同的 Redis 实例。LAL 规则解析OAP 端使用 LAL 处理 Fluent Bit 上报的日志规则文件位于/config/lal/redis-slowsql.yaml仓库中对应 lal/redis-slowsql.yamlrules: - name: redis-slowsql layer: REDIS 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 { } }该规则将日志解析为 JSON抽取layer、service、time并在日志类型为SLOW_SQL时抽取id、statement、query_time最终输出为SlowSQL类型数据——与 SkyWalking 既有的慢 SQL 分析、展示体系完全打通。慢命令监控指标慢命令监控面向Layer: REDIS的 Service 提供如下指标数据源为 fluentbit监控面板单位指标名说明Slow Statementsmstop_n_database_statementRedis 慢命令的延迟与语句内容top_n_database_statement与慢 SQL 体系共用指标模型可在 UI 中按延迟排序查看 Top N 慢命令。自定义扩展无论是指标链路还是慢命令链路你都可以自定义自己的指标、表达式与面板指标定义与表达式修改/config/otel-rules/redis仓库路径 otel-rules/redis下的redis-service.yaml、redis-instance.yaml按 MAL 语法增减metricsRules条目即可慢命令规则修改/config/lal/redis-slowsql.yaml仓库路径 lal/redis-slowsql.yaml可调整字段抽取与输出类型面板配置Redis 监控面板配置随 SkyWalking Horizon UI 包apache/skywalking-horizon-ui分发OAP 后端不再托管 UI 面板 JSON自定义面板需在 Horizon UI 侧完成。注意事项Redis 慢日志配置项slowlog-log-slower-than与slowlog-max-len需按业务实际调整前者决定多慢算慢毫秒后者决定慢日志的保留容量e2e 测试中使用 cron 周期性执行 Redis 命令抓取慢日志并写入本地文件再由 Fluent Bit 采集转发给 OAP生产环境中除 cron Fluent Bit 外也可以采用其他周期获取慢日志并上报 OAP 的方式如自研脚本直连 OAP HTTP 接口核心是保证日志格式与 LAL 规则中的字段约定一致完整的 e2e 用例配置含 docker-compose、期望结果校验等可在 test/e2e-v2/cases/redis 目录中查看redis-exporter子目录即指标链路用例是理解端到端配置的最佳参考实现。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache SkyWalking Redis 监控实战：基于 redis-exporter 的指标采集与基于 Fluent Bit 的慢命令分析
Apache SkyWalking Redis 监控实战基于 redis-exporter 的指标采集与基于 Fluent Bit 的慢命令分析【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking本指南聚焦 Apache SkyWalking OAP 后端对 Redis 的监控方案讲解两条完整数据链路一是通过 redis-exporter OpenTelemetry Collector 采集 Redis 服务/实例级性能指标二是通过 Fluent Bit 等日志采集器收集 Redis 慢命令slow log并汇入慢 SQL 分析体系。读完本文你将掌握 Redis 监控在 SkyWalking 中的部署步骤、指标定义与 MAL/LAL 规则原理以及如何按需自定义监控面板。整体架构与数据流SkyWalking 对 Redis 的监控采用采集器 遥测传输 后端分析的分层架构监控对象在 OAP 中被建模为Layer: REDIS的Service每台 Redis 服务器对应一个Instance。指标数据流redis-exporter 链路redis-exporter 从 Redis 实例采集指标数据OpenTelemetry Collector 通过 Prometheus Receiver 抓取 redis-exporter 暴露的指标再通过 OpenTelemetry gRPC Exporter 推送给 SkyWalking OAP ServerOAP Server 使用 MALMeter Analysis Language 解析表达式对指标进行过滤、计算、聚合后存储。慢命令数据流Fluent Bit 链路周期性执行 Redis 命令如SLOWLOG GET采集慢日志并写入本地文件Fluent Bit 采集本地慢日志文件Fluent Bit 通过 HTTP 以原生 meter API 将数据发送给 SkyWalking OAP ServerOAP Server 使用 LALLog Analysis Language 解析、抽取并存储结果。两条链路分别解决宏观性能指标与微观慢命令诊断两类问题互补构成完整的 Redis 可观测能力。指标监控redis-exporter 链路搭建前置组件redis-exporter负责从 Redis 拉取指标并暴露为 Prometheus 格式OpenTelemetry Collector负责抓取 redis-exporter 指标并转发给 OAPSkyWalking OpenTelemetry ReceiverOAP 端接收 OpenTelemetry 协议数据的入口配置方式参见 OpenTelemetry receiver。参考配置OpenTelemetry Collector仓库 e2e 测试目录中提供了完整可用的 Collector 配置 otel-collector-config.yaml其核心结构如下receivers: prometheus: config: scrape_configs: - job_name: redis-monitoring scrape_interval: 5s static_configs: - targets: [redis_exporter_1:9121, redis_exporter_2:9121, redis_exporter_3:9121] labels: host_name: root[root] processors: batch: exporters: otlp: endpoint: oap:11800 tls: insecure: true service: pipelines: metrics: receivers: - prometheus processors: - batch exporters: - otlp配置要点job_name: redis-monitoring是后续 MAL 规则中filter的依据MAL 规则正是通过tags.job_name redis-monitoring来识别这批指标scrape_interval: 5s控制抓取频率可根据监控精度与资源开销权衡调整labels.host_name用于标识 Redis 主机MAL 规则会将其加工为服务名见下文exporters.otlp.endpoint: oap:11800指向 OAP 的 gRPC 端口insecure: true表示明文传输。指标定义与 MAL 规则解析指标定义与表达式规则位于 OAP 后端的/config/otel-rules/redis目录在仓库中对应 otel-rules/redis包含两个规则文件redis-service.yaml服务级与redis-instance.yaml实例级。服务级规则redis-service.yamlredis-service.yaml 的关键配置filter: { tags - tags.job_name redis-monitoring } # The OpenTelemetry job name expSuffix: tag({tags - tags.host_name redis:: tags.host_name}).service([host_name] , Layer.REDIS) metricPrefix: meter_redisfilter仅接收来自redis-monitoring任务的指标expSuffix将host_name加工为redis::host形式的服务名并声明Layer.REDISmetricPrefix: meter_redis为生成的指标统一添加meter_redis前缀因此面板上的指标名形如meter_redis_uptime。实例级规则redis-instance.yamlredis-instance.yaml 在服务级基础上增加了实例维度expSuffix: tag({tags - tags.host_name redis:: tags.host_name}).service([host_name] , Layer.REDIS).instance([host_name], [service_instance_id], Layer.REDIS)即每台 Redis 服务器由host_name与service_instance_id组合标识会作为Layer: REDIS服务下的独立Instance呈现。支持的监控指标以下是 OAP 为 Redis 服务提供的内置监控面板指标数据源均为 redis-exporter监控面板单位指标名说明Uptime天meter_redis_uptimeRedis 运行时长Connected Clientsmeter_redis_connected_clients已连接的客户端数量Blocked Clientsmeter_redis_blocked_clients被阻塞的客户端数量Memory Max BytesMBmeter_redis_memory_max_bytes内存上限Hits Rate%meter_redis_hit_rate将 Redis 用作缓存时的命中率Average Time Spend By Command秒meter_redis_average_time_spent_by_command各类命令的平均执行耗时Total Commands Trendmeter_redis_total_commands_rate命令总数趋势速率DB keysmeter_redis_evicted_keys_total / meter_redis_expired_keys_total / meter_redis_db_keys被淘汰 / 过期 / 总体的键数量Net Input/Output BytesKBmeter_redis_net_input_bytes / meter_redis_net_output_bytes网络输入 / 输出总字节数Memory Usage%meter_redis_memory_used_bytes / meter_redis_memory_max_bytes内存使用百分比Total Time Spend By Command Trendmeter_redis_commands_duration / meter_redis_commands_total命令总耗时趋势关键指标的 MAL 表达式解读在 redis-service.yaml 中几个代表性指标表达式metricsRules: - name: uptime exp: redis_uptime_in_seconds.max([host_name,service_instance_id]) - name: hit_rate exp: (redis_keyspace_hits_total * 100 / (redis_keyspace_misses_total redis_keyspace_hits_total)).sum([service_instance_id,host_name]) - name: total_commands_rate exp: redis_commands_total.sum([cmd,host_name,service_instance_id]).rate(PT1M) - name: commands_duration exp: redis_commands_duration_seconds_total.sum([host_name,cmd,service_instance_id])uptime对秒级 uptime 取最大值得到实例运行时长hit_rate由命中次数与命中 未命中之比计算得出是缓存场景下的核心健康指标total_commands_rate与commands_duration按命令类型cmd维度聚合再通过.rate(PT1M)计算每分钟速率支撑命令趋势与耗时趋势面板实例级规则如instance_memory_usage则直接以redis_memory_used_bytes * 100 / redis_memory_max_bytes计算内存使用率百分比。慢命令监控Slow Log 采集链路搭建Redis 慢日志Slow Log记录执行时间超过阈值的命令SkyWalking 借助 Fluent Bit或其他日志采集器将其纳入慢 SQL 监控体系。前置组件Fluent Bit日志采集器配置参见 fluent-bit.confRedis 慢日志配置参考 redis.conf周期性执行采集脚本参考 slowlog.sh。Redis 慢日志配置在 redis.conf 中慢日志由两个关键配置项控制slowlog-log-slower-than 1000 slowlog-max-len 1200slowlog-log-slower-than执行时间超过该值单位毫秒的命令会被记入慢日志。示例中为1000即超过 1 秒的命令会被记录slowlog-max-len慢日志文件中最多保存的慢日志条数示例中为1200条。周期采集脚本slowlog.sh 展示了核心采集逻辑len$(/usr/local/bin/redis-cli -h redis_1 slowlog len) if [[ $len -gt 0 ]]; then result$(/usr/local/bin/redis-cli -h redis_1 slowlog get $len) single_line_log$(echo $result | tr \n ) processed_result$(echo $single_line_log | sed s/\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}:[0-9]\{1,5\}/\n/g) echo $processed_result /scripts/slowlog.log fi /usr/local/bin/redis-cli -h redis_1 slowlog reset该脚本依次执行SLOWLOG LEN、SLOWLOG GET、SLOWLOG RESET先查询慢日志条数再取出全部慢日志并将多行压成单行、按IP:port时间戳切分后追加写入/scripts/slowlog.log最后重置慢日志避免重复采集。在 e2e 测试中脚本由 cron 周期性触发调度配置见 crontable.txt* * * * * /scripts/slowlog.sh即每分钟执行一次采集。Fluent Bit 采集与转换fluent-bit.conf 负责读取慢日志文件并发送给 OAP[SERVICE] flush 1 log_level info parsers_File fluent-bit-parser.conf [INPUT] name tail path /scripts/slowlog.log read_from_head true parser my-log-format [FILTER] name lua match * script fluent-bit-script.lua call rewrite_body [OUTPUT] name stdout match * format json [OUTPUT] name http match * host oap port 12800 uri /v3/logs format json[INPUT] tail以my-log-format解析器跟踪慢日志文件read_from_head true表示从头开始读取解析器正则定义在 fluent-bit-parser.conf 中用于从日志行中提取语句主体[FILTER] lua调用 fluent-bit-script.lua 中的rewrite_body函数将原始日志重组为带layerREDIS、service、query_time、statement等字段的结构化 JSON[OUTPUT] http将 JSON 通过 HTTP 发送到 OAP 的/v3/logs接口端口12800。Lua 脚本中有一行关键注释值得注意e2e 中服务名被简单设置为redis::root[root]实际生产部署时建议使用ip:port作为服务名以区分不同的 Redis 实例。LAL 规则解析OAP 端使用 LAL 处理 Fluent Bit 上报的日志规则文件位于/config/lal/redis-slowsql.yaml仓库中对应 lal/redis-slowsql.yamlrules: - name: redis-slowsql layer: REDIS 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 { } }该规则将日志解析为 JSON抽取layer、service、time并在日志类型为SLOW_SQL时抽取id、statement、query_time最终输出为SlowSQL类型数据——与 SkyWalking 既有的慢 SQL 分析、展示体系完全打通。慢命令监控指标慢命令监控面向Layer: REDIS的 Service 提供如下指标数据源为 fluentbit监控面板单位指标名说明Slow Statementsmstop_n_database_statementRedis 慢命令的延迟与语句内容top_n_database_statement与慢 SQL 体系共用指标模型可在 UI 中按延迟排序查看 Top N 慢命令。自定义扩展无论是指标链路还是慢命令链路你都可以自定义自己的指标、表达式与面板指标定义与表达式修改/config/otel-rules/redis仓库路径 otel-rules/redis下的redis-service.yaml、redis-instance.yaml按 MAL 语法增减metricsRules条目即可慢命令规则修改/config/lal/redis-slowsql.yaml仓库路径 lal/redis-slowsql.yaml可调整字段抽取与输出类型面板配置Redis 监控面板配置随 SkyWalking Horizon UI 包apache/skywalking-horizon-ui分发OAP 后端不再托管 UI 面板 JSON自定义面板需在 Horizon UI 侧完成。注意事项Redis 慢日志配置项slowlog-log-slower-than与slowlog-max-len需按业务实际调整前者决定多慢算慢毫秒后者决定慢日志的保留容量e2e 测试中使用 cron 周期性执行 Redis 命令抓取慢日志并写入本地文件再由 Fluent Bit 采集转发给 OAP生产环境中除 cron Fluent Bit 外也可以采用其他周期获取慢日志并上报 OAP 的方式如自研脚本直连 OAP HTTP 接口核心是保证日志格式与 LAL 规则中的字段约定一致完整的 e2e 用例配置含 docker-compose、期望结果校验等可在 test/e2e-v2/cases/redis 目录中查看redis-exporter子目录即指标链路用例是理解端到端配置的最佳参考实现。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考