Redis集群日志配置需按节点类型（普通节点、Sentinel、Cluster Manager）区分，临时生效用CONFIG SET loglevel（仅当前进程），永久生效须逐个修改各节点redis.conf并配logfile；Sentinel需用SENTINEL loglevel单独设置；debug级不记录命令，采样应靠slowlog和monitor。
Redis集群的日志级别不能靠单点配置一劳永逸，必须区分节点类型（普通节点、Sentinel、Cluster Manager）和生效方式（临时 vs 永久），否则改了也看不到日志，或日志爆炸拖垮性能。
CONFIG SET loglevel 只对当前节点临时生效
在任意 Redis 节点的 CLI 中执行 CONFIG SET loglevel verbose 确实能立刻提升日志详细度，但仅限该进程生命周期——重启后还原为配置文件里的值。生产环境排查瞬时故障时可用，比如刚收到报警就快速切 verbose 看连接/命令流；但别指望它“一设永逸”。
- 必须逐个登录每个 master/slave 节点执行，Cluster 中节点多时容易漏掉
-
CONFIG SET不影响 Sentinel 进程或 redis-cli 连接本身的日志，只管 Redis server 实例 - 若节点启用了 AOF 或 RDB 持久化，
CONFIG SET不会写入配置文件，重启即丢
redis.conf 里改 loglevel 才算永久生效
集群中每个节点（包括每个 shard 的 master/slave、每个 Sentinel 实例）都必须独立修改自己的 redis.conf，因为 Redis 没有“集群级统一日志配置”机制。常见错误是只改了一个节点的配置，结果其他节点日志还是 notice，关键报错根本没记录。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认路径：每个节点的
redis.conf位置可能不同，尤其用 systemd 启动时，检查systemctl cat redis@7001查实际加载路径 - 必须同时配
logfile，否则即使loglevel verbose生效，日志仍输出到 stdout —— 容器或 systemd 下会被截断或丢失 - 推荐组合：
loglevel notice（默认）+slowlog-log-slower-than 10000（记录 >10ms 命令），比盲目开 debug 更可控
Sentinel 节点要用 SENTINEL loglevel 单独调
Sentinel 是独立进程，不读取 Redis server 的 redis.conf，它的日志级别必须用 SENTINEL loglevel <master-name> <level> 命令设置，且只对指定 master 的监控上下文生效。直接在 Sentinel CLI 里跑 CONFIG SET loglevel 会报错。
- 例如：想让 Sentinel 对
mymaster输出更细的故障切换日志，执行SENTINEL loglevel mymaster verbose - 该命令不会改 Sentinel 自身进程的日志（如连接超时、哨兵间通信），那些仍由 Sentinel 的
redis.conf控制 - 没有 “全部 master 统一设 level” 的批量语法，master 多时得循环调用
日志采样不是靠 loglevel，而是靠 slowlog 和 monitor 配合
很多人误以为把 loglevel 设成 debug 就能“采样”请求，其实不是。Redis 的 debug 级别主要打内部状态（内存分配、事件循环），不记录客户端命令。真要采样请求，得用：
-
SLOWLOG GET 10查最近 10 条慢查询（需先设slowlog-log-slower-than） -
MONITOR实时看所有命令（仅调试用，性能杀伤极大，禁止在生产长期开） - 结合
CLIENT LIST+CLIENT INFO定位异常连接，再配合loglevel verbose看其连接/断连上下文
真正容易被忽略的是：loglevel 改高后，日志 I/O 会抢磁盘带宽，尤其在 SSD 寿命敏感或日志盘与数据盘共用时，verbose 级别持续跑一周可能让磁盘延迟翻倍。别只盯着“能不能看到日志”，先看“日志会不会变成新故障源”。
