深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116709 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

48 | Prometheus、Metrics Server与Kubernetes监控体系

cAdvisor服务
Metrics Server
kubelet
API Server
Node Exporter
Grafana可视化界面
Alertmanager
Pushgateway
TSDB保存数据
Pull方式采集Metrics数据
监控机制
起源
CNCF基金会
RED原则
USE原则
开启方式
工作原理
Aggregator插件机制
通过标准Kubernetes API暴露监控数据
替代Heapster
Kubernetes核心监控数据
Kubernetes组件的/metrics API
宿主机监控数据
组件
项目介绍
异同和优缺点
监控指标规划
Kubernetes监控体系建设方向
Prometheus项目地位
监控体系设计
Prometheus Operator
部署Metrics Server
Aggregator模式
Metrics Server
Metrics来源
Prometheus
总结
Kubernetes监控体系

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:Prometheus、Metrics Server 与 Kubernetes 监控体系。
通过前面的文章,我已经和你分享过了 Kubernetes 的核心架构,编排概念,以及具体的设计与实现。接下来,我会用 3 篇文章,为你介绍 Kubernetes 监控相关的一些核心技术。
首先需要明确指出的是,Kubernetes 项目的监控体系曾经非常繁杂,在社区中也有很多方案。但这套体系发展到今天,已经完全演变成了以 Prometheus 项目为核心的一套统一的方案。
在这里,可能有一些同学对 Prometheus 项目还太不熟悉。所以,我先来简单为你介绍一下这个项目。
实际上,Prometheus 项目是当年 CNCF 基金会起家时的“第二把交椅”。而这个项目发展到今天,已经全面接管了 Kubernetes 项目的整套监控体系。
比较有意思的是,Prometheus 项目与 Kubernetes 项目一样,也来自于 Google 的 Borg 体系,它的原型系统,叫作 BorgMon,是一个几乎与 Borg 同时诞生的内部监控系统。而 Prometheus 项目的发起原因也跟 Kubernetes 很类似,都是希望通过对用户更友好的方式,将 Google 内部系统的设计理念,传递给用户和开发者。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
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)

  • 最新
  • 精选
  • Acter
    1.老师能讲下prometheus的部署方式吗?比如helm部署,operator部署,过程中具体发生了什么? 2.能否解析下prometheus server配置文件中,jobs的写法,alert rule的写法?还有alertmanager的配置。感谢

    作者回复: 篇幅所限,prometheus 项目具体的玩法不进行详细展开了

    2018-12-12
    25
  • --
    核心监控数据是Prometheus通过Metric Server拉取的还是直接从kubelet拉取?

    作者回复: metric server

    2020-02-24
    5
  • leisland
    老师您好,我想请教你一个k8s问题。我们使用liveness probe探针检查容器健康状态,这个探针执行的是容器里一个脚本。当容器内存和CPU过载时这个脚本会一直执行卡死然后超时。现在看k8s好像不认为执行超时是失败,在不停的去执行脚本。从而检查不到容器异常了,容器一直不重拉起。我们设置失败上限是3次,应该没起作用。请问有没有办法可以解决呢?业界都是怎么使用探针的呢?

    作者回复: 最常用的是暴露healthcheck 端口,脚本也常用,但得处理好各种异常情况

    2020-03-08
    1
  • 孙健波
    Pull和Push两种模式的区别非常有意思,Prometheus非常大胆的采用了pull的模式,但是仔细思考后就会觉得非常适合监控的场景。 Pull模式的特点 1. 被监控方提供一个server,并负责维护 2. 监控方控制采集频率 第一点其实对用户来说要求过高了,但是好处很多,比如pull 不到数据本身就说明了节点存在故障;又比如监控指标自然而言由用户自己维护,使得标准化很简单。 第二点其实更为重要,那就是监控系统对metric采集的统一和稳定有了可靠的保证,对于数据量大的情况下很重要。 缺点也很明显,用户不知道你什么时候来pull一下,数据维护多久更新也不好控制,容易造成一些信息的丢失和不准确。 当把这些优缺点权衡过后就会发现,纯监控的场景确实是适合pull的
    2018-12-22
    4
    57
  • Goswing
    Push模式的优点是在正常情况下数据的延迟可以做到更低,也就是能更快的获取metrics并发现问题,而pull模式一般不会设定很短的轮询时间,所以延迟更高一些。 Push模式的缺点我能想到以下几个: 1 增加了服务的实现复杂度(比如推送错误处理等); 2 不利于平行扩展; 3 不支持自定义metrics采集策略,比如高峰期减少采集频率。
    2018-12-13
    14
  • 拉欧
    pull是拉动作,监听者主动调用被监听者的接口 push是推动作,被监听者主动上报,监听者被动采集 拉动作有助于监听者自己控制频率和采样量,缺点是需要掌握所有被监听者的地址和端口,也就是要有注册中心; 推动作有利于被监听者自己控制上报数量和频率,但有可能对监听者构成额外的压力,同时有信息丢失的风险
    2019-11-30
    13
  • CalvinXiao
    push 方式针对没有 http 接口应用,例如 worker,可以设定每 5 秒上报处理了多少个 job,平均每个 job 耗时多少,有多少个错误等数据,需要配合 push gateway 使用。 当然,也可以自己写一个 exporter 通过查询日志来得到这些数据,然后用 pull 方式来获取。push 方式可以联想到 APM。
    2018-12-13
    9
  • 狮锅艺
    文中缺少的链接:https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh
    2019-04-17
    5
  • 我要收购腾讯
    prometheus 的pull模式搭配自己的kubernetes SD, 加上prometheus-operator的service monitor的抽象,可以很大程度的简化配置的复杂程度
    2018-12-12
    5
  • 我在睡觉
    我认为拉取的最大好处是解耦,metric server对外提供标准接口,第三方实现自己的监控逻辑。还有部署的时候更方便,如果使用push的方式,那么部署一个监控组件之后需要用某种方式配置metric server,让他知道一个监控服务的存在以便通知上报数据,这样对于监控数据描述的配置文件都要配置到metric server(metric server也需要实现逻辑来处理这些配置),这显然增加了使用的复杂度,也不不够灵活。
    2021-03-20
    1
    3
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部