@@ -18,7 +18,7 @@ endif::rootpath[]
18
18
19
19
prometheus官方架构图。
20
20
21
- image::image-2024-12-25-10-03-02-517.png[]
21
+ image::prometheus/ image-2024-12-25-10-03-02-517.png[]
22
22
23
23
TIP: 以下代码相关内容是参考的prometheus 3.0.1 2024-11-28
24
24
@@ -177,7 +177,7 @@ request latency seconds :mean5m {job="myjob"} > 0.5
177
177
178
178
多个prometheus实例可以组成一个集群,用来监控多个实例。多个prometheus节点组成两层联邦结构,下层的prometheus充当代理。
179
179
180
- image::image-2024-12-25-11-55-51-356.png[]
180
+ image::prometheus/ image-2024-12-25-11-55-51-356.png[]
181
181
182
182
存在问题:
183
183
@@ -187,7 +187,7 @@ image::image-2024-12-25-11-55-51-356.png[]
187
187
*Thanos*
188
188
189
189
.Thanos架构图
190
- image::image-2024-12-25-12-06-25-188.png[]
190
+ image::prometheus/ image-2024-12-25-12-06-25-188.png[]
191
191
192
192
193
193
=== 数据存储
@@ -244,7 +244,7 @@ type Querier interface {
244
244
245
245
当执行fanout中的方法时,fanout会首先执行本地存储primary的Add方法,然后便利执行每个远端存储的Add方法。
246
246
247
- image::image-2024-12-25-14-37-44-315.png[]
247
+ image::prometheus/ image-2024-12-25-14-37-44-315.png[]
248
248
249
249
[source, go]
250
250
----
@@ -341,7 +341,7 @@ TSDB设计有两个核心:block和WAL,而block又包含chunk、index、meta.
341
341
可以看到ULID的总长度为128字节,为了生成可排序的字符串,Prometheus使用Base32算法,转化为26字节的可排序字符串。
342
342
343
343
.block 组成示意图
344
- image::image-2024-12-25-15-06-32-209.png[]
344
+ image::prometheus/ image-2024-12-25-15-06-32-209.png[]
345
345
346
346
- chunks
347
347
@@ -975,7 +975,7 @@ USE方法全称"Utilization Saturation and Errors Method",主要用于分析
975
975
976
976
告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示,通过在Prometheus中定义AlertRule(告警规则),Prometheus会周期性的对告警规则进行计算,如果满足告警触发条件就会向Alertmanager发送告警信息。
977
977
978
- image::../image /image-2025-01-11-15-40-34-346.png[]
978
+ image::prometheus /image-2025-01-11-15-40-34-346.png[]
979
979
980
980
- 告警名称:用户需要为告警规则命名,当然对于命名而言,需要能够直接表达出该告警的主要内容
981
981
- 告警规则:告警规则实际上主要由PromQL进行定义,其实际意义是当表达式(PromQL)查询结果持续多长时间(During)后出发告警
@@ -989,7 +989,7 @@ Alertmanager作为一个独立的组件,负责接收并处理来自Prometheus
989
989
990
990
Alertmanager除了提供基本的告警通知能力以外,还主要提供了如:分组、抑制以及静默等告警特性:
991
991
992
- image::../image /image-2025-01-11-15-45-38-890.png[]
992
+ image::prometheus /image-2025-01-11-15-45-38-890.png[]
993
993
994
994
- 分组
995
995
@@ -1335,7 +1335,7 @@ source_match_re:
1335
1335
1336
1336
广义上讲所有可以向Prometheus提供监控样本数据的程序都可以被称为一个Exporter。而Exporter的一个实例称为target,如下所示,Prometheus通过轮询的方式定期从这些target中获取样本数据:
1337
1337
1338
- image::../image /image-2025-01-14-16-27-29-566.png[]
1338
+ image::prometheus /image-2025-01-14-16-27-29-566.png[]
1339
1339
1340
1340
=== 集群和高可用
1341
1341
@@ -1346,7 +1346,7 @@ Prometheus内置了一个基于本地存储的时间序列数据库。在Prometh
1346
1346
1347
1347
=== 监控kubernets
1348
1348
1349
- image::../image /image-2025-01-20-11-20-30-684.png[]
1349
+ image::prometheus /image-2025-01-20-11-20-30-684.png[]
1350
1350
1351
1351
Pod是Kubernetes中的最小调度资源。Pod中会包含一组容器,它们一起工作,并且对外提供一个(或者一组)功能。对于这组容器而言它们共享相同的网络和存储资源,因此它们之间可以直接通过本地网络(127.0.0.1)进行访问。当Pod被创建时,调度器(kube-schedule)会从集群中找到满足条件的节点运行它。
1352
1352
0 commit comments