posts/vmagent-data-structures/

[giscus[bot]]

posts/vmagent-data-structures/

Medium This blog post is also available in English: Persistent Data Structures in VictoriaMetrics (Part 1): vmagent Series Introduction VictoriaMetrics 是一个开源的高性能时序数据库，作为 Prometheus 及其长期存储方案（如：Thanos、Cortex）的平替，有很多

https://jiekun.dev/posts/vmagent-data-structures/

[grzhan]

在读 vmagent 文档与这部分源码有一点是命令行参数 -remoteWrite.queues 事实上对应的似乎是每个 Remote Writer 配置 worker 的数量，而不是 fast queue 的，而 fast queue 确实是每个 Remote Writer 配置（ctx）一个。我一开始以为是 fast queue 有这么多。

https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/app/vmagent/remotewrite/remotewrite.go#L816

[grzhan]

另外补充一下，vmagent 目前的实现似乎不管 Remote Write 端是什么协议都会基于 Protobuf 协议进行序列化，我想这主要也是为了 Promenade 的 Remote Write API 协议兼容，而且 Protobuf 性能似乎也还可以（vmagent 序列化这部分代码写得很好，有不少优化技巧值得学习）。

此外，按照 vmagent 目前的源码实现，persistent-queue 下每个 Remote Write 配置对应的目录中可能不止三个文件，因为数据文件（chunkfile）事实上是可能会有多个的，文章里数据文件的命名 "0000000000000000" ，代表的是这个数据文件存的 bytes 的起始 offset， offset 在 vmagent 是个 uint64 的数，所以文件名也是 16 位的十六进制数，当 vmagent 运行时，如果写入时数据文件的大小超过约 512MB，就会另外创建一个新的数据文件，并以这个文件起始 byte offset 的 16 位十六进制数命名。

persistent-queue 在磁盘读写时主要正是基于 metainfo 的 writer offset 与 reader offset ， writer 在前头顺序写 bytes ， reader 在后头顺序读 bytes，当写文件发现文件大小要超了，就创建个新文件继续写。当 reader 读文件发现读到头了（reader offset == writer offset），vmagent 就会清理重置这些文件。

整体 vmagent 特别是 persistent queue 的部分相对于很多知名消息队列而言并不复杂（buffered io 顺序读写），但整体实现得很老练，有很多并发控制以及性能优化的技巧在里面，而 VictoriaMetrics 本身有关技术内容就更丰富，值得多加讨论和学习

[grzhan]

Promenade -> Prometheus
Protobuf 序列化代码：https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/app/vmagent/remotewrite/pendingseries.go#L236
创建 offset chunkfile 代码： https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/lib/persistentqueue/persistentqueue.go#L424

[kbsonlong]

由于第一个Remote Writer 需要下线,并且使用的是Kubernetes集群内部 Service 域名，将第一个Remote Writer 配置移除后发现指标查不到了是什么原因？把配置恢复回去又可以查询，但是日志一直提示第一个Remote Writer 不可连接。大佬能解答一下是什么原因么？

[jiekun]

最好可以贴出具体的日志哈