告警主题故障处理
提示
本文介绍关于 k3s/k8s 常见告警主题处理及解决方案。
本文目录
处理流程
告警列表及优先级说明
ONES对告警进行优先级划分使用的是priority， 优先级从高到低为P0、P1、P2、P3、P4
- P0 要立刻处理的严重告警，可能已经发生了严重的集群整体不可用的问题
- P1 要立刻处理的严重告警，可能已经发生了严重的关键业务不可用的问题
- P2 可以延后处理（8-24小时）的告警，可能已经发生了非关键业务不可用的问题，或长期下去，可能会升级为P1的问题
- P3 可以延后处理（1-7天）的告警，可能已经发生了轻微的业务问题
- P4 信息级别的告警，无需处理，一般仅来让大家知道告警信息的接收没有问题，如果长期没有接受到P4的信息，就需要去处理下告警发送的问题
对于不同的告警应该设置不同的告警间隔时间（频率）,建议如下
- P0: 10分钟
- P1: 30分钟
- P2: 2小时
- p3: 12小时
- p4: 12小时
注意：
- 下列告警列表，部分告警内容是有阈值的。
- 没有明确列出阈值的，则不存在阈值, 或者无需关心阈值。
- 告警里面也会有一些建议延后处理的时间点，虽然跟P0-P4的标准延后处理时间有差异。 但按标准的P0-P4的标准来处理也不会有大问题。
告警列表
1. KubeStateMetricsListErrors
优先级: P0
描述：
kube-state-metrics is experiencing errors at an elevated rate in list operations. This is likely causing it to not be able to expose metrics about Kubernetes objects correctly or at all.
kube-state-metrics 在list操作中遇到错误的频率很高。这很可能导致它无法正确或根本无法公开有关 Kubernetes 对象的指标。
原因：
- kubernetes集群出现内部问题， 一般是比较复杂的原因。
- 可能是etcd负载过高、etcd所在节点出现了某些问题、 kube-apiserver 负载过高等。
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 可能会因为kubernetes内部问题，进而引起长时间业务故障。
解决方法：
- 立刻处理
- 联系ONES技术支持分析， 排除问题的思路：
- 列出关键信息 kubectl get nodes, kubectl -n kube-system get pods -o wide, kubectl -n monitoring get pods -o wide，
- 根据情况，分析pod log 及 kubectl describe 分析状态， 必要情况下，需要进一步分析kubelet。
- 如果是负载过高引起的，使用top nmon 等近实时监控工具，分析高负载的原因，再视具体情况谨慎处理。
2. KubeStateMetricsWatchErrors
优先级: P0
描述：
- kube-state-metrics is experiencing errors at an elevated rate in watch operations. This is likely causing it to not be able to expose metrics about Kubernetes objects correctly or at all.
- kube-state-metrics 在 watch 操作中遇到错误的频率很高。这很可能导致它无法正确或根本无法公开有关 Kubernetes 对象的指标。
能否自愈：
- 一般情况下不能，需要人工介入
原因
3. NodeFilesystemSpaceFillingUp
优先级:
- P0: 4小时内耗尽
- P0: 24小时内耗尽
描述：
Filesystem on {{"{{"}} $labels.device {{"}}"}} at {{"{{"}} $labels.instance {{"}}"}} has only {{"{{"}} printf "%.2f" $value {{"}}"}}% available space left and is filling up.
Filesystem is predicted to run out of space within the next 24 hours. （按磁盘消耗的速度，24小时内耗尽）
Filesystem is predicted to run out of space within the next 4 hours. (按磁盘消耗的速度，4小时内耗尽)
节点剩余空间不足，即将耗尽。
原因：
- 可能是前期存在资源规划问题，过度压缩了磁盘大，导致资源不足。
- 可能是业务bug，对于临时文件使用后，没有及时回收或清理。
- 可能是 当前配置 不能够满足 业务数据的增长。
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 一旦耗尽，引起的长时间的存储相关业务不可用。
解决方法：
- 根据磁盘剩余空间大小，再决定是马上介入处理 还是 延后到业务低峰期处理（4-24小时内）。
- 磁盘扩容或清理临时文件，扩容时， 可以逐个节点进行扩展。（可以reboot的情况下，不要强制关机）
- 如果是业务临时文件引起的， 反馈到ONES技术支持（必须在技术支持的指引下，谨慎清理临时文件，需慎重，做好备份）
4. NodeFilesystemAlmostOutOfSpace
优先级:
- P0: 剩余空间不足5%
- P1: 剩余空间不足15%
描述:
- Filesystem has less than {{ $config.alertThresholdP1NodeFilesystemOutOfSpace }}% space left.
- Filesystem has less than {{ $config.alertThresholdP0NodeFilesystemOutOfSpace }}% space left.
- 文件系统空间余量小于设置的阈值了
能否自愈：
- 一般情况下不能，需要人工介入
原因
5. NodeNetworkReceiveErrs
优先级: P3
描述：
- '{{"{{"}} $labels.instance {{"}}"}} interface {{"{{"}} $labels.device {{"}}"}} has encountered {{"{{"}} printf "%.0f" $value {{"}}"}} receive errors in the last two minutes.'
- 网卡设备 2分钟内产生了较多的 receive 错误
原因：
- 某节点网卡、或网络故障、交换器故障、waf拦截。
影响：
- 服务不可用持续约2分钟，2分钟后一般情况下能自愈（这两份钟是由k8s自身默认机制决定的）。
解决方法：
- 检查网卡状态、排查内网网络问题、waf问题
缓解手段：
- 下线故障节点（init 0, 尽量不要直接关机）
响应时机：
如果业务还能够使用， 可以延后到业务低峰期处理（12小时内）。
6. NodeNetworkTransmitErrs
- 优先级: P3
描述：
'{{"{{"}} $labels.instance {{"}}"}} interface {{"{{"}} $labels.device {{"}}"}} has encountered {{"{{"}} printf "%.0f" $value {{"}}"}} transmit errors in the last two minutes.
网卡设备 2分钟内产生了较多的 transmit 错误
原因、影响、解决方发、响应时机， 同上 5. NodeNetworkReceiveErrs
7. KubePodCrashLooping
优先级:
- P1：正常情况下都为P1， 特例服务不出现在p1中（比如libreffice）
- P3: 特例，比如第三方工具libreffice等，偶尔会发生自身故障导致重启的，到重启次数超过3时，为P3
描述：
- Pod {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.pod {{"}}"}} ({{"{{"}} $labels.container {{"}}"}}) is restarting {{"{{"}} printf "%.2f" $value {{"}}"}} times / 5 minutes.
- Pod实例重启了
原因：
- 进程异常退出
- OOM
- 业务bug（访问空指针且没有捕获异常）
- 资源上限配置过低了
能否自愈：
- 一般情况下能自愈
- 特殊情况下，如果5分钟内连续重启超过5次，会引发5分钟-10分钟的服务故障，这时需要人工介入处理。
- 边缘服务可以延后（4-8小时）处理。
- 关键服务需要马上处理。
影响：
- 如果是关键服务，会引发服务抖动、短时间卡顿问题。
- 如果是边缘服务，会导致一些异步或非关键功能异常，比如 performance、审计日志、搜索的实时性产生影响。
解决方法：
- 关键服务立刻处理
- 边缘服务延后（1-4小时处理）
- 如果确定某类 pod 重启告警需要做降级或屏蔽，需要联系ONES进行评估，再确定处理方案。
8. KubePodNotReady
优先级: P1
描述：
- Pod {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.pod {{"}}"}} has been in a non-ready state for longer than 15 minutes.
- Pod 长时间non-ready
原因：
- 节点调度出现问题
- 集群资源不足
- 业务升级出现了问题
- 存储出现问题
- kubelet故障
- docker bug
- linux内核故障
- 网络故障
- 部署工具编排bug
能否自愈：
- 不能自愈，需要人工介入
影响：
- 可能业务升级出现问题
- 有潜在导致服务不可用的风险。
解决方法：
- 立刻处理
- 排查思路:
- kubectl -n xxx get pods -o wide
- kubectl -n xxx describe pod xxx
- kubectl -n xxx get node
- kubectl -n xxx describe node xxx
- ping xxx
- journalctl -f
- 处理方法:
- 具体问题具体分析，需要谨慎操作。
- 需要重启对应节点，才能重新加入集群(重启过程由于kubernetes自身组件问题，服务影响在1-2分钟)
- 检查内网网络问题
- 查看内核日志等
9. KubeDeploymentGenerationMismatch
优先级: P2
描述：
- Deployment generation for {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.deployment {{"}}"}} does not match, this indicates that the Deployment has failed but has not been rolled back.
原因：
- kubernetes集群出现问题，导致deployment 无法完成正常的滚动更新调度问题
- 也可能是部署工具编排 Deployment 的bug。
- 集群资源不足
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 可能会因为kubernetes内部问题，进而引起长时间业务故障。
解决方法：
- 延后处理
- 排查思路:
- kubectl get nodes
- kubectl -n kube-system get pods
- kubectl -n xxx get deployment
- kubectl -n xxx describe deployment xxx
- kubectl -n xxx get pods
- kubectl -n xxx describe pod xxxx
- 处理方法:
- 联系ONES进行处理。
10. KubeStatefulSetReplicasMismatch
优先级: P2
描述：
- StatefulSet {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.statefulset {{"}}"}} has not matched the expected number of replicas for longer than 15 minutes.
原因：
- 同上： 10. KubeDeploymentGenerationMismatch
- 差异：
- kubectl -n xxx get statefulset
- kubectl -n xxx describe statefulset xxx
11. KubeStatefulSetGenerationMismatch
优先级: P1
描述：
- StatefulSet generation for {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.statefulset {{"}}"}} does not match, this indicates that the StatefulSet has failed but has not been rolled back.
原因：
- 同上： 10. KubeDeploymentGenerationMismatch
- 差异：
- 需要立即处理，因为有状态应用的影响程度比无状态应用要高
- kubectl -n xxx get statefulset
- kubectl -n xxx describe statefulset xxx
12. KubeStatefulSetUpdateNotRolledOut
优先级: P1
描述：
- StatefulSet {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.statefulset {{"}}"}} update has not been rolled out.
原因：
- 同上： 10. KubeDeploymentGenerationMismatch
- 差异：
- 需要立即处理，因为有状态应用的影响程度比无状态应用要高
- kubectl -n xxx get statefulset
- kubectl -n xxx describe statefulset xxx
13. KubeDaemonSetRolloutStuck
优先级: P1
描述：
- Only {{"{{"}} $value | humanizePercentage {{"}}"}} of the desired Pods of DaemonSet {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.daemonset {{"}}"}} are scheduled and ready.
原因：
- 同上： 10. KubeDeploymentGenerationMismatch
- 差异：
- 需要立即处理，因为daemonset的影响程度比无状态应用要高，并且很多情况下是影响所有节点的
- kubectl -n xxx get daemonset
- kubectl -n xxx describe daemonset xxx
14. KubeContainerWaiting
优先级: P3
描述：
- Pod {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.pod {{"}}"}} container {{"{{"}} $labels.container{{"}}"}} has been in waiting state for longer than 1 hour.
原因：
- 部署问题
- 在等待依赖的中间件、或服务，且对应的中间件或服务长时间没有准备好
- 集群资源不足，导致依赖的中间件、或服务， 间接引发该告警
- 镜像仓库虽然能正常连接，但是拉取镜像的速度过慢，可能限速过于严重。
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 业务可能无法正常更新版本或配置
解决方法：
- 延后处理（2-8小时）
- 排查思路:
- kubectl -n xxx describe pods xxx
- kubectl -n xxx get pods xxx -o yaml ， 观察是哪个container 卡住
- 处理方法:
- 具体问题，具体分析，解决卡住初始化的问题
15. KubeDaemonSetNotScheduled
优先级: P3
描述：
- {{"{{"}} $value {{"}}"}} Pods of DaemonSet {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.daemonset {{"}}"}} are not scheduled.'
原因：
- 集群调度出现问题
- 可能是集群资源问题
- 可能是docker bug
- 可能是网络故障
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 可能会因为kubernetes内部问题，进而引起长时间业务故障。
解决方法：
- 如果业务还能正常访问，则可延后处理，否则立刻处理
- 排查思路:
- kubectl get nodes
- kubectl -n kube-system get pods
- kubectl -n xxx get daemonset
- kubectl -n xxx describe daemonset xxx
- kubectl -n xxx get pods
- kubectl -n xxx describe pod xxxx
- 处理方法:
- 联系ONES进行处理。
16. KubeCronJobRunning
优先级: P1
描述：
- CronJob {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.cronjob {{"}}"}} is taking more than 1h to complete.
原因：
- MySQL数据迁移时间过长、迁移失败、迁移卡住、死锁
- 某些定时任务执行时间过长
- 业务编排问题
能否自愈：
- 一般情况下能够自愈
影响：
- 可能会导致 ONES 业务版本更新时数据迁移失败
- 可能会引发集群资源问题，需要随时留意集群的情况，避免发生服务不可用的问题。
解决方法：
- 可以延后处理 （2-8小时）
- 耐心等待，但是要注意观察集群的情况或留意新的告警。
17. KubeJobCompletion
优先级: P1
描述：
- CronJob {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.cronjob {{"}}"}} is taking more than 1h to complete.
原因：
18. KubeJobFailed
优先级: P2
描述：
- Job {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.job_name {{"}}"}} failed to complete.
原因：
- 同上 17. KubeCronJobRunning
- 差异：
- 可以延后处理 （2-8小时）
- 如果是数据迁移导致的，建议立即处理
19. KubeCPUOvercommit
优先级: P1(无法分配更多的cpu给新调度的实例了)
描述：
- Cluster has overcommitted CPU resource requests for Pods and cannot tolerate node failure.
原因：
- 集群资源不足
- Pod的资源限制设置过高，无法调度到节点上
能否自愈：
- 一般情况下不能资源，需要人工干预
解决方法：
- 立即处理
- 增加硬件资源或调整资源限制
20. KubeMemOvercommit
优先级: P1 (无法分配更多的内存给新调度的实例了)
描述：
- Cluster has overcommitted memory resource requests for Pods and cannot tolerate node failure.
原因：
- 集群资源不足
- Pod的资源限制设置过高，无法调度到节点上
能否自愈：
- 一般情况下不能自愈，需要人工干预
影响：
- 可能会导致服务不可用
解决方法：
- 立即处理
- 增加硬件资源或调整资源限制
21. KubeQuotaExceeded
优先级: P3 （某类 集群资源 的使用率超过 90% ）
描述：
- Namespace {{"{{"}} $labels.namespace {{"}}"}} is using {{"{{"}} $value |humanizePercentage {{"}}"}} of its {{"{{"}} $labels.resource {{"}}"}} quota.
原因：
- 集群资源（cpu、内存）不足
- 存储资源不足
能否自愈：
- 一般情况下不能自愈，需要人工干预
影响：
- 可能会导致服务不可用
解决方法：
- 立即处理
- 增加硬件资源或调整资源限制
22. CPUThrottlingHigh
优先级:
- P1: Pod cpu使用率超过上限的50%了 （一般情况下系统仍能够使用，但是可能某些服务会卡顿）
- P4: Pod cpu使用率超过上限的25%了（预警）
描述：
- '{{"{{"}} $value | humanizePercentage {{"}}"}} throttling of CPU in namespace {{"{{"}} $labels.namespace {{"}}"}} for container {{"{{"}} $labels.container {{"}}"}} in pod {{"{{"}} $labels.pod {{"}}"}}.
- 某些pod的cpu超过警戒线。
原因：
- 集群资源（cpu、内存）不足
- 节点负载过高
- pod的cpu设置过低
能否自愈：
- 视情况而定，一般能自愈
- 如果出现业务访问故障了，需要人工干预
影响：
- 可能会导致服务不可用
- 可能对业务完全无影响
解决方法：
- 如果业务有问题了，立即处理
- 如果业务还能正常使用， 可以延后处理（2-8h）
- 增加硬件资源或调整资源限制
23. KubePersistentVolumeUsageCritical
优先级:
- P0: 某个数据卷的剩余容量低于3%了
描述:
- The PersistentVolume claimed by {{"{{"}} $labels.persistentvolumeclaim {{"}}"}} in Namespace {{"{{"}} $labels.namespace {{"}}"}} is only {{"{{"}} $value | humanizePercentage {{"}}"}} free.
原因：
- 卷存储服务出现问题
- 网络故障
- 超过2个实例的磁盘同时损坏
- 被误删节点的磁盘数据
- ceph bug
能否自愈：
- 视情况而定，大多数情况不能自愈
- 少数情况能够自愈（比如只是偶发的网络抖动）
影响：
- 可能会导致服务不可用
解决方法：
- 分析磁盘、网络、ceph问题
- 联系ONES进行处理
24. KubePersistentVolumeFullInFourDays
优先级: P1 按趋势，某个数据卷4天内耗尽
描述:
- Based on recent sampling, the PersistentVolume claimed by {{"{{"}} $labels.persistentvolumeclaim {{"}}"}} in Namespace {{"{{"}} $labels.namespace {{"}}"}} is expected to fill up within four days. Currently {{"{{"}} $value | humanizePercentage {{"}}"}} is available.
- 磁盘快满了
原因：
- 数据卷快满了
能否自愈：
- 不能自愈
影响：
- 可能会导致服务不可用
解决方法：
- 视情况而定，可能需要立即处理，也可能可以延后处理
- 联系ONES，扩容
25. KubePersistentVolumeErrors
优先级: P1
描述
- The persistent volume {{"{{"}} $labels.persistentvolume {{"}}"}} has status {{"{{"}} $labels.phase {{"}}"}}.
原因：
- 卷存储服务出现问题
- 网络故障
- 超过2个实例的磁盘同时损坏
- 被误删节点的磁盘数据
- ceph bug
能否自愈：
- 视情况而定，大多数情况不能自愈
- 少数情况能够自愈（比如只是偶发的网络抖动）
影响：
- 可能会导致服务不可用
解决方法：
- 立即处理
- 分析磁盘、网络、ceph问题
- 联系ONES进行处理
26. KubeVersionMismatch
优先级: P4
描述： There are {{"{{"}} $value {{"}}"}} different semantic versions of Kubernetes components running.
原因:
- 不同版本的k8s节点放在了同一个集群内
能否自愈：
- 视情况而定，大多数情况不能自愈
影响：
- 不可以预知， 但是节点调度会受影响， 也会发生一些奇怪的问题。
解决方法：
- 立即处理
- 联系ONES进行处理
- kubectl get nodes (关注VERSION)
- kubectl describe nodes xxx
- kubectl cluster-info
27. KubeClientErrors
优先级: P4
描述: Kubernetes API server client '{{"{{"}} $labels.job {{"}}"}}/{{"{{"}} $labels.instance {{"}}"}}' is experiencing {{"{{"}} $value | humanizePercentage {{"}}"}} errors.'
原因:
- k8s集群内部出现问题
- api-server证书过期
- 客户端证书过期
能否自愈：
- 视情况而定，大多数情况不能自愈
影响：
- 不可以预知，只要不出现其他的连带问题，业务一般还能正常使用
解决方法：
- 业务有问题则，立即处理
- 业务能够正常访问，可以延后（2-8）小时处理
- 排查证书、集群资源状态、日志，对症下药。
28. ErrorBudgetBurn
优先级:
- P0: 滥用程度过高
- P1：滥用程度高
描述:
- budget burn
原因:
- k8s集群出现内部问题
- kube-apiserver 超载
- master节点资源不足
- 集群规模过大，api-server不堪重负，可能需要做联邦集群了
- kube-apiserver被恶意攻击
- 第三方operator bug，滥用kube-apiserver
能否自愈：
- 视情况而定，大多数情况不能自愈
影响：
- 不可以预知，只要不出现其他的连带问题，业务一般还能正常使用
解决方法：
- 业务有问题则，立即处理
- 业务能够正常访问，可以延后（2-8）小时处理
- 可能需要升级master节点配置。
- 排查攻击源
29. KubeAPILatencyHigh
优先级:
- P0: 延迟的99分位超过4秒
- P1：延迟的99分位超过1秒
描述:
- api延迟过高
原因： 同上 29. ErrorBudgetBurn
30. KubeAPIErrorsHigh
优先级:
- P1: 10%的接口错误率
- P2: 5%的接口错误率
- P4: 1%的接口错误率
描述:
- api报错过多
原因： 同上 29. ErrorBudgetBurn
31. KubeClientCertificateExpiration
优先级:
- P0：24小时内证书过期
- P2: 7天内证书过期
描述:
- A client certificate used to authenticate to the apiserver is expiring in less than 7.0 days.
原因:
- kubenetes 内部自签名证书快过期了
能否自愈：
- 不能自愈
影响：
- 业务短期内还能正常使用，集群无法执行新的调度， 如果发生新调度，必然引发服务不可用。
解决方法：
- 还在证书有效期内，则可以延后处理
- 如果已经超出证书有效期，需要马上处理
- 参考ONES整理的 k8s集群证书更新手册（make cat-k8s-cert 等）
32. KubeAPIDown
优先级: P4
描述:
- KubeAPI has disappeared from Prometheus target discovery.
原因:
- kubenetes 内部出现问题了
能否自愈：
- 不能自愈
影响：
- 业务短期内还能正常使用，集群无法执行新的调度， 如果发生新调度，必然引发服务不可用。
解决方法：
- 业务有问题则，立即处理
- 业务能够正常访问，可以延后（2-8）小时处理
- 排查api-server的状态
- kubectl -n kube-system get pods xxx
- kubectl -n kube-system describe pods xxx
33. KubeNodeNotReadydy
优先级: P1
描述：
- '{{"{{"}} $labels.node {{"}}"}} has been unready for more than 15 minutes.'
原因：
- 节点宕机
- 节点故障
- 节点负载过高，健康检查心跳失效
能否自愈：
- 大多数情况下不能自愈
影响：
- 如果触发 k8s 集群内部问题，会导致业务长时间不可用
- 如果没有触发 k8s集群内部问题，业务在1-2分钟内可恢复访问
解决方法：
- 立即处理
- 排查node的状态
- kubectl get node
- kubectl describe node xxx
- 可能需要重启节点
34. KubeNodeUnreachable
优先级: P1
描述：
- {{"{{"}} $labels.node {{"}}"}} is unreachable and some workloads may be rescheduled.
- Kubernetes 节点无法访问，部分工作负载可能会重新安排
原因：
- 节点故障
能否自愈：
- 大多数情况下不能自愈
影响：
- 如果触发 k8s 集群内部问题，会导致业务长时间不可用
- 如果没有触发 k8s集群内部问题，业务在1-2分钟内可恢复访问
解决方法：
- 立即处理
- 排查node的状态
- kubectl get node
- kubectl describe node xxx
- 可能需要重启节点
35. KubeletTooManyPods
优先级: P1
描述:
- Kubelet '{{"{{"}} $labels.node {{"}}"}}' is running at {{"{{"}} $value | humanizePercentage {{"}}"}} of its Pod capacity.
原因:
- 节点上运行了太多的pod，即将超过阈值了
能否自愈：
- 大多数情况下不能自愈
影响：
- pod的调度会出现问题， 业务虽然还能够正常访问，但是也有些危险了
- 不尽快处理，容易出现服务不可用
解决方法：
- 立即处理
- 排查node的状态
- kubectl get node
- kubectl describe node xxx
- 检查 kubelet 配置的 pod数量限制，根据实际情况来选择调整 pod数量上限，或给集群增加新的节点
36. KubeletDown
优先级: P1
描述：
- Kubelet has disappeared from Prometheus target discovery
原因：
- kubelet挂了
- 节点资源耗尽
- 节点负载过高
能否自愈：
- 大多数情况下不能自愈
影响：
- 这是极端情况了，大多数情况下业务无法正常访问了。
- 注意：不人工介入，业务可能无法自愈。
解决方法：
- 立即处理
- systemctl status kubelet
- 重启kubelet\重启节点\排查节点资源消耗情况
37. PrometheusBadConfig
优先级: P1
描述:
- Failed Prometheus configuration reload.
原因：
- prometheus的告警规则格式错误
能否自愈：
- 不能自愈
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法识别问题并发出告警，要留意了
解决方法：
- 立即处理
- 如果能够忍受 业务不可用的风险，可以延后处理。
38. PrometheusNotificationQueueRunningFull
优先级: P2
描述：
- Prometheus alert notification queue predicted to run full in less than 30m.
原因：
- 告警队列满了，可能发不出告警了
- 告警接受端出现问题了
- 网络出现问题
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法识别问题并发出告警，要留意了
解决方法：
- 立即处理、或延后处理
- 如果能够忍受 业务不可用的风险，可以延后处理。
39. PrometheusErrorSendingAlertsToSomeAlertmanagers
优先级: P4
描述：
- '{{"{{"}} printf "%.1f" $value {{"}}"}}% errors while sending alerts from Prometheus {{"{{"}}$labels.namespace{{"}}"}}/{{"{{"}}$labels.pod{{"}}"}} to Alertmanager {{"{{"}}$labels.alertmanager{{"}}"}}.'
- Prometheus 在向特定 Alertmanager 发送警报时遇到超过 1% 的错误.
原因：
- Prometheus 跟 Alertmanager 之间的网络出现问题了
- Prometheus 配置错误
- Alertmanager 配置错误
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法识别问题并发出告警，要留意了
解决方法：
- 可以延后处理（8-24小时）。
- 检查配置、和网络
40. PrometheusErrorSendingAlertsToAnyAlertmanager
优先级: P2
描述：
- Prometheus encounters more than 3% errors sending alerts to any Alertmanager.
原因： 同上 39. PrometheusErrorSendingAlertsToSomeAlertmanagers
41. PrometheusNotConnectedToAlertmanagers
优先级: P2
描述：
- Prometheus is not connected to any Alertmanagers.
原因： 同上 39. PrometheusErrorSendingAlertsToSomeAlertmanagers
42. PrometheusTSDBReloadsFailing
优先级: P4
描述
- Prometheus has issues reloading blocks from disk.
原因:
- Prometheus服务内部问题
- Prometheus配置错误
- 网络故障
- 磁盘故障
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法识别问题并发出告警，要留意了
解决方法：
- 立即处理
- 如果能够忍受 业务不可用的风险，可以延后处理。
43. PrometheusTSDBCompactionsFailing
- 优先级: P4
同上 42. PrometheusTSDBReloadsFailing
44. PrometheusNotIngestingSamples
- 优先级: P4
同上 42. PrometheusTSDBReloadsFailing
45. PrometheusDuplicateTimestamps
- 优先级: P4
同上 42. PrometheusTSDBReloadsFailing
46. PrometheusOutOfOrderTimestamps
- 优先级: P4
同上 42. PrometheusTSDBReloadsFailing
47. PrometheusRemoteStorageFailures
- 优先级: P1
同上 42. PrometheusTSDBReloadsFailing
48. PrometheusRemoteWriteBehind
- 优先级: P2
同上 42. PrometheusTSDBReloadsFailing
49. PrometheusRemoteWriteDesiredShards
- 优先级: P4
同上 42. PrometheusTSDBReloadsFailing
50. PrometheusRuleFailures
优先级: P2
描述:
- Prometheus is failing rule evaluations.
原因：
- prometheus的告警规则格式错误
能否自愈：
- 不能自愈
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法识别问题并发出告警，要留意了
解决方法：
- 立即处理
- 如果能够忍受 业务不可用的风险，可以延后处理。
51. PrometheusMissingRuleEvaluations
- 优先级: P4
52. AlertmanagerConfigInconsistent
优先级: P4
描述:
- The configuration of the instances of the Alertmanager cluster
{{"{{"}}$labels.service{{"}}"}}are out of sync.
- The configuration of the instances of the Alertmanager cluster
原因：
- Alertmanager配置错误
- kubernetes集群触发bug
能否自愈：
- 不能自愈
影响：
- 对业务访问无影响
- 监控系统无法正常处理告警了
- 一旦业务在这段时间内出现问题，无法发出告警，要留意了
解决方法：
- 立即处理
- 如果能够忍受 业务不可用的风险，可以延后处理。
53. AlertmanagerFailedReload
- 优先级: P2
同上： 52. AlertmanagerConfigInconsistent
54. AlertmanagerMembersInconsistent
- 优先级: P2
同上: 52. AlertmanagerConfigInconsistent
55. TargetDown
- 优先级: P4
同上: 52. AlertmanagerConfigInconsistent
56. ClockSkewDetected
优先级: P4
描述：
- Clock skew detected on node-exporter {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.pod {{"}}"}}. Ensure NTP is configured correctly on this host.
原因：
- 节点时钟错误
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 会引发kubernetes内部问题，业务时间错乱、产生脏数据等。
解决方法：
- 立刻处理
- 检查节点系统时间，及时间同步， 修复后，重启对应节点，并清理redis缓存。
57. NodeNetworkInterfaceFlapping
优先级: P4
描述：
- Network interface "{{"{{"}} $labels.device {{"}}"}}" changing it's up status often on node-exporter {{"{{"}} $labels.namespace {{"}}"}}/{{"{{"}} $labels.pod {{"}}"}}"
原因：
- 网络环境出现问题
- 可能是多网卡环境，多网卡的某些网卡网络故障、或硬件故障
- 也可能是 接入了 waf，受waf的影响
58. PrometheusOperatorReconcileErrors
- 优先级: P4
可忽略
59. PrometheusOperatorNodeLookupErrors
- 优先级: P4
可忽略
60. PodHighMemory
优先级
- P1: mysql内存超过8G、
- P2：redis内存超过1G、rabbitmq超过1G、project-api超过6G、wiki-api超过2G、devops-api超过1G、oness超过1G
描述：
- 各类关键业务、关键中间件的内存暂用过高告警
原因：
- 硬件资源不足
- Pod内存上限限制过低
- 业务有内存泄漏
能否自愈：
- 一般情况下不能，需要人工介入
影响:
- 业务一般情况下能够自愈，但是可能会有秒级的故障感知。
处理方式：
- 硬件资源不足，则升级硬件配置
- Pod内存上限限制过低， 这是可以根据需要合理调整上限。
- 如果硬件资源不足，先扩容硬件，再调整上限
- 业务有内存泄漏，则可以先定期手工执行滚动更新命令 kubectk rollout restart xxx进行缓解，再向 ONES 研发组提bug工单跟进
61. NodeHighMemory
优先级
- p1: 内存使用量超过 90%
- P2: 内存使用量在 85%-90%
描述：
- 节点内存过高
原因：
- 节点资源分配不均
- 某些pod内存泄漏或其他原因占用了太多的内存。
能否自愈：
- 一般情况下不能，需要人工介入
影响：
- 短期（5-10分钟）内对业务影响较小，但是长时间会引发业务故障。
解决方法：
- 立刻处理
- 排查思路:
- kubectl top
- 查看节点pod的负载
- 处理方法:
- 缓解： 把内存占用过高的无状态实例进行手工delete，使其重新调度到空闲的节点上。
- 排查内存消耗问题，再确定处理方式。
- 如果是当前硬件无法承载日益增长的用户量，需要考虑扩容了。
62. ONESMetricsAlert
优先级
- p1:
- 2分钟内 project-api报错超过30条
- 5分钟内 CallLeancloudAPIFailed错误超过30条
- 5分钟内 RedisError错误超过1条
- 5分钟内 SendEmailFailed错误超过10条
- 24小时内发送了超过8000封邮件
- P2:
- 2分钟内 project-api报错在10-30条之间
- 5分钟内 CallLeancloudAPIFailed错误在10-30条之间
- 24小时内发送了超过6000封邮件
- 5分钟内产生了NginxUpstreamTimedOut错误
- 2分钟内产生了CanalKafkaError错误（canal连接kafka出现了错误）
- p1:
描述：
- 各类业务监控信息
原因：
- 各类关键业务、关键中间件 出现故障
- 业务出现bug
影响:
- 可能导致部分接口报错
- 可能导致长期服务故障
- 可能导致短时间服务故障
- 可能中间件故障
处理方式：
- 立即联系ONES进行处理
- 由ONES根据问题的严重程度，来判断处理方式
- 排查各类关键业务、关键中间件的故障
63. ONESProcessCountWarn
优先级：P1
原因：
- 节点的进程数量超过15000阈值
影响：
- 暂时不会对业务访问照成影响
- 长期不处理，将导致 k8s集群的监控检查机制崩溃，导致业务故障
处理方式：
- 立即联系ONES进行处理（处理僵死进程）
64. MysqlMasterCheck
默认优先级: P2
描述:
- master pod '%s' is not the same as the last one '%s'
原因：
- 可能是 mysql 主库故障，自动进行了故障转移，切换到新主库上
- 可能是 实施手工执行了 mysql的优雅切主操作。
- 可能是 旧主库所在节点 负载过高 或出现 底层bug（操作系统内核、docker的bug）
影响：
- 业务相关的同步管道，可能中断一小段时间，一般情况下能够管道自己能够自行恢复
能否自愈：
- 大多数情况下，都能够自愈， 但是需要运维关注从库的状态，确保从库的同步是正常的。
处理方式：
- 检查mysql状态是否正常，执行命令 ./script/mysql/status.sh ones
- 如有异常，如果有异常则需要联系ONES处理
- 需要注意一下 旧主库所在的节点是否正常，如果节点有异常，需要联系ONES处理
65. NamePodCheck
默认优先级: P2
描述:
- failed to get pod '%s'
- pods '%+v' are on the same node '%s'
- pod name is empty
- pod '%s' role not found
- pod '%s' unhealthy
- pod '%s' node not found
- pod '%s' version not found
原因：
- pod '%s' unhealthy
- 可能是在升级ONES版本过程中，mysql有比较大的数据迁移，从库跟主库的binlog偏移量相差过大。
- 可能是MySQL从库bug，或其他原因，导致从库无法继续同步主库的数据。
- kubernetes bug 或 节点负载过高 引起的 调度问题
- pod '%s' unhealthy
能否自愈：
- 一般情况下，能够自愈。
影响：
- 需要 10-60秒的完成自动的故障转移，期间业务的访问会受到影响。
处理方式：
- 检查mysql状态是否正常，执行命令 ./script/mysql/status.sh ones
- 特殊情况处理：
- 没有在做ONES版本的期间发送告警
- 需要人工介入分析原因，进行风险排查。（请联系ONES）
- 在做ONES版本升级
- 对于pod unhealthy，能够自愈，因为此时从库跟主库的binlog偏移量相差过大，一段时间后，主从同步完成后，则会恢复健康(收到MysqlRcover通知)。
- 如果是其他告警，需要人工介入分析原因，进行风险排查。（请联系ONES） 。
66. MysqlFindMaster
默认优先级: P2
描述:
- master not found
- too many master nodes '%+v'
原因：
- mysql主从状态异常
能否自愈：
- 一般情况下无法自愈
影响：
- mysql无法正常连接或使用
处理方式：
- 立即联系ONES进行处理
67. MysqlRcover
默认优先级: P4
描述:
- Mysql cluster becomes healthy.
原因：
- mysql恢复健康通知
能否自愈：
- 属于恢复健康的通知
影响：
- 无
处理方式：
- 无
📄️ Node故障处理
本文介绍关于 k3s/k8s Node节点异常问题的诊断流程、排查思路、常见问题及解决方案。
📄️ POD故障处理
本文介绍关于 k3s/k8s Pod异常问题的诊断流程、排查方法、常见问题及解决方案。
📄️ Alert故障处理
本文介绍关于 k3s/k8s 常见告警主题处理及解决方案。
📄️ ONES故障处理
本文介绍关于 ONES 常见场景故障处理及解决方案。