适合开发者排查应用故障的Kibana仪表盘可选面板有哪些

一、K8s资源维度补充面板 #

• Pod 重启次数&OOM事件统计：直接关联OOM kill场景，可按时间粒度聚合，搭配Pod名称筛选，1小时内重启超过2次直接标记为异常，不用翻日志就能第一时间定位服务宕机根因是否为内存溢出
• Pod CPU Throttling（CPU限流）统计：很多时候CPU使用率看起来不高但应用卡顿，是因为容器被K8s限流了，这个面板能直接区分是应用本身计算负载高，还是资源配额给的不够
• 宿主机基础监控：节点CPU/内存/磁盘使用率、磁盘inode使用率，很多Pod异常是底层节点资源耗尽导致的，单独列面板能快速排除基础设施层问题
• PV/PVC使用率：有状态应用存储占满会直接导致服务写失败，这个面板对应存储相关故障场景

二、应用运行时维度面板 #

• JVM/Go Runtime等语言专属指标：如果是Java应用加堆内存/GC次数/GC耗时面板，Go应用加协程数量/堆内存分配面板，高CPU、请求耗时过长很多时候是频繁GC导致的，不用登容器就能看运行时状态
• 线程池/连接池指标：数据库连接池、HTTP线程池的活跃连接数、等待队列长度，连接池耗尽会直接导致请求堆积超时，是应用卡顿的常见隐性原因
• 缓存命中率统计：直接对应缓存问题导致的请求耗时过长场景，命中率低于60%直接标记告警，不用查日志就能判断是不是缓存击穿/穿透/失效导致的数据库压力突增

三、服务请求维度面板 #

• 请求黄金三指标面板：按接口维度聚合的QPS、错误率（HTTP 5xx/4xx占比、业务错误码占比）、请求耗时分位值（P50/P95/P99），这三个指标能第一时间告诉开发者服务是不是出问题了，出问题的范围有多大
• 上下游依赖耗时统计：数据库查询耗时、第三方接口调用耗时、MQ消息生产消费耗时，很多请求慢不是自身应用的问题，是依赖的下游服务故障导致的，这个面板能快速缩小排查范围
• MQ堆积量&消费失败次数：用到消息队列的服务，这个面板能直接对应消息堆积导致的业务延迟、消费失败导致的数据不一致问题

四、异常事件维度面板 #

• 错误日志聚合统计：不是单纯放原始日志，是按错误等级（ERROR/FATAL）、异常类型聚合的计数面板，还可以加Top N高频错误排行，开发者不用翻海量日志就能先看到最频繁的报错类型
• K8s事件面板：聚合K8s集群的Warning级事件，比如调度失败、镜像拉取失败、健康检查失败这些，能快速定位服务启动失败、频繁重启的集群层原因

额外需要纳入的监控维度 #

你提到的三个典型场景已经覆盖了大部分故障，还有两个容易遗漏的维度：

1. 配置变更维度：可以把最近的配置发布、镜像版本变更记录集成到面板做时间轴对照，80%的线上异常都和最近的变更有关，故障发生后先看最近有没有变更，排查效率能提升很多
2. 业务指标维度：比如支付成功率、订单创建量这类和业务强相关的指标，很多时候技术指标看起来正常，但业务已经出问题了，加入业务指标能第一时间感知到影响用户的故障

内容的提问来源于stack exchange，提问作者sidharth vijayakumar