和 VictoriaLogs 尝鲜初体验 极速构建新一代的日志系统 经常使用 Loggie

假设你相熟Prometheus，想必你必需也知道VictoriaMetrics，这款越来越盛行的监控名目，可作为Prometheus的增强或许平替。VictoriaMetrics一个关键的亮点就是处置Prometheus在大规模Metrics目的数据量级下的存储疑问。

同属于可观测性，当咱们把目光聚焦到日志畛域，其实很久以往日志的一个痛点是也是存储。

时下比拟经常出现的一些开源日志存储名目有：Elasticsearch、Clickhouse、Loki等。当然，Elasticsearch和Clickhouse并非天生针对日志存储而设计，咱们只是可以拿来存储日志数据而已。

比如Elasticsearch的外围是一个搜查引擎。针对日志存储的场景，可以全文检索是一大好处，但同时存在以下一些无余：

总体来说，Elasticsearch是一款历史悠久、被宽泛经常使用的日志存储数据库，毕竟当年ELK的概念不得人心。然而，在降本增效的大背景下，很多企业还是会对Elasticsearch占用的机器资源比拟敏感，假设只用于存储少量的运维类日志，性价比还是偏低。

所以前两年Grafana家的Loki横空入世，还是掀起了一点水花的，毕竟日志畛域早就苦Elasticsearch久矣。

繁难引见一下Loki的好处：

大半年前，咱们公司外部有部门开局尝试经常使用Loki存储一些系统日志。但总会遇到一些小疑问，并不是很让人安心。除此之外，Loki的无余之处还有：

当然，Loki还是一个相对年轻的名目，咱们可以了解这些稳固性、性能、设计上的疑问或许是开展早期的阵痛。

然而，貌似很多人曾经等不迭了。

最近VictoriaMetrics颁布了预览版的VictoriaLogs，相似Loki专门用于存储日志。鉴于VictoriaMetrics的良好名声，还是让大家对这条搅局的「鲶鱼」充溢了必定的等候。

VictoriaMetrics为什么要入局搞VictoriaLogs呢？

其实从2020年的这个Issues开局：

VictoriaMetrics就有了研发VictoriaLogs的想法。从该issues的探讨中咱们可以看出，大家对Loki还是有点微辞的，比如说存储依赖S3（本地存储不允许散布式），比如说性能。

这里节选一下issues里的吐槽：

不用翻译了，隔着屏幕咱们都能感遭到这个用户的剧烈不满。

时隔两年多，VictoriaLogs终于正式到来了咱们背地，那VictoriaLogs究竟有哪些好处，又能处置日志存储畛域的哪些疑问呢？

这里我简略总结几点，感兴味的同窗可以在[官网文档]:中寻觅更多答案。

先说VictoriaMetrics家的一大特征：兼容性。VictoriaLogs间接允许了Elasticsearch bulk API，由于市面上简直一切的日志采集Agent都允许发送至Elasticsearch，所以可以基本做到无缝对接和迁徙，无需让这些Agent都去研发参与新的输入源。（这里确实要吐槽一下Loki，连个地下的客户端Client SDK包都没有提供，这让人怎样对接呢）

然而允许横向和纵向扩容，这点由于如今VictoriaLogs预览版只提供了单节点的，临时还无法确认。

另内在资源占用方面，咱们可以间接看 VictoriaLogs提供的[benchmark]:结果。对比Elasticsearch，从下图可以看出：

内存和磁盘占用确实要低太多，基本上是差了一个数量级，假设存储量大的话，能省下不少台主机的钱，无疑是如今降本增效患者的一大福音。

VictoriaLogs雷同引入了log stream的概念，联合多租户的才干，仿佛可以做到日志存储场景下的性能、资源占用权衡下的最优解，这也是VictoriaLogs区别于Elasticsearch等非专门为日志存储设计数据库的外围起因。

所以在经常使用VictoriaLogs之前，请务必先好好了解一下log stream。

log stream是什么呢？

繁难来说，示意运行（服务）的一个日志实例。至于这个日志实例的详细粒度，可以由咱们自行设计和掌控，然而不倡导全体数量特意大。

举例说明，一个日志实例可以为：

log stream设计的关键是可以被惟一标识，这样可以确定日志在散布式系统中发生的位置，比如在哪个节点的哪个容器的哪个日志文件中。

一个log stream由多个label来标识，所以其实这里和Prometheus metrics的label相似，咱们可以拿Prometheus中的一些概念类比：

在VictoriaLogs中也可以自己设计一些相似的label，加在日志采集的元消息中，这样还能用于后续的日志和目的的关联和检索。当然在实践的运行中，咱们还可以参与诸如：环境、数据中心、namespace等的label。

假设你之前了解Loki，必需会想说，Loki不也是这样设计label的吗？

对，然而等你深化用过Loki后，或许会遇到这样的坑：当发送的日志labels里携带了一些频繁修正的字段，比如说一条日志，将其中的偏移量offset字段作为一个label，大略如下所示：

{"message": "xxx","timestamp": "","logconfig": "foo","podname": "bar","offset": 20,...}

Loki会将一切labels的值作为一个惟一的log stream标识，比如上方的内容就会将{logconfig: "foo", "podname":"bar", "offset": 20}作为一个log stream。由于在同一个文件中，offset会随着采集的每行日志都在参与，因此会造成log stream个数有限增长，对Loki形成渺小的压力。

为了规避这类疑问，VictoriaLogs设计上就将stream label和普通label做了辨别，比如以上这种场景，咱们只要要将logconfig和podname作为stream label即可，offset则作为普通的label。

了解了stream label后，咱们就可以更好的了解以下VictoriaLogs中的数据格局：

实在环球：经常使用Loggie采集日志至VictoriaLogs中

上方咱们开局实在的体验一下如何经常使用Loggie和VictoriaLogs极速构建一套日志系统。

可口头以下命令：

helm repo add vmrepo updatehelm install vlsingle vm/victoria-logs-single -nvictoria-logs --create-namespace

更多的概略可参考[helm chart部署]:。

这里咱们设置部署的namespace为victoria-logs，假设修正了该namespace称号，上方的一些性能也请同步修正。

假设你还不知道Loggie，请进[这里]:。

为了繁难起见，咱们在Loggie catalog中提供了一个适配VictoriaLogs的部署性能。

VERSION=v1.4.0helm pull$VERSION/loggie-$VERSION.tgz && tar xvzf loggie-$VERSION.tgz# 从catalog中下载适配victoriaLogs所用的部署性能values文件wget指定该values文件部署Loggiehelm install loggie ./loggie -nloggie --create-namespace -f values.yml

部署完了VictoriaLogs和Loggie后，创立一个测试用的Deployment genfiles用于发生日志。

wgetapply -f deployment.yml

而后创立一个相婚配的日志采集义务，通知Loggie要去采集这个Deployment容器中的日志文件：

wgetapply -f genfiles_logconfig.yml

这里咱们重点关注下genfiles_logconfig.yml中的sink局部性能：

sink: |type: elasticsearchhosts: [ "vlsingle-victoria-logs-single-server.victoria-logs.svc:9428/insert/elasticsearch/" ]parameters:_msg_field: "body"_time_field: "@timestamp"_stream_fields: "logconfig,namespace,podname,containername"

在本示例中，咱们在sink端发送的日志格局大略如下所示：

{"body": "2023-07-04 02:58:18.014 INF cmd/subcmd/genfiles/genfiles.go:57 > 1000 TqrccSCPzRUYRP PJ MlvgdAluEpIoRIRyzjZoNk","containername": "genfiles","namespace": "default","podname": "genfiles-66f5c86fdb-tjpzr","@timestamp": "2023-07-04T02:58:21.905Z","offset": 1092798,"cluster": "test","logconfig": "genfiles","nodename": "kind-control-plane","filename": "/var/lib/kubelet/pods/c7b2da94-b152-414e-a7d8-1951e9d4f09a/volumes/kubernetes.io~empty-dir/logs/loggie.log"}

可以看到，这里将log stream的粒度定为了Pod容器级别，所以_stream_fields设置为了cluster,logconfig,namespace,podname,containername。

如今咱们模拟发生一点日志：

# 进入到genfiles容器中kubectl exec -it $(kubectl get po -l app=genfiles -o jsnotallow="{.items[0].metadata.name}") bash# 发生一点日志./loggie genfiles -totalCount=1000 -lineBytes=1024 -qps=0 \-log.maxBackups=1 -log.maxSize=1000 -log.directory=/tmp/log -log.noColor=true \-log.enableStdout=false -log.enableFile=true -log.timeFormat="2006-01-02 15:04:05.000"

关于loggie生成日志的genfiles子命令，更多的经常使用形式可以参考[这里]:。

反常状况下，Loggie会很快采集这些日志，而后发送至VictoriaLogs。

当然咱们也可以进入Loggie terminal控制台确认一下采集进展：

kubectl -nloggie -it exec $(kubectl -nloggie get po -l app=loggie -o jsnotallow="{.items[0].metadata.name}") -- ./loggie inspect

如上图所示，文件采集进展为100%，示意曾经采集终了，并且发送日志到了VictoriaLogs中。

Loggie terminal详细的操作形式，也可以参考咱们的[日志采集极速排障指南]:。

接上去，咱们就可以经常使用VictoriaLogs内置的UI检查采集的日志了。

由于本地和Kubernetes集群外部网络不通，繁难起见，咱们间接port-forward一下：

export POD_NAME=$(kubectl get pods --namespace victoria-logs -l "app=server" -o jsnotallow="{.items[0].metadata.name}")kubectl --namespace victoria-logs port-forward $POD_NAME 9428

而后本地访问以下页面：[。

VictoriaLogs提供了一个繁难的UI页面，可用于查问日志。为了演示如何查问刚才采集的日志，咱们先极速了解一下查问语法。

思考到最大化查问的性能，倡导普通写LogsQL规范性套路为：

1、确定log stream

_stream这里的过滤字段，就是刚才在sink上parameters._stream_fields性能的，比如查问哪个日志采集义务，哪个Pod等。示例中咱们依据log stream中的logconfig label查问了刚才创立的日志采集义务下的一切日志，LogsQL如下：

_stream:{logcnotallow=genfiles}

假设logconfig婚配了很多的Pod，这里还可以加上对应的podname等字段来进一步过滤。比如：_stream:{logcnotallow=genfiles, podname="genfiles-66f5c86fdb-mrfzc"}。

2、加上期间区间

接着咱们还可以参与期间区间，进一步缩减前往的日志条数。

LogsQL:_stream:{logcnotallow=genfiles} _time:[now-1h,now]

请留意，这里经过空格来距离，另外_stream和_time为内置的字段，无先后顺序辨别。

3、进一步的过滤

上方咱们让Victoria先极速确定一个log stream的日志范围，而后在此基础上，启动关键字婚配，字段过滤等其余复杂的日志检索。

比如：

LogsQL的性能还是比拟多的，更详细的LogsQL经常使用姿态，可以参考[官网文档]:。

只管VictoriaLogs只颁布了一个预览版，然而从的设计和体验来看，还是要优于 Loki 的，毕竟站在了 Loki 的肩膀上，有后发好处。

然而软件设计没有银弹，实在的环球里，能否选用经常使用某个名目，最关键的还是适不适宜，而不在与名目自身性能能否弱小。

可以预料到的是，在很长的一段期间内，Elasticsearch这些老牌们还是会占据大局部的市场，由于在企业中，很多都有曾经常年稳固运转的Elasticsearch或许Clickhouse，同时还有相应的运维人员和配套撑持。

那什么状况适宜VictoriaLogs呢？

假设你们正在从头开局搭建自己的日志系统，情愿接受新事物的潜在危险，对VictoriaLogs的未来充溢信念，那么还是值得一试的。

正是由于VictoriaLogs这些新星们进场，让日志畛域愈加内卷的同时，也让广阔的人民群众受益。毕竟咱们多了一个不错的选用，国际的「开源定制化开发」市场又有更多的活可以干了。