调整描述

linuxerwang · Jun 8, 2020 · 8211bbc · 8211bbc
1 parent 9a5e097
commit 8211bbc
Show file tree

Hide file tree

Showing 2 changed files with 6 additions and 2 deletions.
diff --git a/content/posts/prometheus/2020-05-16-metrics.md b/content/posts/prometheus/2020-05-16-metrics.md
@@ -356,7 +356,7 @@ http_durations_seconds_count{path="/summary"} 5
 
 在本章节中我们介绍并实操了 Prometheus 的四种度量指标类型 Counter、Gauge、Histogram、Summary，这四种度量类型都极具代表性：Counter 是单调递增的计数器，Gauge 是可任意调整数值的仪表盘，Histogram 是分组区间统计，Summary 是中位数统计。
 
-其中 Histogram 和 Summary 具有一定的 “相似” 度，因为在 Histogram 指标中我们可以通过 `histogram_quantile` 函数计算出分位值，而 Summary 也可以计算分位值，两者区别就在于 Histogram 是在服务端计算的，而 Summary 是在客户端就进行了计算，也相应的有利有弊，具体我们在后面的章节继续深入学习。
+其中 Histogram 和 Summary 具有一定的 “相似” 度，因为在 Histogram 指标中我们可以通过 `histogram_quantile` 函数计算出分位值，而 Summary 也可以计算分位值，两者区别就在于 Histogram 是在服务端计算的，而 Summary 是在客户端就进行了计算，其一个计算好了再推上去，一个直接推上去，数据维度不一样，可以做的事情也不一样，有利有弊，具体可以根据指标的实际情况做衡量。
 
 
 另外针对度量指标的命名，这是一个非常多人问的问题，因为命名是一个难题，在这里大家可以参照官方的[文档](https://prometheus.io/docs/practices/naming/)建议去针对指标命名就可以了。

diff --git a/content/posts/why-container-memory-exceed.md b/content/posts/why-container-memory-exceed.md
@@ -124,11 +124,15 @@ Linux xxx-xxx-99bd5776f-k9t8z 3.10.0-693.2.2.el7.x86_64
 
 在本场景中 cadvisor 所提供的判别标准 container_memory_working_set_bytes 是不可变更的，也就是无法把判别标准改为 RSS，因此我们只能考虑掌握主动权。
 
+### 内部解决
+
 首先是做好做多级内存池管理，可以缓解这个问题的症状。但这存在难度，从另外一个角度来看，你怎么知道什么时候在哪个集群上会突然出现这类型的服务，何况开发人员的预期情况参差不齐，写多级内存池写出 BUG 也是有可能的。
 
 让业务服务无限重启，也是不现实的，**被动重启，没有控制，且告警，存在风险**。
 
-因此为了掌握主动权，可以在部署环境可以配合脚本做 “手动” HPA，当容器内存指标超过约定限制后，起一个新的容器替换，再将原先的容器给释放掉，就可以在预期内替换且业务稳定了。
+### 外部解决
+
+为了掌握主动权，我们可以在部署环境可以配合脚本做 “手动” HPA，当容器内存指标超过约定限制后，起一个新的容器替换，再将原先的容器给释放掉，就可以在预期内替换且业务稳定了。
 
 ![image](https://image.eddycjy.com/2b449204373cd0d7c8e8501a326061a7.jpg)