你好，选型了解一下

标签：prometheus   监控   k8s   

看到这篇文章，说明你正在为自己的监控场景进行选型。软件选型之所以重要，是因为我们要以自己的需求为标准，选择那些可以满足需求的解决方案。所以，知道自己要什么很重要。当然需求可以从很多的维度去刻画，这里也无法一一列举。但是希望大家带着这样问题往下看：我的场景是否可以匹配Prometheus的适用场景？是否可以接受不适用的相关限制？

适用场景了解一下

存在即合理。Prometheus不是万能的，可能也不存在一款万能的软件吧o(╯□╰)o。
不过Prometheus也许正是你所需要的解决方案。
首先需要简要说明Pormetheus的工作模式，这样有助于更好的理解使用场景和不适用场景的原因：

• 采用pull的方式，而非push的方式。
• 每隔一个固定的时间间隔（如10秒），通过pull的方式去主动收集监控信息

那接下来就是千呼万唤的Prometheus的适用不适用场景列表：

适用场景：

• 收集时序值为纯数字的场景
• 传统的以主机为中心的相关监控场景
• 面向动态特性的微服务场景
• 对已有数据具有再分类聚合和查询需求的场景
• 要求高可靠性的场景。

不适用场景：

• 实时高精度的监控场景。例如：基于监控项的变化而实时感知。

特别说明1：高可靠性。可以通过启动多个完全一样但是独立的Prom Server来达到高可靠的目的，这里需要说明的是每一个server之间都是独立的，各自存储各自的数据。

特别说明2：不适用实时高精度的监控场景。
看完特别说明1，有没有觉得哪里有点问题？这多个独立Server之间的数据岂不是不一样？呃，真的是这样的。那这叫什么高可用o(╯□╰)o？所以这是Prometheus不具备实时高精度监控的一个体现。那他究竟适用于什么样的场景(⊙o⊙)？总的来说就是非实时高精度的统计场景：

1. 那些监控指标项数据只关注相对一段时间之内的变化差异的场景。其实这样的场景很普遍，比如1分钟之内的cpu平均使用率。
2. 允许监控指标项在之前很短的时间段内选择最新的一个值，并且认为它能代表当前的数据，比如允许当前内存使用量返回的数据是上一个采集周期采集到的值来代表当前状态的值。
3. 两个server之间的数据不一致并不代表数据是错的，而是周期性采集的真实结果在不同具体时间点上的体现。

所以，只要上述非实时高精度的限制对于你的场景需求来说不是问题（对于多数场景往往也不是问题），那Prometheus就是你需要的具有高可靠性的监控工具。

你好，选型了解一下

标签：prometheus   监控   k8s   

原文地址：http://blog.51cto.com/8721244/2094149