VictoriaLogs 是 VictoriaMetrics 团队发布的日志存储系统，声称可以用单节点替代之前 30 个节点的 Elasticsearch 集群，查询速度快，节省 CPU 和内存，具备很高的压缩比，可以大幅节省存储。2024 年 11 月 VictoriaLogs 发布正式版，我们一起来了解一下。
核心摘要
- VictoriaLogs 面向日志存储和日志查询，主打易部署、低资源消耗、高压缩比和快速全文搜索。
- 它可以接收 Vector、Logstash、Fluent Bit、Promtail 等常见日志收集器的数据。
- VictoriaLogs 提供 LogsQL 查询语言、Web UI、Grafana 插件、vlogscli 命令行工具，并兼容一些常见日志分析习惯。
- 当前高可用主要靠双写：日志收集器把数据写入两个或更多 VictoriaLogs 单节点实例，查询侧通过 vmauth 或负载均衡器读副本。
- 本文用本地安装和 rsyslog 示例，演示 VictoriaLogs 如何接收 syslog、如何理解 log stream、日志记录结构和 LogsQL 查询方式。
VictoriaLogs 特性
下面这些能力来自 VictoriaLogs 官方文档特性摘录，也代表它作为日志存储后起之秀的主要卖点：
- 可以接收来自流行日志收集器的日志，比如 Vector、Logstash、Fluent Bit、Promtail 等。
- 与 Elasticsearch 和 Grafana Loki 相比，设置和操作更容易，组件更少。
- 提供简单且强大的查询语言，可以在所有日志字段中进行全文搜索。其检索语法称为 LogsQL，和 Elasticsearch 新提供的 EQL 有点像。
- 提供交互式命令行工具
vlogscli，可以像使用 UNIX 工具一样查询日志。 - 可以与用于日志分析的传统 UNIX 工具结合，例如
grep、less、sort、jq等。很多用户最核心的需求就是分布式检索。 - 在相同硬件上运行时，声称可以处理比 Elasticsearch 和 Grafana Loki 大 30 倍的数据量。
- 对高基数字段提供开箱即用的快速全文搜索，例如
trace_id、user_id和ip这类唯一值很多的字段。 - 支持多租户。
- 支持无序日志摄取，也就是回填。
- 支持选择某条日志前后的上下文日志，类似
grep的-A、-B参数。 - 提供用于查询日志的 Web UI。
- 提供 Grafana 插件用于查询日志。
- 支持警报。
上面可以看出，VictoriaLogs 针对日志场景做了很多考虑：既想降低存储和查询成本，也想让日志排查体验接近命令行工具。
VictoriaLogs 调优
VictoriaLogs 声称默认参数基本就是最优的。默认值会根据可用 CPU 和 RAM 资源自动调整，通常不需要额外调优。操作系统也无需额外调优，只需要把允许打开的文件句柄数量调大即可。
推荐的文件系统是 ext4。推荐的持久存储是 GCP 上基于 HDD 的持久磁盘，因为它自身提供高可用机制，并且可以动态调整大小。如果计划在 ext4 分区上存储超过 1TB 数据，或者计划扩展到超过 16TB，建议将以下选项传递给 mkfs.ext4：
mkfs.ext4 ... -O 64bit,huge_file,extent -T huge
VictoriaLogs 监控
VictoriaLogs 在 http://localhost:9428/metrics 暴露自身监控指标，符合 Prometheus 协议，可以通过 Prometheus 或 vmagent 采集。
VictoriaLogs 也提供了 Grafana 仪表盘 和 Prometheus 告警规则。
VictoriaLogs 会把自己的日志发送到标准输出。故障排查时，建议先查看这些日志。
VictoriaLogs 升级
VictoriaLogs 只有一个二进制文件。只要 changelog 没有额外说明，升级时直接替换二进制即可。
停进程时不要使用 kill -9，建议使用 kill -INT 优雅退出。
VictoriaLogs 日志保留时间
默认情况下，VictoriaLogs 存储时间戳在 [now-7d, now] 范围内的日志条目，同时删除这个范围之外的日志。也就是说，默认保留 7 天。可以使用 -retentionPeriod 命令行参数配置保留时间。该参数接受从 1d（一天）到 100y（100 年）的值。
例如，以下命令启动 VictoriaLogs 并保留 8 周：
/path/to/victoria-logs -retentionPeriod=8w
如果日志时间戳超出配置的保留时间，VictoriaLogs 会在数据摄取阶段自动删除这类日志。删除的日志示例会与 WARN 消息一起记录，便于故障排查。每次因为时间戳超出保留时间而删除摄取日志条目时，vl_rows_dropped_total 指标都会递增。建议设置以下告警规则，以便在引入错误时间戳日志时收到通知：
rate(vl_rows_dropped_total[5m]) > 0
默认情况下，VictoriaLogs 不接受时间戳大于 now+2d 的日志条目，也就是未来 2 天之后的日志。如果需要接受更大未来时间戳的日志，可以通过 -futureRetention 指定“未来保留”。例如，以下命令启动 VictoriaLogs，并接受最多未来一年时间戳的日志：
/path/to/victoria-logs -futureRetention=1y
如果 -storageDataPath 目录中的数据总大小超过给定阈值，可以用 -retention.maxDiskSpaceUsageBytes 命令行参数让 VictoriaLogs 自动删除较旧的每日分区。例如，以下命令启动 VictoriaLogs，如果总存储大小大于 100GiB，就删除旧的每日分区：
/path/to/victoria-logs -retention.maxDiskSpaceUsageBytes=100GiB
VictoriaLogs 通常会把日志压缩 10 倍或更多。这意味着，对于上面的参数，VictoriaLogs 运行时可以存储超过 1TB 的未压缩日志。
VictoriaLogs 至少保留最后两天的数据，以保证查询时可以返回最后一天的日志。因此，如果最近两天的数据大小超过 -retention.maxDiskSpaceUsageBytes，总磁盘空间使用量可能会超过这个阈值。
需要注意，-retentionPeriod 和 -retention.maxDiskSpaceUsageBytes 独立生效。如果设置了 -retention.maxDiskSpaceUsageBytes，但每天数据量较少，通常还会希望尽量保留更长时间的数据，此时可以把 -retentionPeriod 设置为较大值。例如：
/path/to/victoria-logs -retention.maxDiskSpaceUsageBytes=10TiB -retentionPeriod=100y
VictoriaLogs 存储目录
VictoriaLogs 默认把所有数据存储在 victoria-logs-data 目录中。可以通过 -storageDataPath 命令行参数更改目录路径。例如：
/path/to/victoria-logs -storageDataPath=/var/lib/victoria-logs
如果 -storageDataPath 目录不存在，VictoriaLogs 会在第一次运行时自动创建。
VictoriaLogs 高可用
目前 VictoriaLogs 没有提供集群版本，只有单机版本，所以高可用主要靠双写实现。
典型高可用方案由三部分组成：
- 日志收集器：日志收集器需要支持把传入数据复制到多个输出。Fluent Bit、Logstash、Fluentd、Vector 等流行日志收集器已经提供这个能力。
- VictoriaLogs 单节点实例：使用两个或更多实例来实现 HA。
- vmauth 或负载均衡器：从副本之一读取数据，用于平衡和冗余访问。
VictoriaLogs 安装体验
VictoriaLogs 提供多种安装方式。这里使用二进制方式安装，从下面地址下载发布包：
https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.0.0-victorialogs
我的环境是 MacBook M1 芯片，所以下载 victoria-logs-darwin-arm64-v1.0.0-victorialogs.tar.gz。解压后得到一个二进制文件 victoria-logs-prod，直接运行即可。
./victoria-logs-prod -syslog.listenAddr.tcp=:29514
这里加了 -syslog.listenAddr.tcp=:29514 参数，让 VictoriaLogs 监听 29514 端口接收 syslog 数据，方便快速体验。启动 VictoriaLogs 后，可以通过 http://localhost:9428/ 访问 Web UI。
使用 rsyslog 发送日志到 VictoriaLogs
我本地还有一个虚拟机，可以在虚拟机里配置 rsyslog，把日志发送到 VictoriaLogs。在 /etc/rsyslog.d/50-default.conf 最下面加一行：
*.* @@10.211.55.2:29514
重启 rsyslog 服务后，就可以通过 VictoriaLogs UI 查询相关日志：
上面的例子里，查询条件是 *。后面有个 limit 参数，默认是 50。点击查询，很快就可以返回结果。结果分两部分：上面是图表，展示不同时间的日志量，并按 log stream 分成多条线；下面是日志详情。
何为 log stream
log stream 是 VictoriaLogs 中的一个概念，表示一组具有相同标签的日志条目。例如，来自相同应用程序的日志条目可以组成一个 log stream。log stream 可以包含任意数量的日志条目，也可以来自不同标签集。
log stream 的标签和 Prometheus 生态中的标签类似，都是键值对。例如上图中：
app_name="kernel", hostname="ubuntu-linux-22-04-desktop"
这两个标签就是某个 log stream 的标签。它们是 VictoriaLogs 从 syslog 日志流中自动解析出来的。VictoriaLogs 会给 log stream 标签做索引，检索速度很快。
通常，为了提升日志检索速度，查询时应提供尽量细化的筛选条件。最有效的检索条件就是时间范围和 log stream 标签。
日志记录的结构
上图截取了一条日志。大面上看，它包含两部分：日志文本和日志元信息。日志文本是从 [1015282.725324] 到 peer="unconfined" 的那段字符串；日志元信息是 _time、_stream_id、severity 等结构化字段。
实际上，日志文本也是一个特殊字段，叫 _msg。结构化字段中，可以拿来作为 log stream 标识的字段会被单独提取出来，作为 log stream 标签，也就是上面的 app_name 和 hostname。这些标签计算哈希后得到 log stream ID，即 _stream_id。
除了 _msg，_time 是另一个必备特殊字段。对每条日志来说，至少需要时间戳和日志原文。其他字段都是可选的。用户在采集日志时，可以通过 Vector、Logstash 等工具对日志做结构化，并在推送给 VictoriaLogs 时，通过参数告诉 VictoriaLogs 哪个字段作为 _time，哪个字段作为 _msg，哪些字段拼成 log stream 标签，也就是 _stream。
下面以 Vector 为例。Vector 可以把日志发送给 Elasticsearch，而 VictoriaLogs 提供了 Elasticsearch 兼容接口，所以可以让 Vector 把日志发给 VictoriaLogs。
sinks:
vlogs:
inputs:
- your_input
type: elasticsearch
endpoints:
- http://localhost:9428/insert/elasticsearch/
mode: bulk
api_version: v8
healthcheck:
enabled: false
query:
_msg_field: message
_time_field: timestamp
_stream_fields: host,container_name
上面 query 部分中，_msg_field 指定日志原文字段，_time_field 指定时间戳字段，_stream_fields 指定哪些字段作为 log stream 标签。这样配置后，Vector 会把日志发送给 VictoriaLogs，VictoriaLogs 会自动解析日志并提取 _msg、_time、_stream 等字段。
VictoriaLogs 查询语法 LogsQL
VictoriaLogs 查询语法称为 LogsQL。比如最常见的需求：查看最近 5 分钟内的 error 日志。
error AND _time:5m
这里 error 是日志文本中的关键字，_time:5m 是时间范围，表示最近 5 分钟。AND 可以省略，直接写成：
error _time:5m
这个语法很清晰。
该查询可能以任意顺序返回日志，因为对大量日志进行排序可能需要大量 CPU 和 RAM。这样做可以让查询更快返回结果：VictoriaLogs 检索到一条就可以立刻返回到 response 中，不必等待所有日志都检索完再返回。
但有时我们还是希望按时间排序。比如过去 5 分钟的数据不会特别多，这时可以使用 sort 命令：
_time:5m error | sort by (_time) desc
上例使用管道符，对日志结果继续排序。也可以使用 limit 限制返回日志数量：
_time:5m error | sort by (_time) desc | limit 10
这种管道式查询体验和 UNIX 很像，是一个有意思的设计。Elasticsearch 8 开始支持的 EQL 也类似这种方式，大家可能都是从 Splunk 借鉴的。更多 LogsQL 语法可以参考 VictoriaLogs 官方文档，这里不赘述。
FAQ
VictoriaLogs 正式版主要解决什么问题？
它主要解决日志存储和日志查询中的成本、资源占用、全文搜索和易用性问题。原文特别强调它相对 Elasticsearch、Loki 的性能和资源优势，但实际选型仍要以自己的日志规模和查询模式压测为准。
VictoriaLogs 如何实现高可用？
当前主要通过双写实现。日志收集器把数据同时写入两个或多个 VictoriaLogs 单节点实例，查询侧通过 vmauth 或负载均衡器访问副本。
log stream 对查询有什么帮助？
log stream 是一组具有相同标签的日志条目。VictoriaLogs 会给 log stream 标签建索引。查询时提供时间范围和 log stream 标签，可以更快缩小检索范围。
总结
大家苦于 Elasticsearch 的成本和性能问题，社区也出现了 ClickHouse、Doris 等多种日志存储方案。VictoriaLogs 作为挑战者，性能强劲，并且围绕日志场景做了不少专门设计。VictoriaMetrics 在指标存储方面已经做得不错，其团队值得关注。至于 VictoriaLogs 能否替代现有日志系统，还是要回到真实数据规模、查询习惯、采集链路和运维能力上做测试。
