目录
5. Data visualization and export 数据可视化和导出
7. When does it not fit? 不适合场景
一、 Prometheus组件及架构
官网：Prometheus - Monitoring system & time series database
1. Prometheus server 服务端
作用：抓取和存储时间序列数据
2. Pushgateway 推送网关
作用：推送一些Prometheus无法抓取的数据
3. Alertmanager 警报管理器
作用：警报阈值的设置与发送
4. Prometheus targets 数据采集
5. Data visualization and export 数据可视化和导出
- Prometheus web Ul：Prometheus 自带数据可视化
- Grafana：数据可视化（推荐）
- API clients：
6. When does it fit? 适合场景
Prometheus works well for recording any purely numeric time series. It fits both machine-centric monitoring as well as monitoring of highly dynamic service-oriented architectures. In a world of microservices, its support for multi-dimensional data collection and querying is a particular strength.
Prometheus is designed for reliability, to be the system you go to during an outage to allow you to quickly diagnose problems. Each Prometheus server is standalone, not depending on network storage or other remote services. You can rely on it when other parts of your infrastructure are broken, and you do not need to setup extensive infrastructure to use it.
7. When does it not fit? 不适合场景
Prometheus values reliability. You can always view what statistics are available about your system, even under failure conditions. If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough. In such a case you would be best off using some other system to collect and analyze the data for billing, and Prometheus for the rest of your monitoring.
二、 Prometheus数据模型
我们需要了解是什么构成了时间序列以及如何存储这些数据。
1. 时间序列数据（带时间戳的数据）
时间序列数据通常可以定义为一个数字数据点的序列，这些数据点按时间顺序从同一来源索引。在Prometheus的范用内这些数据点是在固定的时间间隔内收集的。因此，这种数据以图形形式表示时，通常会绘制数据随时间的演变，X轴表示时间，y轴表示数据值。
2. 时间序列的数据库
在处理来自收集器和传感器(如组成物联网的那些)的大量数据时，如果数据库没有在设计时考虑到用例，那么查询结果数据集的速度会非常慢。虽说可以使用其它的关系型数据库，但是查询速度往往不理想。
因此，现代时间序列数据库存储以下组件:
时间戳
值
关于值的一些上下文，以度量名称或关联的键/值对进行编码
一个符合时间序列数据库规范的抽象数据示例如下:
timestamp=1544978108，company=ACME，location=headquarters,beverage=coffee，walue=40172
3. Prometheus的本地存储
本地存储是在prometheus存储数据的标准方法，因此，我们必须了解它的基础知识。在一个非常高的层次上，Prometheus的存储设计是一个索引实现的组合，它使用了所有当前存储的标签及其值的发布列表，以及它自己的时间序列数据格式
1. 数据流
prometheus 在本地存储收集到的数据的方式可以被看作是一个分为三个部分的过程。下面的主题描述了数据在成功持久化之前所经历的各个阶段。
- 内存
最新鲜的一批数据保存在内存中长达两个小时。这包括在两个小时时间窗口期间收集的一个或多个数据块。这种方法极大地减少了磁盘I/O的消耗;最新的数据存储在内存中，查询速度快得惊人;数据块是在内存中创建的，避免了持续的磁盘写操作。
- 预写日志
而在内存中，数据不是持久的，如果进程非正常终止，数据可能会丢失。为了防止这种情况，磁盘上的write-ahead Iog(WAL)会保持内存数据的状态，以便在prometheus 因任何原因崩溃或重新启动时可以重播它。
- 磁盘
在两个小时的时间窗口之后，块被写入磁盘。这些块是不可变的，即使数据可以删除，它也不是原子操作。相反,tombstone文件是用不再需要的数据信息创建的。
2. 布局
我们在下面的例子中可以看到，Prometheus中数据的存储方式被组织到一系列目录(块)中，这些目录(块)包含了数据块，这些数据的LeveIDB索引就是一个元数据。带有人类可读的关于块的信息的json文件，以及不再需要的数据的tombstone。每个块代表一个数据库。
4. Prometheus数据模型
正如我们到目前为止所看到的，Prometheus将数据存储为时间序列，其中包括称为
- 度量名称 : Metirc names
- 标签键值对
- 数据卷的范围：<datapoint_numerical_value>
下面的主题将对这些组件进行扩展，并提供每个组件的基础知识，我们将在第7章深入使用这些基础知识，即Prometheus查询语言一PromQL，专门用于PromQL。
1. 表示法
Prometheus的时间序列如下:
<metric_name>[{<label_1="value_1">,<label_N="value_N">}] <datapoint_numerical_value>如下案例:
api_http_requests_total{method="PosT",handler="/messages"}如您所见，它表示为一个度量名称，后跟一组或多组花括号内的标签名称/值，然后是度量的值。此外，样本还具有亳秒精度的时间戳。
2. Metirc names
尽管这是一个实现细节，度量名称只不过是一个名为“name”的特殊标签的值。因此，如果您在内部有一个名为“beverages_total”的度量，它被表示为”_name=beverages_total”。请记住，被“"”包围的标签是Prometheus内部的，任何以“__”为前缀的标签只在度量收集周期的某些阶段可用。
标签(键/值)和度量名称的组合定义了时间序列的标识。
Prometheus中的每一个度量名称都必须符合以下正则表达式
"[a-zA-Z_:][a-zA-Z0-9_:]*"3. Metric Labels
标签，或与某个度量相关的键/值对，向度量添加维度。这是普罗米修斯如此擅长对时间序列进行切片和切割的一个重要部分
虽然标签值可以是完整的UTF-8，但标签名称必须与正则表达式匹配才能被认为是有效的;[例如,“-za-z0-9_:]*"
它们在度量名称方面的主要区别是标签名称不允许冒号(:)。
4. Samples
样本是采集的数据点，代表时间序列数据的数值。定义一个示例所需的组件是一个flIoat64值和一个精确到毫秒的时间戳。需要记住的是，不按顺序收集的样本会被普罗米修斯丢弃。同样的情况也发生在具有相同度量单位和不同样本值的样本上.
三、 核心的指标
1. 什么是指标
软件或硬件属性的度量
2. 指标的类型-3种
1. Counter:（累加）统计
- Prometheus 实例接收的数据包总数:（网卡流出总量）
2. Gauge：测量
测量是一种度量，它在收集时对给定的测量进行快照，可以增加或减少
(例如温度、磁盘空间和内存使用量).
如果刮擦失败，您将丢失该样本，因为下一次刮擦可能会遇到不同值(更高/更低)的度量。
为了帮助可视化这种类型的度量，下面是一些基于我们在前一章中创建的测试环境的量规及其图形表示示例:
- Alertmanager实例上建立的TCP连接数量:
- grafana实例上的空闲内存量 一注意由实例重新启动引起的中间空白，防止在此期间对可能的值进行任何假设
3. Histogram：柱状图
在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例:如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。
Histogram常常用于观察，一个Histrogram包含下列值的合并:
- Buckets: 桶是观察的计数器。它应该有个最大值的边界和最小值的边界。它的格式为《basename>_bucket{le=!<bound_value>"
- 观察结果的和，这是所有观察的和。针对它的格式是《basename>_sum
- 观察结果统计，这是在本次观察的和。它的格式为《basename>_count
- 一个普罗米修斯HTTP请求持续时间以秒为单位，分为桶。这是显示在Grafana热图，以更好地说明桶的概念
4. Summaries
与Histogram 类型类似（占百分比），用于表示一段时间内的数据采样结果(通常是请求持续时间或响应大小等)，但它直接存储了分位数(通过客户端计算，然后展示出来)，而不是通过区间来计算。
为了帮助可视化这种类型的度量，下面是一个基于我们在前一章中创建的测试环境的摘要及其图形表示示例:
- 普罗米修斯规则组的最大持续时间(以秒为单位):
四、 指标摘要及聚合
1. 指标的摘要
通常来说，单个指标对我们价值很小，往往需要联合并可视化多个指标(来定位或预判问题)，这其中需要一些数学变换，例如，我们可能会统计函数应用于指标或指标组，一些可能应用常见函数包括:
- 计数 : 计算特定时间间隔内的观察点数。
- 求和 : 将特定时间间隔内所有观察点的值累计相加。
- 平均值 : 提供特定时间间隔内所有值的平均值。
- 中间数 : 数值的几何中点，正好50%的数值位于它前面，而另外50%则位于它后面。
- 百分位数 : 度量占总数特定百分比的观察点的值。
- 标准差 : 显示指标分布中与平均值的标准差，这可以测量出数据集的差异程度。标准差为0表示数据都等于平均值,较高的标准差意味着数据分布的范围很广,
- 变化率 : 显示时间序列中数据之间的变化程度。
2. 指标聚合
除了上述的指标摘要外，你可能经常希望能看到来自多个源的指标的聚合视图，例如所有应用程序服务器的磁盘空间使用情况。指标聚合最典型的样式就是在一张图上显示多个指标，这有助于你识别环境的发展趋势(如图1-7所示)。例如,负载均衡器中的间歇性故障可能导致多个服务器的Web流量下降，这通常比通过查看每个单独的指标更容易发现。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
