又来一个挑战 Elastic 的，初识 SigLens

Elastic Stack 在日志领域具备无与伦比的地位，各类新兴的开源项目都声称比 Elastic 更节省资源，同时检索速度也不慢，比如 ClickHouse、Loki、OpenObserve、VMLogs，今天我们来看看另一个项目：SigLens。

SigLens 的官网是：https://www.siglens.com/，其在官网声称了几点选择 SigLens 的理由：

高效扩展：在一台 8 核机器上可以处理 8TB/day 的数据，在 800 核的集群上可以处理 1PB/day 的数据。
全文检索：可以在任意字段上做全文检索，支持通配符和正则表达式。看起来不是类似 ElasticSearch 的倒排索引的实现。
在查询时提取字段：在查询的时候从现有的日志中提取数据作为新字段，新字段可以参与后续的 Pipeline query 过程。
快速的数据摄入：创新的微索引功能使您能够以闪电般的速度进行索引。“微索引”是 SigLens 的一个重要概念。
查询兼容性：支持多种查询语言，包括 Splunk QL、Elastic DSL、SQL、Loki LogQL。这点好，尤其是 Splunk QL 和 SQL 的支持。
支持接入多种数据格式：支持对接各类日志采集器，即 SigLens 不做采集只做存储，支持包括 OpenTelemetry、Fluentd、Fluent Bit、Logstash、Vector、Splunk HEC、Promtail、S3/SQS/SNS 等等。
快速安装：提供 git 编译安装、Docker、Helm 等多种方式，我测试过 git 编译安装了，确实很方便。
架构简单：开源版貌似只支持单机版，当然，人家单机版已经声称非常牛逼，一台 SigLens 就抵得上几十台 ElasticSearch。
统一查看面板：SigLens 不止做底层存储，还做上层 Metrics、Logs、Traces 的统一查看面板。野心挺大哦。

SigLens 对比 ElasticSearch

ElasticSearch 是倒排索引，实际存储量是来源数据的 110% 左右，SigLens 采用微索引技术，存储只需要 1% 哦
ElasticSearch 通常需要集群才能搞定大数据量，SigLens 单机就可以搞定
ElasticSearch 的查询速度慢，尤其是那种非结构化字段的查询聚合，而 SigLens 的查询、过滤、聚合是 ElasticSearch 的 1025 倍
由于一些节点重启，ElasticSearch 集群动不动就变成 Yellow 状态，有时甚至会变成 Red 状态，SigLens 架构简单，通常没有这些乱七八糟的问题

总之，SigLens 号称自己比 ElasticSearch 牛逼多了。

SigLens 对比 ClickHouse

ClickHouse 需要预先定义 Engine 才能较好压缩数据，比如使用 MergeTree 引擎，Siglens 采用动态列压缩，零配置
ClickHouse 需要预先定义物化视图来提升聚合查询性能，SigLens 采用 AgileAggsTree，零配置也可以做到快速聚合查询
由于上面提到的各种预定义需求，ClickHouse 运维负担较重，而 SigLens 都是动态零配置，哼哼
ClickHouse 写入数据需要攒批，否则性能会很差，但是这不符合真正的日志场景，日志就是连续输入的，SigLens 支持连续输入
ClickHouse 不支持查询时提取字段，SigLens 支持

总之，SigLens 号称自己比 ClickHouse 牛逼多了。

SigLens 对比 Loki

Loki 只索引日志的元数据，SigLens 索引所有字段
Loki 查询慢，动不动需要几分钟，SigLens 是亚秒级响应（这吹得有点过了，笔者都看不下去了）
Loki 使用 S3 作为存储，查询时需要高昂的带宽成本，SigLens 微索引是本地的，本地的最新数据（高度压缩），S3 中的旧数据，由于微索引，从 S3 中提取的数据很少
Loki 聚合查询慢，而 SigLens，因为 AgileAgssTree 创新带来的闪电般的聚合查询

一句话，SigLens 号称自己比 Loki 牛逼多了。

SigLens 对比 OpenObserve 等

你们这些利用 Parquet/Arrow 格式的存储引擎，我就不多说了，如上图，在 SigLens 眼里，你们都是弟弟。

SigLens 和多种日志存储方案做了对比，不过没有对比 VMLogs，不知道是啥原因，觉得 VMLogs 不够格吗？还是 VMLogs 还没成熟？还是 SigLens 觉得和 VMLogs 半斤八两？

SigLens 安装

SigLens 建议咱们试用 Docker 安装，说一条命令搞定：

curl -L https://siglens.com/install.sh | sh

但是现在这个破网络环境，我还是自己下载代码编译安装吧。SigLens 是 go 写的，我机器上有 go 环境，直接 git clone 下来编译就行了。

git clone https://github.com/siglens/siglens.git

cd siglens

go build -o siglens cmd/siglens/main.go

./siglens --config server.yaml

上面的命令是编译并启动 SigLens 的命令，server.yaml 是配置文件，默认在当前目录下。server.yaml 的内容要看一下，配置项比较少，其中 UI 查询端口默认是 5122，接收数据的接口是 8081。

SigLens 接入日志数据

我之前本地测试过 vector，文章参考：高性能日志转发神器 Vector 的 Github Star 19K 了，对接一下夜莺的日志。那对这个配置稍作修改就可以复用了，我的 vector 的配置文件如下：

data_dir: "/Users/ulric/works/vector-test/data_dir"

api:

  enabled: true

sources:

  app_logs:

    type: "file"

    include:

      - "/Users/ulric/works/gopath/src/nightingale/logs/*.log"

transforms:

  parse_log:

    type: "remap"

    inputs:

      - "app_logs"

    source: |

      . |= parse_regex!(.message, r'(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{6}) (?P<level>\w+) (?P<source_location>[^ ]+) (?P<message>.+)')

      .timestamp = parse_timestamp(.timestamp, format: "%Y-%m-%d %H:%M:%S.6%f") ?? now()

      .@timestamp = del(.timestamp)      

sinks:

  print:

    type: "console"

    inputs:

      - "parse_log"

    encoding:

      codec: "json"

  es:

    type: "elasticsearch"

    inputs:

      - "parse_log"

    endpoints:

      - http://localhost:8081/elastic/

    mode: bulk

    healthcheck:

      enabled: false

可以看出来，SigLens 是兼容 ElasticSearch 接口的，即 /elastic/ 接口路径，伪装成 ElasticSearch 的样子。很快，你就可以在 SigLens 的 UI 上看到数据了。

右上角可以看出来，SigLens 也是每天一个索引文件，因为我的采集器是 vector，索引有个 vector 的前缀，不知道是在哪个环节加的。

我大概体验了一下日志检索和聚合功能，感觉还可以，UI 上有些细节处理不到位无关痛痒。不过不支持日志上下文查询功能，就是我看到一条关键日志，想查看这条日志的上面10行和下面10行，目前还没有找到这个功能。难道是要通过 Splunk QL 来写吗？我对 Splunk QL 还不熟悉，有熟悉的小伙伴可以留言指点一下哈。

另外我想查询 vector 作为前缀的所有索引，也没有找到这个功能，即类似 Elastic 里的 index pattern 的功能。这个不支持的话，告警规则就没法用了，按理说应该支持才对。难道 UI 不支持需要调用接口？那就不太方便了。SigLens 的文档不支持检索，找起来有点费劲。

SigLens 接入指标数据

SigLens 支持 Prometheus remote write 方式写入数据，其接口地址为：

http://localhost:8081/promql/api/v1/write

我用 categraf 直接采集了数据推过去，是可以推送成功的。简单查询也可以，比如：

上面查询的是 net_bits_recv 指标，这是一个 Counter 类型的数据，显然大家更关心的是 rate 或 increase 计算之后的结果，于是，我利用它的 UI，增加了 rate 函数：

GG 了，竟然没有让我输入 rate 函数的参数，直接就给我执行了，结果是错误的。好在我切到 code 视图，自己手写 Promql 是可以的：

SigLens 的告警能力

上面提了，我没有找到 SigLens 的 index pattern 功能，所以告警规则按理是没法用的（因为每天都会生成一个索引文件，而告警永远是针对最新索引的，所以告警规则里应该指定 index pattern）。但是实际情况并非如此。我昨天 4.16 号配置了一条告警规则，相关属性如下：

上面的属性中，并没有 index 相关的信息，这就奇怪了，拿到 SigLens 是对所有日志数据都做这个告警判定吗？还是说，SigLens 期望不同的 App 要单独部署一个 SigLens 实例？今天 4.17 号，我重新打开这个告警规则，点击编辑：

它自动帮我选择了 vector-2025.04.17 这个今天最新生成的索引让我预览数据。不知道它到底是怎么个逻辑，已懵圈。

点评

昨天大概研究了一天，底层数据存储吹得很牛逼，需要大数据量压测一下，如果真有他说的这么好，那前途不可限量。UI 层面有一些乱七八糟的小问题，再给点时间，按理说都可以修复。国内也有类似的创业公司，比如 GreptimeDB，也是尝试把 Metrics、Logs、Traces 统一存储，但是 GreptimeDB 目前是专注做存储没有涉及上层可观测性产品，否则就跟我们是竞品了，哈哈。而 SigLens 是从底层存储到上层可观测性产品都做了，上层做的还比较简陋，未来会如何尚不得而知。

指标、日志等数据都采集了，就是告警，通常各个公司都有多套告警相关的系统，导致告警散落各处，没法统一做告警降噪、排班、认领、升级，我们创业做了一个统一告警响应平台：Flashduty，注册就可以免费试用，创业不易感谢大家支持了解：https://flashcat.cloud/product/flashduty/。