总结：K8S可观测-创新互联
Kubernetes 系统的可观测性方案包括指标、日志、链路追踪、K8s Event 事件、NPD 框架等方式。
https://new.qq.com/rain/a/20210605A02GBV00
二、指标（Metrics）Prometheus 是业界指标类数据采集方案的事实标准，是开源的系统监测和报警框架。
Prometheus 具有以下特性：
多维的数据模型（基于时间序列的 Key、Value 键值对）
灵活的查询和聚合语言 PromQL
通过基于 HTTP 的 Pull模型采集或利用 Pushgateway实现 Push 模式
可通过动态服务发现或静态配置发现目标机器
支持多种图表和数据大盘
Prometheus 可以周期性采集组件暴露在 HTTP(s) 端点的/metrics 下面的指标数据，并存储到 TSDB，实现基于 PromQL 的查询和聚合功能。
https://blog.csdn.net/w2009211777/article/details/123822132
三、K8S指标：容器基础资源指标采集源为 kubelet 内置的 cAdvisor，提供容器内存、CPU、网络、文件系统等相关的指标，指标样例包括：
容器当前内存使用字节数 container_memory_usage_bytes；
容器网络接收字节数 container_network_receive_bytes_total；
容器网络发送字节数 container_network_transmit_bytes_total，等等。
四、K8S指标：节点资源指标采集源为 node_exporter，提供节点系统和硬件相关的指标，指标样例包括：节点总内存 node_memory_MemTotal_bytes，节点文件系统空间 node_filesystem_size_bytes，节点网络接口 ID node_network_iface_id，等等。基于该类指标，可以统计节点的 CPU/内存/磁盘使用率等节点级别指标。
针对node_exporter，我们是单独部署了一个prometheus采集，专门给管理员他们看的，业务部关系node
五、K8S指标：资源指标采集源为 kube-state-metrics，基于 Kubernetes API 对象生成指标，提供 K8s 集群资源指标，例如 Node、ConfigMap、Deployment、DaemonSet 等类型。以 Node 类型指标为例，包括节点 Ready 状态指标 kube_node_status_condition、节点信息kube_node_info 等等。
六、K8S指标：组件指标1、Kubernetes 系统组件指标
例如 kube-controller-manager, kube-apiserver，kube-scheduler, kubelet，kube-proxy、coredns 等。
2、Kubernetes 运维组件指标。
可观测类包括 blackbox_operator, 实现对用户自定义的探活规则定义；gpu_exporter，实现对 GPU 资源的透出能力。
3、Kubernetes 业务应用指标。
包括具体的业务Pod在/metrics 路径透出的指标，以便外部进行查询和聚合。
除了上述指标，K8s 提供了通过 API 方式对外透出指标的监测接口标准，具体包括 Resource Metrics，Custom Metrics 和 External Metrics 三类。
十、Pod异常排查 1、Pod 状态异常就绪失败，即 Pod 一直无法到达 Ready 状态，无法接收请求进行业务处理，常见的根因如下：
资源不足，无法调度（Pending），即集群的 Node 没有预留资源能够满足 Pod 的 Request 资源。
镜像拉取失败（ ImagePullBackoff ），镜像的仓库地址，tag 出现问题。
磁盘挂载失败（Pending），容器挂载的 PVC 没有 bound。
Liveless probe 探针失败，频繁重启。
Readiness probe 探针失败，无法达到 Ready 状态。
postStart 执行失败，一直无法进入运行状态。
运行时程序崩溃（ CrashLoopBackOff ），频繁重启。
配置错误，比如挂载的 Volume 不存在（RunContainerError）。
报告期内出现 Pod 频繁重启现象，常见的根因如下：
程序异常退出，比如非法地址访问，比如进入了程序需要退出的条件等。
容器内存使用量超过内存 Limit 量，被 OOMKilled。
具体体现在 Pod 服务的请求错误率变高或者请求处理 P95 响应时间高等，常见的根因如下：
请求量突增，程序自身可能触发流控或者其他异常处理，导致请求处理失败率提升；
自身代码处理错误，请求量没有变化，可能是上线新的功能有 bug；
不可压缩资源不足（磁盘，内存），请求处理包含磁盘的写操作，资源不足出现失败；外部依赖服务报错，请求处理需要调用下游服务，他们报错引发请求处理失败。
外部依赖服务响应时间高，请求处理需要调用下游服务，他们的响应时间高会导致请求处理慢。
Pod 容器出现内存 OOM，Pod 频繁重启，常见的根因如下：
自身代码内存泄露；
Pod 内存 Request 值偏低，如果该值偏低的情况下配置 HPA，会频繁触发扩容，同时具有被驱逐的风险。
Pod 内存 Limit 值偏低，容器内存使用量超过 Limit 值会被 OOMKilled 掉。
Pod 的整体 CPU 使用率一直维持在超过 80% 的状态，常见的根因如下：
自身代码效率不足，业务处理的时间复杂度太高，需要找到热点方法进行优化；
Pod CPU Request 值偏低，如果该值偏低的情况下配置 HPA，会频发触发扩容，同时具有被驱逐的风险。
https://new.qq.com/rain/a/20210605A02GBV00
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
分享题目：总结：K8S可观测-创新互联
文章起源：http://azwzsj.com/article/dpjohi.html
