48 | Prometheus、Metrics Server与Kubernetes监控体系
该思维导图由 AI 生成,仅供参考
- 深入了解
- 翻译
- 解释
- 总结
Prometheus、Metrics Server与Kubernetes监控体系 本文介绍了Prometheus、Metrics Server与Kubernetes监控体系的核心技术。Prometheus作为Kubernetes监控体系的核心项目,以Pull方式搜集被监控对象的Metrics数据,并保存在时间序列数据库中。其配套组件包括Pushgateway和Alertmanager,以及通过Grafana提供的监控数据可视化界面。文章还介绍了Kubernetes监控数据的三种来源:宿主机监控数据、来自Kubernetes API Server和kubelet的/metrics API的数据,以及Kubernetes核心监控数据,其中Metrics Server取代了Heapster项目,通过标准的Kubernetes API暴露监控数据。此外,文章还解释了Aggregator模式的工作原理和Metrics Server的部署方法。最后,建议遵循业界通用的USE原则和RED原则进行监控指标规划。文章深入浅出地介绍了Kubernetes监控体系的设计和Prometheus项目的地位,为读者提供了全面的认知和技术指导。 总结:本文深入介绍了Prometheus、Metrics Server与Kubernetes监控体系的核心技术,包括Prometheus的工作方式、Metrics数据的来源和Aggregator模式的工作原理,为读者提供了全面的认知和技术指导。
《深入剖析 Kubernetes》,新⼈⾸单¥68
全部留言(29)
- 最新
- 精选
- Acter1.老师能讲下prometheus的部署方式吗?比如helm部署,operator部署,过程中具体发生了什么? 2.能否解析下prometheus server配置文件中,jobs的写法,alert rule的写法?还有alertmanager的配置。感谢
作者回复: 篇幅所限,prometheus 项目具体的玩法不进行详细展开了
2018-12-1225 - --核心监控数据是Prometheus通过Metric Server拉取的还是直接从kubelet拉取?
作者回复: metric server
2020-02-245 - leisland老师您好,我想请教你一个k8s问题。我们使用liveness probe探针检查容器健康状态,这个探针执行的是容器里一个脚本。当容器内存和CPU过载时这个脚本会一直执行卡死然后超时。现在看k8s好像不认为执行超时是失败,在不停的去执行脚本。从而检查不到容器异常了,容器一直不重拉起。我们设置失败上限是3次,应该没起作用。请问有没有办法可以解决呢?业界都是怎么使用探针的呢?
作者回复: 最常用的是暴露healthcheck 端口,脚本也常用,但得处理好各种异常情况
2020-03-081 - 孙健波Pull和Push两种模式的区别非常有意思,Prometheus非常大胆的采用了pull的模式,但是仔细思考后就会觉得非常适合监控的场景。 Pull模式的特点 1. 被监控方提供一个server,并负责维护 2. 监控方控制采集频率 第一点其实对用户来说要求过高了,但是好处很多,比如pull 不到数据本身就说明了节点存在故障;又比如监控指标自然而言由用户自己维护,使得标准化很简单。 第二点其实更为重要,那就是监控系统对metric采集的统一和稳定有了可靠的保证,对于数据量大的情况下很重要。 缺点也很明显,用户不知道你什么时候来pull一下,数据维护多久更新也不好控制,容易造成一些信息的丢失和不准确。 当把这些优缺点权衡过后就会发现,纯监控的场景确实是适合pull的2018-12-22457
- GoswingPush模式的优点是在正常情况下数据的延迟可以做到更低,也就是能更快的获取metrics并发现问题,而pull模式一般不会设定很短的轮询时间,所以延迟更高一些。 Push模式的缺点我能想到以下几个: 1 增加了服务的实现复杂度(比如推送错误处理等); 2 不利于平行扩展; 3 不支持自定义metrics采集策略,比如高峰期减少采集频率。2018-12-1314
- 拉欧pull是拉动作,监听者主动调用被监听者的接口 push是推动作,被监听者主动上报,监听者被动采集 拉动作有助于监听者自己控制频率和采样量,缺点是需要掌握所有被监听者的地址和端口,也就是要有注册中心; 推动作有利于被监听者自己控制上报数量和频率,但有可能对监听者构成额外的压力,同时有信息丢失的风险2019-11-3013
- CalvinXiaopush 方式针对没有 http 接口应用,例如 worker,可以设定每 5 秒上报处理了多少个 job,平均每个 job 耗时多少,有多少个错误等数据,需要配合 push gateway 使用。 当然,也可以自己写一个 exporter 通过查询日志来得到这些数据,然后用 pull 方式来获取。push 方式可以联想到 APM。2018-12-139
- 狮锅艺文中缺少的链接:https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh2019-04-175
- 我要收购腾讯prometheus 的pull模式搭配自己的kubernetes SD, 加上prometheus-operator的service monitor的抽象,可以很大程度的简化配置的复杂程度2018-12-125
- 我在睡觉我认为拉取的最大好处是解耦,metric server对外提供标准接口,第三方实现自己的监控逻辑。还有部署的时候更方便,如果使用push的方式,那么部署一个监控组件之后需要用某种方式配置metric server,让他知道一个监控服务的存在以便通知上报数据,这样对于监控数据描述的配置文件都要配置到metric server(metric server也需要实现逻辑来处理这些配置),这显然增加了使用的复杂度,也不不够灵活。2021-03-2013