可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载本篇技术指南讲解如何在 Apache SkyWalking 中监控 Redis 服务器覆盖两大场景一是借助redis-exporter OpenTelemetry Collector 采集 Redis 运行指标并汇入 SkyWalking OAP 的 Meter 系统二是借助 fluent-bit 等日志采集器收集 Redis 慢命令Slow Log并通过 LAL 规则解析入库。读完本文你将掌握从零搭建 Redis 监控链路、理解指标命名与 MAL 表达式、自定义面板与告警指标的完整方法。总体架构与数据流SkyWalking 对 Redis 的监控分为两条相互独立的链路它们分别面向「性能指标」与「慢命令语句」两类数据指标链路Metricsredis-exporter → OpenTelemetry Collector → OAPredis-exporter从 Redis 实例采集指标数据OpenTelemetry Collector 通过 Prometheus Receiver 从redis-exporter拉取指标再通过 OpenTelemetry gRPC exporter 推送到 SkyWalking OAP ServerOAP Server 使用 MALMetrics Analysis Language 解析表达式对指标进行过滤、计算、聚合并存储。这条链路中OAP 通过 OpenTelemetry receiver 接收数据最终汇入 Meter 系统。慢命令链路Slow LogRedis Slowlog → fluent-bit → OAP周期性地执行脚本命令采集 Redis 慢日志slowlog并保存到本地文件fluent-bit 等日志采集 Agent 从本地文件读取慢日志fluent-bit 通过 HTTP 调用 SkyWalking 的原生 Meter API即/v3/logs把数据发送到 OAP ServerOAP Server 使用 LALLog Analysis Language 解析表达式提取字段并存储结果。第一部分指标监控Redis server performance接入前的组件准备部署 redis-exporter它会将 Redis 的INFO命令输出转换为 Prometheus 格式的指标并暴露在默认的9121端口。部署 OpenTelemetry Collector。关于 Collector 中 Prometheus Receiver 拉取 redis-exporter 的具体配置可以参考仓库内的 e2e 测试示例 otel-collector-config.yamlreceivers: prometheus: config: scrape_configs: - job_name: redis-monitoring # job 名称MAL 规则中的 filter 依赖它 scrape_interval: 5s # 抓取间隔 static_configs: - targets: [redis_exporter_1:9121, redis_exporter_2:9121, redis_exporter_3:9121] labels: host_name: root[root] # 用于标识 Redis 服务/实例的标签 processors: batch: # 批量处理提升吞吐 exporters: otlp: endpoint: oap:11800 # OAP 的 gRPC 端口 tls: insecure: true service: pipelines: metrics: receivers: - prometheus processors: - batch exporters: - otlp在 SkyWalking 侧启用 OpenTelemetry receiverOAP 默认开启对11800端口 gRPC 数据的接收。从 e2e 测试的 docker-compose.yml 可以看到完整的部署拓扑三台 Redis 实例redis_1、redis_2、redis_3镜像redis:6.0分别对应三个redis_exporter镜像oliver006/redis_exporter:v1.48.0-alpine通过REDIS_ADDRredis_x:6379指定被监控实例地址otel-collector容器挂载上述 Collector 配置并将指标发送到oap:11800。redis_mock容器会预先向redis_1写入 mock.txt 中的模拟数据用于验证 DB keys 等指标。数据模型Service 与 Instance 的映射Redis 监控遵循 SkyWalking 的实体模型Redis 集群cluster在 OAP 中被登记为Layer: REDIS的Service每一个 Redis 服务器被登记为该 Service 下的一个Instance。这个映射关系由 MAL 规则中的expSuffix完成见下文源码。服务级指标redis-service.yaml服务级指标的 MAL 规则位于 otel-rules/redis/redis-service.yamlfilter: { tags - tags.job_name redis-monitoring } # 只处理 job_name 为 redis-monitoring 的指标 expSuffix: tag({tags - tags.host_name redis:: tags.host_name}).service([host_name] , Layer.REDIS) metricPrefix: meter_redis metricsRules: - name: uptime exp: redis_uptime_in_seconds.max([host_name,service_instance_id]) - name: connected_clients exp: redis_connected_clients.sum([host_name,service_instance_id]) # ……其余规则见下文规则中的几个关键点filter指定只接收 OpenTelemetry job 名称为redis-monitoring的数据与 Collector 配置中的job_name严格对应expSuffix将host_name标签改写为redis::host_name形式作为服务名并以Layer.REDIS登记服务redis-service.yaml用.service(...)实例级规则 redis-instance.yaml 额外追加.instance([host_name], [service_instance_id], Layer.REDIS)登记实例metricPrefix: meter_redis表示生成的指标统一以meter_redis为前缀因此最终查询名形如meter_redis_uptime、meter_redis_instance_connected_clients等。实例级指标redis-instance.yaml实例级规则定义了更细粒度的指标见 otel-rules/redis/redis-instance.yamlmetricsRules: - name: instance_uptime exp: redis_uptime_in_seconds - name: instance_memory_usage exp: redis_memory_used_bytes * 100 / redis_memory_max_bytes - name: instance_total_commands_rate exp: redis_commands_total.sum([cmd,host_name,service_instance_id]).rate(PT1M) - name: instance_hit_rate exp: redis_keyspace_hits_total * 100 / (redis_keyspace_misses_total redis_keyspace_hits_total) - name: instance_average_time_spent_by_command exp: (redis_commands_duration_seconds_total.sum([host_name,cmd,service_instance_id]) / redis_commands_total.sum([host_name,cmd,service_instance_id])).rate(PT1M)这些表达式展示了 MAL 的核心能力*、/做四则运算sum([host_name,cmd,service_instance_id])按标签分组聚合.rate(PT1M)计算每分钟速率。例如instance_hit_rate即keyspace_hits / (keyspace_hits keyspace_misses) × 100与文档指标表中的 Hits Rate 一一对应。支持的服务级指标总览监控面板单位指标名Metric Name说明数据来源Uptimedaymeter_redis_uptimeRedis 的运行时长redis-exporterConnected Clientsmeter_redis_connected_clients已连接客户端数量redis-exporterBlocked Clientsmeter_redis_blocked_clients阻塞中的客户端数量redis-exporterMemory Max BytesMBmeter_redis_memory_max_bytes内存上限字节数redis-exporterHits Rate%meter_redis_hit_rate作为缓存时的命中率redis-exporterAverage Time Spend By Commandsecondmeter_redis_average_time_spent_by_command各类命令的平均执行耗时redis-exporterTotal Commands Trendmeter_redis_total_commands_rate命令总量的趋势redis-exporterDB keysmeter_redis_evicted_keys_totalmeter_redis_expired_keys_totalmeter_redis_db_keys过期 / 驱逐 / 总计的键数量redis-exporterNet Input/Output BytesKBmeter_redis_net_input_bytesmeter_redis_net_output_bytesRedis 网络输入 / 输出总字节数redis-exporterMemory Usage%meter_redis_memory_used_bytesmeter_redis_memory_max_bytes已用内存百分比redis-exporterTotal Time Spend By Command Trendmeter_redis_commands_durationmeter_redis_commands_total命令总耗时的趋势redis-exporter需要说明的是服务级指标实际上是聚合了集群内所有实例的结果例如uptime使用.max(...)取最大值、connected_clients使用.sum(...)求和、hit_rate则按sum语义聚合命中与未命中后再计算比例具体实现以 redis-service.yaml 为准。文档表中列出的若干指标名如meter_redis_average_time_spent_by_command与规则文件中定义的服务级规则存在细节差异实际可用指标建议以规则文件metricsRules中声明的name为准例如实例级指标实际命名为meter_redis_instance_average_time_spent_by_command。UI 仪表盘Redis 的监控面板配置位于 ui-initialized-templates/redisredis-service.jsonRedis 服务级仪表盘包含 Uptime、Connected Clients、Memory Usage、Total Commands Trend、Hits Rate 等卡片与趋势图redis-instance.jsonRedis 实例级仪表盘展示单实例的 Uptime (day)、Connected Clients、Blocked Clients、Memory Max Bytes (MB)、Memory Usage (%)、Total Commands Trend、Hits Rate (%)、Net Input/Output Bytes (KB)、DB Keys、Total Time Spent by Command Trend (sec)、Average Time Spent by Command / sec 等面板。面板中的每个组件通过expressions字段直接引用meter_redis_*指标例如expressions: [ latest(meter_redis_instance_uptime)/3600/24 ]表示将 uptime 秒数换算为天数而expressions: [ meter_redis_instance_memory_usage ]直接展示实例内存使用率百分比。你可以仿照这些表达式结构编写自己的查询面板。自定义指标与面板你可以完全自定义自己的指标、表达式与仪表盘面板指标定义与 MAL 表达式规则位于oap-server/server-starter/src/main/resources/otel-rules/redis/目录即 redis-instance.yaml 与 redis-service.yamlRedis 仪表盘面板配置位于oap-server/server-starter/src/main/resources/ui-initialized-templates/redis/目录。指标链路验证e2e 测试参考仓库的 e2e 测试 redis-cases.yaml 演示了如何用swctl验证整条链路是否打通。以服务级指标为例swctl --display yaml --base-urlhttp://${oap_host}:${oap_12800}/graphql metrics exec \ --expressionlatest(aggregate_labels(meter_redis_uptime,max)) \ --service-nameredis::root[root]实例级指标则额外指定实例名即 redis-exporter 的地址swctl --display yaml --base-urlhttp://${oap_host}:${oap_12800}/graphql metrics exec \ --expressionmeter_redis_instance_uptime \ --service-nameredis::root[root] --instance-nameredis_exporter_1:9121对应的预期结果文件位于 expected 目录service.yml断言服务redis::root[root]的layers包含REDIS、group为redismetrics-single-value.yml、metrics-has-value.yml断言各指标有值返回。注意测试中服务名redis::root[root]的来源Collector 抓取配置中给 target 打的host_name: root[root]标签经 MALexpSuffix改写为redis::root[root]因此实际接入时服务名取决于你为 target 配置的host_name标签。第二部分慢命令监控Collect sampled slow commands采集原理与数据流SkyWalking 借助 fluent-bit 或其他日志采集 Agent 收集 Redis 的慢命令数据流如下周期性执行 slowlog.sh 脚本把 Redis 中的 slowlog 取回并保存到本地文件fluent-bit Agent 从本地文件采集慢日志fluent-bit 通过 HTTP 调用 SkyWalking 的原生日志 API 把数据发送到 OAP Servere2e 配置中为POST http://oap:12800/v3/logsOAP Server 使用 LAL 解析表达式提取字段并存储为 TopN 记录。设置步骤部署 fluent-bit参考 fluent-bit.conf 配置 fluent-bit 的输入、过滤与输出[INPUT]使用tail插件监听/scripts/slowlog.log文件并应用my-log-format正则解析器[FILTER]调用 fluent-bit-script.lua 中的rewrite_body函数将慢日志文本重写为包含layer、service、query_time、statement、id等字段的 JSON[OUTPUT]通过http插件将 JSON 发送到 OAP 的/v3/logs接口。[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 http match * host oap port 12800 uri /v3/logs format json对应的正则解析器定义在 fluent-bit-parser.conf[PARSER] name my-log-format format regex regex ^\S\s\S\s\S\s([\S\s])\s\S:\S$参考 redis.conf 为 Redis 配置慢日志相关参数周期性执行 slowlog.sh 脚本采集慢日志。慢日志采集脚本解析采集脚本 slowlog.sh 的核心逻辑len$(/usr/local/bin/redis-cli -h redis_1 slowlog len) # 查询当前 slowlog 条数 if [[ $len -gt 0 ]]; then result$(/usr/local/bin/redis-cli -h redis_1 slowlog get $len) # 取出全部慢日志 single_line_log$(echo $result | tr \n ) # 转成单行 # 按 x.x.x.x:port 模式切分还原成逐条日志并追加写入文件 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 # 取走后 reset避免重复采集在 e2e 测试中脚本由 cron 每 1 分钟调度一次执行cron 配置见 crontable.txt内容为* * * * * /scripts/slowlog.sh调度进程由 start.sh 初始化安装 cron、写入 crontab 并启动 cron 服务。这也是官方推荐思路的参考实现你完全可以不用 cron fluent-bit而采用其他方式周期性获取慢日志并发送给 OAP。慢日志配置项说明关于 Redis 慢日志的两个关键配置项见 redis.confslowlog-log-slower-than执行时间超过该值单位毫秒的命令会被记录到 slowlog。e2e 示例中设为1000即超过 1ms 的命令slowlog-max-lenslowlog 中最多保存的慢日志条数。e2e 示例中设为1200。NoticeSlow Log 中记录的是命令执行耗时而不是网络往返时间也不包含 I/O 等待慢日志默认保存在内存中Redis 重启后会丢失因此「周期性取走并落盘」是必要的。慢命令的数据模型与指标慢 SQL 监控提供 Redis 服务器慢命令的监控能力Redis 服务器被登记为 OAP 中Layer: REDIS的Service。监控面板单位指标名说明数据来源Slow Statementsmstop_n_database_statementRedis 慢命令的延迟与语句内容fluentbitLAL 解析规则慢命令日志的解析规则位于 lal/redis-slowsql.yamlrules: - name: redis-slowsql layer: REDIS 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) { slowSql { id parsed.id as String statement parsed.statement as String latency parsed.query_time as Long } } } }该规则通过json{}解析 fluent-bit Lua 脚本构造的 JSON 体提取layer、service、time字段并在LOG_KIND SLOW_SQL时把id、statement、query_time映射为slowSql记录对应 TopN 面板中的top_n_database_statement。其中LOG_KIND标签正是由 fluent-bit-script.lua 写入的record.tags { data { { key LOG_KIND, value SLOW_SQL } } } inner_record.time os.time() * 1000 inner_record.layer REDIS record.service redis:: .. root[root] inner_record.query_time qt -- 从 slowlog 文本第 3 列解析出的执行耗时 inner_record.statement ... -- 拼接第 4 列起的命令语句 inner_record.id splitResult[1] -- slowlog 唯一 IDLua 脚本中对原始慢日志文本的解析示例一条典型 Redis slowlog 形如102 1684379526 2691 flushall 192.168.150.29:42904其中第 1 列为日志 ID、第 2 列为 Unix 时间戳、第 3 列为执行耗时微秒、第 4 列起为命令及其参数、末尾为客户端地址端口。脚本把耗时换算为毫秒写入query_time把命令语句拼接到statement。慢命令链路验证e2e 测试通过以下查询验证慢命令 TopN 记录是否入库见 redis-cases.yamlswctl --display yaml --base-urlhttp://${oap_host}:${oap_12800}/graphql records list \ --nametop_n_database_statement --service-nameredis::root[root]预期结果 db-has-value.yml 断言 TopN 记录包含name与value字段notEmpty证明慢命令已被成功解析并写入 OAP。自定义你可以自定义自己的慢命令指标、表达式与仪表盘面板慢 SQL 解析规则位于oap-server/server-starter/src/main/resources/lal/redis-slowsql.yaml即 redis-slowsql.yamlRedis 仪表盘面板配置位于oap-server/server-starter/src/main/resources/ui-initialized-templates/redis/目录服务级 redis-service.json、实例级 redis-instance.json。常见问题与排查建议指标不出数优先核对 Collector 的job_name是否与 MAL 规则中的filterredis-monitoring一致再确认 redis-exporter 的REDIS_ADDR指向正确、9121端口可访问最后检查 OAP 的 OpenTelemetry receiver 是否启用、oap:11800gRPC 端口是否可达。服务/实例不出现expSuffix依赖抓取配置中的host_name标签若未打该标签则无法正确登记 Service 与 Instance服务名会以redis::前缀呈现例如redis::root[root]。慢命令不展示检查 cron 是否在调度slowlog.she2e 中每分钟一次、slowlog.log是否持续写入fluent-bit 的path是否指向该文件、Lua filter 是否执行成功最后确认 LAL 规则redis-slowsql已生效且LOG_KIND SLOW_SQL标签正确写入。单位换算面板表达式中的换算逻辑如 uptime 秒转天、字节转 MB/KB、耗时转毫秒都在 UI 模板与 Lua 脚本中完成改动指标时注意保持单位一致。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐SkyWalking Kafka 监控接入指南基于 Prometheus JMX Exporter 与 OpenTelemetry Collector 的指标采集与 MAL 分析SkyWalking Kafka 监控接入指南基于 Prometheus JMX Exporter 与 OpenTelemetry Collector 的指标可观测性APM链路追踪指标监控日志分析微服务Apache SkyWalking RocketMQ 监控接入指南基于 rocketmq-exporter 与 OpenTelemetry 的指标采集与 MAL 聚合Apache SkyWalking RocketMQ 监控接入指南基于 rocketmq exporter 与 OpenTelemetry 的指标采集与 MA可观测性后端微服务云原生SkyWalking 监控 PostgreSQL基于 postgres-exporter 与 OpenTelemetry 的指标采集及慢 SQL 采集方案SkyWalking 监控 PostgreSQL基于 postgres exporter 与 OpenTelemetry 的指标采集及慢 SQL 采集方案 导可观测性APM链路追踪指标监控日志分析微服务上一篇ai53_19/garbage_datasets数据集详解下一篇RevokeMsgPatcher 安装指南微信/QQ/TIM 防撤回补丁装完后撤回的消息还能看吗创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考