如何用Elastic來診斷下redis slowlog

# 如何用Elastic來診斷Redis Slowlog

## 前言

Redis的`slowlog`是排查性能問題的關鍵工具，但當集群規模擴大時，手動分析日志會變得低效。結合Elastic Stack（ELK）的日志收集、存儲和可視化能力，可以構建高效的慢查詢分析平臺。本文將詳細介紹如何實現這一過程。

---

## 一、Redis Slowlog基礎

### 1.1 什么是Slowlog
Redis Slowlog記錄執行時間超過閾值的命令，包含以下關鍵信息：
- **唯一ID**：自增的日志標識符
- **時間戳**：命令執行完成的時間
- **執行時長**：微秒級精度
- **命令詳情**：包含參數（默認不記錄敏感參數）

### 1.2 配置參數
```redis
# 配置文件示例
slowlog-log-slower-than 10000  # 閾值10ms（單位：微秒）
slowlog-max-len 128           # 最大記錄條數

二、數據采集方案設計

2.1 整體架構

Redis實例 → Filebeat → Logstash → Elasticsearch → Kibana

2.2 日志格式示例

{
  "timestamp": 1620000000,
  "duration": 15000,
  "command": "GET user:12345:profile",
  "client_ip": "10.0.0.1",
  "client_name": "cart-service"
}

三、具體實現步驟

3.1 配置Redis輸出Slowlog

# 動態修改配置（無需重啟）
redis-cli config set slowlog-log-slower-than 5000
redis-cli config set slowlog-max-len 500
redis-cli slowlog reset  # 可選：清除歷史記錄

3.2 Filebeat配置

filebeat.inputs:
- type: log
  paths:
    - /var/log/redis/redis-slow.log
  json.keys_under_root: true
  json.add_error_key: true

output.logstash:
  hosts: ["logstash:5044"]

3.3 Logstash處理管道

input {
  beats { port => 5044 }
}

filter {
  grok {
    match => { "message" => "\[%{INT:id}\] %{INT:timestamp} %{INT:duration} %{GREEDYDATA:command}" }
  }
  date {
    match => ["timestamp", "UNIX"]
    target => "@timestamp"
  }
  mutate {
    convert => { "duration" => "integer" }
  }
}

output {
  elasticsearch {
    hosts => ["http://es:9200"]
    index => "redis-slowlog-%{+YYYY.MM.dd}"
  }
}

四、Elasticsearch優化策略

4.1 索引模板

PUT _template/redis-slowlog
{
  "index_patterns": ["redis-slowlog-*"],
  "settings": {
    "number_of_shards": 2,
    "analysis": {
      "analyzer": {
        "command_analyzer": {
          "type": "custom",
          "tokenizer": "pattern",
          "filter": ["lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "duration": { "type": "long" },
      "command": { 
        "type": "text",
        "analyzer": "command_analyzer",
        "fields": { "keyword": { "type": "keyword" } }
      }
    }
  }
}

4.2 典型查詢示例

// 查詢TOP10慢命令
GET redis-slowlog-*/_search
{
  "size": 0,
  "aggs": {
    "slow_commands": {
      "terms": { "field": "command.keyword", "size": 10 },
      "aggs": { "avg_duration": { "avg": { "field": "duration" } } }
    }
  }
}

五、Kibana可視化方案

5.1 關鍵儀表板組件

1. 慢查詢趨勢圖：按時間分布的請求量
2. 命令耗時熱力圖：command與duration的二維分析
3. 客戶端排名：按client_ip統計的慢查詢占比

5.2 告警規則配置

PUT _watcher/watch/slowlog_alert
{
  "trigger": { "schedule": { "interval": "5m" } },
  "input": {
    "search": {
      "request": {
        "indices": ["redis-slowlog-*"],
        "body": {
          "query": { "range": { "duration": { "gte": 100000 } } }
        }
      }
    }
  },
  "condition": { "compare": { "ctx.payload.hits.total.value": { "gt": 0 } } },
  "actions": { "send_email": { ... } }
}

六、實戰案例分析

6.1 高頻大Key問題

通過聚合分析發現HGETALL large:hash頻繁出現，結合memory usage命令確認后，改用HSCAN分批獲取。

6.2 不合理批量操作

發現大量PIPELINE中的MGET超過100個key，優化為分批執行并添加本地緩存。

6.3 熱點Key問題

某INCR counter:20230801命令持續出現在日志中，采用分片計數器counter:20230801:{1..10}分散壓力。

結語

通過Elastic Stack實現的慢查詢分析平臺，運維團隊可以實現： - 實時監控慢查詢發生率 - 快速定位問題模式 - 量化優化效果（優化前后耗時對比）

建議每月生成《Redis慢查詢分析報告》，持續跟蹤系統健康度。完整配置示例可參考GitHub倉庫：示例項目鏈接 “`

注：實際部署時需根據具體環境調整參數，生產環境建議添加TLS加密和訪問控制。