做企业网站收费多少,品牌形象设计的意义,东莞机械建站如何,用宝塔做网站步骤1、Prometheus、Metrics Server与Kubernetes监控体系 简介#xff1a; Prometheus 项目与 Kubernetes 项目一样#xff0c;也来自于 Google 的 Borg 体系#xff0c;它的原型系统#xff0c;叫作 BorgMon#xff0c;是一个几乎与 Borg 同时诞生的内部监控系统 Pro…1、Prometheus、Metrics Server与Kubernetes监控体系 简介 Prometheus 项目与 Kubernetes 项目一样也来自于 Google 的 Borg 体系它的原型系统叫作 BorgMon是一个几乎与 Borg 同时诞生的内部监控系统 Prometheus 项目的作用和工作方式官方示意图 Prometheus 项目工作的核心是使用 Pull 抓取的方式去搜集被监控对象的 Metrics 数据监控指标数据然后再把这些数据保存在一个 TSDB 时间序列数据库比如 OpenTSDB 、 InfluxDB 等当中以便后续可以按照时间进行检索。 Pushgateway 允许被监控对象以 Push 的方式向Prometheus 推送 Metrics 数据 Alertmanager 可以根据 Metrics 信息灵活地设置报警 Grafana 对外暴露出的、可以灵活配置的监控数据可视化界面 1.1、Metrics 数据的来源
第一种 Metrics是宿主机的监控数据 这部分数据的提供需要借助一个由 Prometheus 维护的Node Exporter 工具就是代替被监控对象来对Prometheus 暴露出可以被“抓取”的 Metrics 信息的一个辅助进程。 第二种 Metrics 是来自于 Kubernetes 的 API Server 、kubelet 等组件的 /metrics API 除了常规的 CPU 、内存的信息外这部分信息还主要包括了各个组件的核心监控指标。比如对于 API Server 来说它就会在 /metrics API 里暴露出各个 Controller 的工作队列 Work Queue 的长度、请 求的 QPS 和延迟数据等等。这些信息是检查 Kubernetes 本身工作情况的主要依据。 第三种 Metrics 是 Kubernetes 相关的监控数据 这部分数据一般叫作 Kubernetes 核心监控数据core metrics 。这其中包括了 Pod 、 Node 、容器、Service 等主要 Kubernetes 核心概念的Metrics。 这里提到的 Kubernetes 核心监控数据其实使用的是 Kubernetes 的一个非常重要的扩展能力叫作Metrics Server。在社区的定位是用来取代Heapster。 在具体的监控指标规划上建议你 遵循业界通用的 USE 原 则和 RED 原则 USE 原则指的是按照如下三个维度来规划资源监控指标原则是主要关注“ 资源 ” 利用率Utilization资源被有效利用起来提供服务的平均时间占比 饱和度Saturation资源拥挤的程度比如工作队列的长度 错误率Errors错误的数量。 RED 原则指的是按照如下三个维度来规划服务监控指标 原则是主要关注“ 服务 ” 每秒请求数量Rate 每秒错误数量Errors 服务响应时间Duration。 2、日志收集与管理 Kubernetes 中对容器日志的处理方式 , 都叫做 cluster-level-logging即这个日志处理系统与容器、 Pod 以及 Node 的生命周期都是完全无关的。这种设计当然是为了保证无论是容器挂了、Pod 被删除甚至节点宕机的时候应用的日志依然可以被正常获取到。 第一种在 Node 上部署 logging agent 将日志文件转发 到后端存储里保存起来 架构图如下 这里的核心在于 logging agent 它一般都会以DaemonSet 的方式运行在节点上然后将宿主机上的容器日志目录挂载进去最后由 logging-agent 把日志转发出去。 优势 在 Node 上部署 logging agent 在于一个节点只需要部署一个 agent 并且不会对应用和 Pod 有任何侵入性。 不足 要求应用输出的日志都必须是直接输出到容器的stdout 和 stderr 里。即如果每秒日志量很大时直接输出到容器的stdout 和 stderr, 很容易就把系统日志配额用满因为对系统默认日志工具是针对单服务( 例如 docker) 而不是进程进行限额的最终导致的结果就是日志被吞掉。解决办法一个是增加配额一个是给容器挂上存储将日志输出到存储上 stdout 和 stderr stdout 是标准输出 stderr 是错误输出 第二种就是对这种特殊情况的一个处理即当容器的日志 只能输出到某些文件里的时候我们可以通过一个 sidecar 容器把这些日志文件重新输出到 sidecar 的 stdout 和 stderr 上这样就能够继续使用第一种方案了。 架构图如下 不足 宿主机上实际上会存在两份相同的日志文件一份是应用自己写入的另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费除非万不得已或者应用容器完全不可能被修改否则不要使用这个方案 第三种方案就是通过一个 sidecar 容器直接把应用的日 志文件发送到远程存储里面去 架构图如下 优势 直接把日志输出到固定的文件里而不是 stdout logging-agent 可以使用 uentd 后端存储可以是 ElasticSearch 。部署简单对宿主机友好。 不足 这个 sidecar 容器很可能会消耗较多的资源甚至拖垮应用容器。并且由于日志还是没有输出到 stdout 上所以你通过 kubectl logs 是看不到任何日志输出的。 最后无论是哪种方案都必须要及时将这些日志文件从宿主机上清理掉或者给日志目录专门挂载一些容量巨大的远程盘。否则一旦主磁盘分区被打满整个系统就可能会陷入奔溃状态。
