在很短的时间内，Prometheus已成为最受欢迎的监视工具之一。 特别是，感谢其工作的高速化。 它的本地存储非常适合短期存储指标并与它们一起使用。 有时，您希望将指标保持几个月和几年的时间分布，自动删除旧数据，但又不更改使用它们的界面。
与此有关的是Alexey Palazhchenko在RootConf 2018上对报告的解码。在报告中：Prometheus，本地存储TSDB，远程存储Prometheus，PromQL，TSDB，Clickhouse，PromHouse和一些InfluxDB。
谁在乎，请在猫下。
朋友们！ 大家好！ 我叫阿列克谢·帕拉日琴科（Alexey Palazhchenko）。 我在Percona工作。 我想告诉您有关Prometheus中指标的长期存储的信息。
我在Percona工作，制作一个称为percona监视和管理的产品。 这是我们的客户为自己设置的盒装解决方案。 PMM是完全开源的。 它由Prometheus，用于绘图的Grafana，自定义查询分析软件以及我们自己的包装程序组成，该包装程序可让您进行一些管理。 例如，您可以将刮擦目标添加到Prometheus。 这些是他从中获取指标的新资源，而无需手动输入容器或虚拟机并编辑配置文件。
重要的是要了解这些不是SaaS。 我们没有生产。 我们的产品位于我们的客户手中。 做实验不是很好。 我们有一个可以称为生产的最接近的东西-这是https://pmmdemo.percona.com/ 。 在撰写报告时，由于GDPR的缘故，必须关闭pmmdemo.percona.com。
我们向客户交付PMM —盒装解决方案：泊坞窗容器或虚拟机。 他们都喜欢普罗米修斯。 一些第一次看普罗米修斯的人遇到了拉模型。 对于初学者来说，这很不方便。 通常是一个单独的大型对话。 您可以争论拉或推方法。 平均而言，这是同一回事。
普罗米修斯的一些东西很酷。
Prometheus客户喜欢它。 他们想保持指标越来越长。 有人将Prometheus仅用于操作监视。 但是有人想要保持指标更长，观察动态并与一年前的图表进行比较。 同时，长期存储指标的目标不是Prometheus项目的目标。 最初，它是为了在短时间内存储指标而创建的。 SoundCloud可以在短短几天内存储指标。 普罗米修斯（Prometheus）中有一些机制可以使您执行此操作的时间更长，但它们的排列稍微偏于侧面。 因此，我们可以为Prometheus生态系统做出决策，而无需更改系统本身的核心。 基于它们，我们可以在同一个生态系统中做出自己的决定。
这不是有关现成解决方案的报告。 这是关于我们的经历，痛苦，尝试的报告。 如果您希望在此报告后下载存储库或Docker容器，然后运行它即可运行，那么事实并非如此。 但是同时它已经足够接近了。 我们有一些基础。 它们都是开源的。 你可以试试看。 他们还没有准备好生产。 但是利用此报告中的信息，您可以了解原因，因此可以做得更好。 您可以做出适合自己的决定。
指标如何存储在Prometheus中？ 有本地存储。 有远程存储。 这实际上是两个不同的世界。 它们相交较弱。 因此，报告也分为两个部分。
如果您在正厅的上一个报告中（Prometheus的介绍很不错），您会知道本地存储是一个单独的库，称为TSDB。 TSDB与OpenTSDB无关。 TSDB是一个单独的Go软件包，您可以从Go程序中使用它。 在TSDB库级别，没有客户端或服务器。
该库针对使用时间序列数据进行了优化。 例如，TSDB具有增量编码，它允许您不存储数字本身，而是存储这些数字之间的更改。 这使您可以存储1个字节而不是16个字节。 时间为1个字节，值为1个字节。 也就是说，由于这种良好的压缩，您平均平均要存储1或2个字节。
TSDB针对拉模型进行了优化。 数据仅添加到此处。 Prometheus无法写入历史数据。 没有为此的API。 最大增量约为5分钟。 如果数据较旧，将不被接受。
TSDB中没有内置的降采样tsdb＃313 。 有一个公开的问题，其中讨论了这样一个事实，即总的来说，有些项目在做普罗米修斯的事情，而那里的采样率较低。 到目前为止，解决方案是TSDB将不会添加下采样。
我们如何从TSDB获取数据？ TSDB是磁盘上的数据库。 如果您正在编写Go程序，则可以使用它。 但是，如果您不使用Go编写程序，则可以使用JSON API进行查询。 如果您曾经使用过Prometheus，并且至少一次构建了图表，那么您就会知道标准的Query API，其中有一个查询参数，您可以在其中执行任何PromQL查询并选择执行时间。 如果没有时间，则采用当前时间。
幻灯片上突出显示了一个特定的查询，您在现实生活中很少看到该查询。 这是一个hack。 这使我们能够提取Prometheus的所有指标。 如何运作？ 在PromQL级别上，据说不可能编写出能够吸引所有时间序列的表达式。 这直接写在规则中。 另一个规则说，您不能使所有值都为空的匹配器。 如果您只写括号，这将不起作用。 如果您写的名字不等于任何东西（不是空值），那么它将不起作用。 但这是一个真正的技巧，可让您执行此操作。 但是，它甚至没有特别记录。 在代码本身中有此功能的注释。
第二个查询是query_range，它执行相同的操作，但返回具有一定范围的步骤中的数据。 从本质上讲，它从头到尾对每个步骤进行多次查询。 这是用于绘制图形的API。 第一个API用于获取即时值。
我们有一个用于检索元数据的API。 如果要获取度量的所有名称，请进行如下查询，其中match是度量数组。 可能有几个参数，但是在这种情况下，我们传递相同的匹配项，一切都返回给我们。
第二个meta API，它返回所有标签的值。 如果我们要查看所有作业的列表，而不是label_name，我们可以编写作业并获取此列表。 这些API向我们返回JSON。
还有另一个API以出口商固有的格式返回Prometheus本身的所有指标。 该格式称为expfmt。 在Prometheus本身中，有一个联合身份验证API，使您可以发出这样的请求。 这是为了什么 最简单的选择是，如果您已经有一些可与expfmt一起使用的代码，则无需重新培训它即可与某些自定义JSON API一起使用。 这种格式更容易流式传输，因为如果在对象的顶层某个位置有JSON，则通常需要将这个对象作为一个整体进行解析。 在这里可以逐行完成。
最重要的是，它是一个单独的API。 它的工作方式就像真实的出口一样。 您可以采用其他Prometheus进行刮擦。 这是具有常规参数的常规工作。 您需要传递参数-查询网址。 如果您发出卷曲请求，您将在此处获得相同的请求。 我们获取当前时间值的所有指标。 唯一的警告：您必须设置honor_labels，以使将通过此API刮除另一个Prometheus的Prometheus不会擦拭作业和实例标签的值。 使用此联合身份验证API，您可以将所有数据从一个Prometheus加载到另一个。
如何使用？
首先，要说的最重要的是您不需要这样做。 TSDB针对不同的操作模式进行了优化。 如果您的Prometheus会抓取大量数据，那么它将执行很多I / O。 如果使用联合身份验证API，则输入输出量将增加大约2倍。 有细微差别。 取决于您刮刮联邦的频率和刮刮目标的频率。 如果时间没有更改，那么这实际上会使负载加倍。 因此，如果您想扩展Prometheus并启用联盟，则将其杀死。 负载将增加一倍。
第二刻 您将跳过数据。 您将获得数据冲突。 为什么这样 与Prometheus中的几乎所有API一样，该API也不是原子的。 如果有新数据到达，则在您的联邦请求仍在进行时，新的抓取将终止，您可以在一个时间序列中获得一个数据，而在另一个时间序列中获得新数据。 如果这是一个不相关的时间序列，那么通常并不可怕。 但是，如果您有一个摘要或直方图，它们在expfmt级别上由几个基本指标表示，则它们之间将存在不一致之处。
我们如何解决这个原子问题？ Prometheus具有记录规则，可让您根据现有时间序列创建新的时间序列。 这可以不那么频繁地完成。 这是进行下采样的一种方法。 例如，每秒废弃一次目标，但是接下来我们要在一分钟内进行node_cpu聚合。 通过Prometheus 2.0中的分组，您可以按顺序进行这些聚合。 同一组中的规则严格按顺序执行。 至此，没有原子性问题，也没有数据在过程中发生变化的问题。 但是，这并不能解决以下事实：与之逻辑相关的其他一些数据是可以接受的，但从数据模型的角度来看，这些数据是不相关的。 还没有纯原子性。 关于此主题有一个未解决的问题。 您可以制作快照。 您可以对TSDB数据库进行PromQL查询，并从获得的值中删除所有小于评估开始时间的值的样本。 这将是最简单的方法，但到目前为止尚未完成。
重要的是要了解，记录规则需要在较低的Prometheus上完成，而不是在联邦所做的工作上完成。 否则，您将跳过峰，监控将无法正常工作。
我们如何使用这些东西的组合来进行下采样和长期存储。
第一个。 我们只是建立联盟并从Prometheus下载所有数据。 这个奇怪的正则表达式就像一个zoidberg-实际上只是一个冒号。 冒号左右的星号。 我们使用标准名称作为记录规则，在中间添加一个冒号。 划分原始名称时，左侧将有一个聚合级别，而在右侧将有一个功能。 正常的结肠度量标准则不然。 如果存在冒号，则表明这是聚合。 之后，我们在图形中使用该指标名称。 如果我们希望我们的日程安排，我们的grafana仪表板可以与主要的Prometheus一起使用，对于更高级别的人，我们可以使用或表达式。 我们采用一个度量或另一个度量，具体取决于哪个度量。 我们可以作弊并使用重新标记将新指标重命名为旧名称。 这是一种相当危险的方法。 您可能会错误地拼写常规附件，并且会有时间序列冲突。 Prometheus将向日志写入许多警告。 您将看到这一点，但是找到原因可能非常困难。 但是，如果仔细地进行操作（例如，以编程方式生成这些正则表达式），那么它将起作用。 接下来，您将有一个常规的仪表板，其中仅使用node_cpu。 根据所使用的Prometheus，您将收到原始数据或汇总数据。
如我所说，可以很简单地生成记录规则。 我们只是通过我已经显示的API获得了所有时间序列。 我们创建规则，并且这些规则必须使用正确的函数和运算符。 无需在那里使用带有量规的速率。 这将无法正常工作。 仅应与count一起使用。 在您所在的级别，您可能没有有关数据类型的信息。 例如，如果您使用expfmt。 有关于类型的信息。 如果不存在JSON API。 因此，您自动生成的表达式可能没有任何物理意义。 因此，您可以在其中使用白名单或黑名单。 依赖于此，要么生成您需要的规则，要么丢弃那些没有意义的规则。 有一个promtool工具，可让您检查生成的规则和生成的配置是否合理。 它具有正确的语法。
如果我们有Grafana，并且有多个Prometheus，则需要知道将请求发送到哪个Prometheus。 我们将如何做？
一种方法是放置一个特殊的代理，该代理将查看请求中的时间，并根据此选择Prometheus。 查询具有开始时间和结束时间。 取决于此，您可以用手进行布线。 可以编写某种程序来执行此操作。 实际上，这是通过nginx使用lua模块或一个小程序来完成的。
我们真的需要一个API吗？ 我们可以直接与TSDB合作吗？ 有细微差别。 首先，如果我们尝试使用Prometheus现在使用的TSDB，我们将无法做到这一点。 有一个特殊的锁定文件可以防止这种情况。 如果我们编写将忽略此代码的代码并尝试读取或写入数据，则一定会损坏它们。 而且，甚至阅读。 该怎么办？ 我们可以通过API读取数据并并排创建TSDB。 然后停止Prometheus，并将其替换为TSDB。 但是同时，如果我们通过API读取所有数据，则会浪费性能。 我待会儿再谈。
第二种选择。 您可以复制（进行热备份）这些文件，即按原样复制。 是的，它们将被损坏。 打开时，您将收到一条警告，指出数据已损坏。 它们需要修复。 您可能会丢失新数据。 但这对我们来说并不重要。 我们希望对旧数据进行下采样。 可以使用PromQL进行下采样。 但是有细微差别。 从普罗米修斯那里撕下它比TSDB要困难得多。 如果您对Go和依赖项管理有点熟悉，那么供应商PromQL会很痛苦。 我不会建议你。 尽可能避免这种情况。
我们传递到远程存储。 有人在Prometheus中使用过远程存储吗？ 几只手。 远程存储是已经存在很长时间的API。 现在在2.2版远程存储中-标记为实验性。 此外，众所周知，远程存储API肯定会发生变化。
远程存储仅允许您处理原始数据。 输入或输出处没有PromQL。 阅读时，您将无法使用PromQL的全部功能。 实际上，它会从远程存储中抽出符合条件的所有数据。 进一步的PromQL已经与他们合作。 这有很大的开销。 您需要通过网络泵送大量数据。 因此，在尚未发布但已被延迟的Prometheus 2.3中，将显示读取提示。 我们稍后再讨论。
尚无用于元数据的API。 您无法创建从远程存储返回所有时间序列的API。 如果您向Prometheus API提出请求，则该请求不会转到“远程存储”。 它将返回时间序列，该时间序列位于其本地数据库中。 如果您的本地数据库被禁用，它将返回0。这可能有点意外。 现在，该API使用ProtoBuf，将来肯定会更改为gRPC。 他们尚未完成此操作，因为gRPC需要HTTP2。 实际上，他们对他有问题。
写API如下所示。 该请求具有一组标签。 标签集只是唯一地标识时间序列。 __name__实际上只是带有特殊名称的标签。 样本是一组时间和值-int64和float64。 录制时，顺序并不重要。 假定将其写入自身的数据库将正确执行所有操作。 Prometheus可能会进行一些优化，而不是对其进行重新排序。 因此，写请求只是几个时间序列。
写配置具有相当灵活的配置。 有许多用于配置写并发的选项。 普罗米修斯所说的碎片本质上是竞争要求。 您可以限制一个请求中的最大样本数，并行请求的最大数，超时，如何重复以及哪个退避。 对于许多数据库，一次只能处理100个样本-这可能非常小。 如果您像我们一样使用ClickHouse，则当然需要大大提高其价值。 否则，它将是非常低效的。
远程读取API如下所示。 这只是一个从开始到结束的时间范围，也是比赛的开始。
Match本质上是名称和值对的集合-常规标签和条件类型。 相比之下，存在等式，不等式或正则表达式。 这是您在PromQL中看到的常用时间序列选择器。 这里没有功能。
答案是一些与此查询匹配的时间序列。 在这里，样品应按时间排序。 再次，这可以帮助Prometheus节省一点CPU-无需排序。 但是假定您的数据库应该这样做。 在大多数情况下，情况会如此，因为很可能会按时编制索引。
Prometheus 2.3引入了阅读提示。 这是什么 这是一个告诉Prometheus的机会，它将应用与所请求的时间序列配合使用的内部函数。 这可以是函数或聚合运算符。 这可能是率。 也就是说，它称为func，但实际上它可以是求和的，从PromQL的角度来看，它实际上根本不是一个函数。 这是操作员。 和一步。 在前面的示例中，速率为1分钟。 速率是一个函数，以毫秒为单位，以分钟为单位。 远程数据库可以忽略此提示。 同时，答案中没有指示是否忽略它。
read的配置是什么？
首先，有这样的配置required_matchers。 这使您可以发送与表达式匹配的远程存储请求。 要从远程存储中读取聚合的数据，必须使用包含冒号的查询。
有一个选项允许您从TSDB的远程存储中读取或不读取最新数据。 通常，在标准配置中，有一个小的本地TSDB被写入本地磁盘。 她在那里存放了几个小时或几天。 您现在使用的用于警报的数据（用于构建仪表板）仅从本地TSDB中读取。 它速度很快，但是不允许我们存储大量数据。
旧的历史数据将从远程存储中读取。 这清楚表明本地存储和远程存储如何相互通信。 没有重复数据删除。
本质上是发生了什么。 如果启用了read_recent，则数据是从本地存储中获取的，数据是从远程存储中获取的。 他们只是合并在一起。 看来这不是问题。 如果假设我们没有对最近的数据进行下采样，那么它们是完全相同的数据，它们与本地数据完全一致，那么我们将拥有两倍的采样数，我们不应该影响任何功能。 不完全是 有一个irate（）函数和一个用于量规的对，它向我们返回最后两个值之间的差。 她回头看了指示的时间范围，但仅使用最后两个值。 如果我们使最后两个值具有相同的时间，则差将为零。 这是一个错误，几乎不可能找到它。 它是在四天前修复的。 这是有兴趣的人的门票 。
有趣的是，自1.8版以来，Prometheus已实现了远程读取。 这样，您便可以在迁移到2.x版时读取旧的Prometheus的数据。 官方方式建议将其连接为远程读取。 数据将根据需要减去。
远程读取可用于在没有代理的情况下进行查询路由。 在上一张幻灯片中，我显示了可以根据时间在一个Prometheus或另一个Prometheus上进行路由。 同样，我们可以避免这种情况。 只需插入下面的Prometheus（可远程读取）即可从那里读取数据。 但是对以下事实进行了修正：当然，将抽取大量数据。 特别是如果您不使用查询提示。
为什么要点击房子？
对于我们的研究解决方案，我们选择了ClickHouse，因为我们已经研究了很长时间。 我们拥有不断致力于数据库性能，不断检查新数据库的人员。 我们公司从事开源数据库。
我们真的很喜欢它的原始性能。 它在CPU，时间等方面的功能非常出色。 这些系统中的大多数都谈论无限的可伸缩性，但是很少谈论单个服务器的效率。 我们的许多客户都将指标存储在一对服务器上。
内置复制，分片。
GraphiteMergeTree是用于存储石墨数据的特殊引擎。 起初他对我们很感兴趣。
该引擎旨在汇总（精简和汇总/平均）石墨数据。
Graphite将完整数据存储在ClickHouse中，并且可以接收它，并且进一步说，通过细化，使用GraphiteMergeTree，而无需细化就使用MergeTree。 感觉是数据始终是完整的，不会被覆盖，只是对读取的优化。 但是总体来说还不错。 当我们进行读取时，我们不会抽出数据，它们会自动聚合，我们会得到一些数据-这很好。 我们的缺点是所有数据都已存储。
我在月初准备报告。 有人在电报聊天中问：“ GraphiteMergeTree数据降采样”？ 我已经写了 该文件说不。 但是聊天中的另一个人回答“是的，您需要调用优化”。 运行，检查-是的。 该文档本质上是一个错误。 然后我阅读了源代码，检查了一下，结果发现有优化，最终优化。 Optimize final最初是专门为GraphiteMergeTree创建的。 实际上，他确实降低了采样率。 但是必须用手来调用它。
GraphiteMergeTree具有不同的数据模型。 他没有标签。 以指标的名义有效地编写所有内容的效果并不理想。
名称指标存储在一个表中。 度量标准的名称具有不同的长度。 这导致以下事实：如果我们按度量名称进行索引搜索，则由于长度不同，因此该索引的有效性不如该索引具有固定的长度值。 因为您需要进行文件搜索。 无法确切指定进行二进制搜索的位置。
因此，他们制定了自己的方案。 幻灯片显示了我们如何在数据库中存储时间序列。 ClickHouse需要的日期是指纹。 如果您查看了Prometheus或TSDB的来源，那么您就会知道指纹本质上是全名时间序列的简短快速校验和。 指纹是所有标签，键和值的组合。 名称是常规标签。 为了兼容性，我们使用相同的算法。 借记可以很方便。 指纹是相同的，可以在TSDB和我们的存储中检查它们是否相同。 标签存储在特殊的JSON中，允许ClickHouse通过其标准功能使用它。 这是紧凑的JSON，没有空格，命名略有简化。 运行期间不使用该表。 它始终存储在我们实际解决方案的内存中，即PromHouse。 仅在启动服务器以了解时间序列时才使用它。 她被减去。 当新的时间序列到来时，我们将它们记录在那里。 所有多个PromHouse实例都可以读取同一张表。 ReplacecingMergeTree告诉我们这些时间序列（有多个不同的实例）编写相同的时间序列。 他们会竞争-这里不会有问题。
我们非常有效地将样本存储在单独的表中。 对于固定长度值，此指纹是相同的，时间和值。 每个样本获得24个字节。 它具有严格固定的长度。 每列分别存储。 指纹搜索是有效的，因为我们知道大小是固定的。 当它是一个字符串时，没有GraphitmergeTree这样的问题。 我们使用自定义分区。 主指纹索引和时间。
24字节是简化版本。 实际上，它压缩得很好。 实际上占用的空间更少。 在我们最新的测试中，压缩比约为1到42。
如果我们有GraphiteMergeTree，但如何与我们想要的不一样，我们如何进行手动下采样。 实际上，我们可以手工完成。 如之前所做的分片，分区一样，没有内置任何内容。 我们用手做一张新桌子。 当有时间样本到我们时，我们将确定要写入的表。
我们从查询中选择要读取哪个表的时间。 如果阅读发生在边境，我们将阅读几张桌子。 接下来，我们保存此数据。 一个人可以为此使用视图。 例如，为几个表创建一个视图，使它可以在单个查询中读取。 但是ClickHouse中存在一个错误：视图中的谓词未替换到查询中。 因此，如果您在视图中发出请求，那么它将转到所有表。 查看我们无法使用。
我们如何进行下采样？ 我们创建一个临时表。 使用正确的功能将插入片段复制到其中的选择数据中。
我们进行重命名，这在全局锁下是原子的。 我们正在将现有表重命名为旧表。 现有的新手。 我们放下旧桌子。 我们有148天的数据已经过采样。 这是什么问题？ 插入看起来很漂亮。 实际上，我们需要应用正确的功能，正确的汇总来做。 在实践中，这不可能有一个大的要求。 甚至不能提出几个大的请求。 这必须通过代码来完成。 该代码发送大量的小请求。 我们尽最大的努力做到这一点，但这并不是很有效。 到目前为止，从一天开始对数据进行下采样不到一天。 根据数据量，可能需要很长时间。
ClickHouse将进行更新/删除。 删除已经有了第一个版本。 如果更新/删除有效，则可以简化我们的下采样数据方案。
其次，ClickHouse的任务是进行自定义压缩（增量，增量到增量）。 TSDB就是这样做的。 这非常适合时间序列数据。 如果我们能够根据数据类型选择压缩类型，则这特别有用。 例如，计数器只是在增长-为此，delta-delta压缩是合适的。 量表围绕幅度波动，因此增量效果很好。
还有其他可以使用的存储。 开箱即用的InfluxDB。 习惯责骂他提高速度，但是开箱即用的方法是有用的，而您无需执行任何操作。
有OpenTSDB和Graphite，它们是只写的。 Prometheus的标准适配器不能真正起作用。
有一个CrateDB。 有一个TimescaleDB，它可以将PostgreSQL用于时间序列数据库。 他们说它很好用，但是我们自己还没有尝试过。
有Cortex，也被称为科学怪人计划。 这很好地描述了他。 这是试图基于普罗米修斯联邦做出决定的家伙。 他们将数据存储在S3中。
有塔诺斯人。
- 他有一个非常有趣的体系结构。 有Prometheus使用本地TSDB。 在它们之间创建一个集群。 每个Prometheus旁边都有一个特殊的侧面车，它可以通过远程读取和远程写入API接受请求。 他将这些请求重定向到Prometheus。 Prometheus可以使用其远程读取和远程写入API。 所有副车都相互连接，并且通过gRPC在自定义API主站之间互连，可以进行复制，并且需要重新着色。
- 复杂的架构。
- 好潮湿 几个月前，它开始时还差一点点。
使用拉模型不会写入太多数据。 您需要等待整整一年才能填写年度数据。 我们正在尝试以某种方式将其写入此处。
Prometheus中没有远程写入，因此，无法将大量数据写入本地TSDB。
第二个问题。 如果我们生成用于压力测试的数据，那么它们通常会表现得很好。 例如，如果我们采用现有数据并生成100个实例，而这些实例是相同的数据，则压缩系数将非常漂亮，以至于实际上它们不会发生。
我们写了一个伪造的出口商，看起来像普罗米修斯可以放在一起的常规出口商：
- 当废料进来时，他去了一些上游出口商。 从中获取数据。
- 生成许多实例。 假设1是痒痒痒的东西，我们得到100。
- 略微更改数据：计数器和量具的正负10％。
- 它不会更改简单值0或1。因为如果有一个UP度量标准响应，它将显示服务是否正在运行：是-1或否-0。而且098 UP的含义还不是很清楚。
- 我们不会将整数更改为实数，反之亦然。
- 它只是以通常的expfmt格式提供数据。
加载数据的Promload工具。 读取数据：
- 可以读取自己格式的文件
- 也许从远程阅读
- 可以从某些出口商处读取
以不同的格式写入。 如果我们想精确测试读取的工作速度，请在/ dev / null中添加。
现在，它不仅是PromHouse的负载测试工具，而且是使用远程读取或Prometheus的任何解决方案的负载测试工具。
我们希望添加读取缓存，因为在我们的测试中，瓶颈通常是虚假的导出程序，该程序长时间生成数据。 我们可以缓存它们。 让他们变得虚幻的好。 但是我们不会放慢脚步。 我们不必等待几天就可以进行压力测试。
即时进行某种过滤，即时进行某种修改。
对TSDB的本机支持。 为了在磁盘上使用数据库，而不是通过API。
专注于迁移的准确性。 我曾经把pmmdemo.percona.com放在：已连接，接收了所有指标。 如果您以本机方式执行此操作，则Prometheus将打开TSDB，从磁盘中引发所有时间序列，引发索引，然后爬入块文件中，意识到它们确实存在。 此时，一切都可以躺下来。
天真的方法是采用整个时间序列，并从旧数据读取到新数据。 那一刻他将躺下。 您需要做相反的事情。 首先，您需要使用一些带有正则表达式的查询来获取时间序列列表。 例如，一个时间序列从A开始。然后给我一个时间序列，从B开始。然后按指标而不是按时间准确地加载它们。 这是不合逻辑的，但是它是这样工作的。 如果您做这样的事情，这是一个细微的差别。 如果您看到OOM Killer在那里发生过，那么您将知道那是因为您。
负载测试的结果，将没有图形。 负载测试需要花费大量时间，而且不幸的是，由于配置错误，一切都出错了。 因此，结果无法解决。
进行负载测试时，我们将在Percona博客上发表文章。
我可以说没有图形的结果。 记录是线性的。 阅读跳得并不快。 读取当前数据对我们来说不是很重要。 通过阅读提示可以加快它们的速度。 您可以启用read_recent来改善阅读。 对于旧数据，这很好用。
人们想要长期存储。 有这样的需求。 我们在PromCon上谈论了PromHouse。 那里是一个非常热门的话题。 Thanos正在积极发展。
现在已经可以了。 有一个解决方案。 有一个API。 有一些集成。 但是所有这些都需要用一个文件来完成。 没有生产就绪的解决方案。
链接在哪里看。 第一个链接是PromHouse存储库。 第二个环节是他可能会移动的地方。 现在在一个存储库中有几件不同的事情？ 不是很密切的关系。 因此，您将需要转移它们。
我们的博客将包含有关性能和一些新闻的信息。
问题：
问题：您是否检查了有关InfluxDB的传言？
答：他不是很好。 他变得好多了。 所有这些有关InfluxDB运行缓慢，崩溃的事实-它们都是关于旧版本的。 当前版本是稳定的。 我不会说吗？ 它工作很快。 但是它运行稳定。 我认为InfluxDB的优点：
- 首先，由于InfluxDB开箱即用，因此无需在附近做任何事情。
- 其次，与其他基于数据库的解决方案一样，在ClickHouse中，但在TSDB中，您可以使用您更熟悉的查询语言。 InfluxDB查询语言类似于SQL。 您可以对此进行分析，而这在PromQL上很难完成。 如果您使用TimeScaleDB-有真正的SQL。
问题：GraphiteMergeTree引擎仅用于记录工作吗？ 如果要显示图形，是否需要在Graphite上设置Grafana才能显示长期存储？
答：可以。 Prometheus本身的集成仅适用于录制。 他只写数据。 因此，从Grafana前往石墨。
问题：他在写作时会丢失标签吗？
答案：有一个配置说明如何处理它们，如何插入它们，在何处插入它们。
听众的信息：Avito说他们正在编写从Prometheus到Graphite的录音解决方案。
问题：有一个结论是，在长期存储服务器上记录一切都很好。
(5- 15-). raid 6 sata ?
: PMM — . downsampling c 14 1 . , . . . .
: IOPS ?
: .
:
: . , . , , .
: InfluxDB, InfluxDB?
: read_recent. , remote storage. InfluxDB . . read_recent , .
: , Prometheus. InfluxDB. Grafana Prometheus. Prometheus PromQL , InfluxDB?
: .
: Prometheus InfluxDB Grafana?
: . Prometheus 2.2 , .
PS : valyala gecube
, .