大伟，携程软件技术专家，关注企业级监控、日志、可观测性领域。
监控领域有三大块，分别是 Metrics，Tracing，Logging。这三者作为 IT 可观测性数据的三剑客，基本可以满足各类监控、告警、分析、问题排查等需求。
Logs：我们对于 Logs 是更加宽泛的定义，即记录事物变化的载体，包括常见的访问日志、交易日志、内核日志等文本型以及 GPS、音视频等泛型数据。日志在调用链场景结构化后其实可以转变为 Trace，在进行聚合、降采样操作后会变成 Metrics。
Metrics：是聚合后的数值，相对比较离散，一般有 name、labels、time、values 组成，Metrics 数据量一般很小，相对成本更低，查询的速度比较快。
Traces：是最标准的调用日志，除了定义调用的父子关系外（一般通过 TraceID、SpanID、ParentSpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过 Trace 能够代替一部分 Logs 的功能，通过 Trace 的聚合也能得到每个服务、方法的 Metrics 指标。
近年来，可观测性这个概念如火如荼，可以看作是对监控的一次大升级。CNCF 也发布了 OpenTelemetry 标准，旨在提供可观测性领域的标准化方案。那么相比传统的监控告警，监控和可观测性有啥区别和联系呢？个人理解，可观测性能够以更加白盒的方式看透整个复杂的系统，帮助我们更好的观察系统的运行状况，快速定位和解决问题。
简单理解，监控和可观测性的关系。监控告诉我们系统的哪些部分是正常工作的，可观测性告诉我们那里为什么不工作了。监控侧重宏观，可观测性包括微观能力。监控是可观测性的子集。
图1
近些年，随着携程集团对线上故障 1-5-10 目标的提出（即第 1 分钟发现故障，第 5 分钟定位故障，第 10 分钟解决故障），对监控系统提出了更高的要求。监控系统最重要的三个特点可以定义为，系统稳定性，数据及时性，数据精准性，三者缺一不可。
携程监控系统 Hickwall 是一个企业级的指标监控告警系统，兼容了业界的 Prometheus 监控标准，覆盖携程所有的指标监控数据，包括系统层和应用层。主要目标是实现指标数据的采集、接入、存储、展现，并在此基础上配置告警和通知，告警治理等，同时为第三方平台提供第一手的监控数据和告警事件。
二、遇到的问题
随着业务不断膨胀，系统规模的持续扩大，Hickwall 遇到了一些问题：
- 高基数查询，指标维度过多，导致整体查询慢，用户体验不佳。
- 云原生的监控方案缺乏，需要支持开源 PromQL 业界标准，Prometheus SDK 指标接入。
- 监控粒度粗，一些毛刺无法洞察，需要提高数据采样粒度。
- 告警系统多，技术方案杂，难维护，产品使用上用户到处找入口，规则和阈值定义不一样，很困惑。
- 监控数据延迟，导致误告警。
- 告警多，重复告警，缺乏治理。
- 容器大规模 HPA 带来的指标基数膨胀问题。
三、主要的演进
针对上述问题和痛点，Hickwall 过去两年进行了一些针对性的优化和演进。
3.1 云原生监控
1）TSDB 升级，经过三次演进，现在是基于 VictoriaMetrics 实现的第四代的 TSDB 解决方案。完全兼容 Prometheus 查询语法。
2）提供了自研 Beacon 容器监控组件，和 k8s 体系高度集成，不仅支持容器系统指标，JVM 指标，也支持自定义的 PrometheusSDK 埋点接入。
3.2 解决高基数问题
1）产品升级，新增日志/指标预聚合能力，产品开放配置能力，根据一定配置策略，通过将多维原始数据降维，收敛指标维度，聚合输出预聚合数据，通过这种方式可以缩减指标量级，对后续链路的处理都有性能提升。目前系统配置了 166 条聚合规则，生成了 209 个指标。
2）指标治理：监控统计指标维度，应用维度的高基数检测，对非法写入进行封禁。非法写入包括了 tag 的 value 使用了随机数，字符内容超过 256 个字符，指标名称使用了中文命名等。
3）容量规划：做好集群的自监控，进行妥善的容量规划，主要是监控 ts 增长数量和 datapoint 数据量，以应对日益增长的指标数据。
4）忽略有问题的 tag：治理平台能够按需配置 ignore tag，例如针对 HPA 场景下的应用埋点，忽略 value 容易发生变化的 hostname 和 ip 这两种 tag（一般不会关心这种维度），可以大大减少基数。
3.3 数据粒度提升
为了响应集团 1-5-10 目标，核心指标采集上秒级，目前主要涉及的是核心的系统指标，业务订单指标和部分应用指标，其他非关键可以按需自行配置。
3.4 告警中台接入
自研新一代统一的 pull 告警系统，统一各类老的告警技术方案，目前接入告警规则 10 万+，同时对接了告警中心，对用户提供一站式的告警治理能力。
3.5 解决数据延迟问题
数据延迟问题主要是数据链路还依赖了消费 Kafka 来写入 TSDB。因此我们将核心链路改造成最短路径，从数据网关分发数据直接写到 TSDB，从根本上解决了延迟问题。
3.6 时序存储的演进
Hickwall 存储这块主要经历了下面四个阶段。
第一阶段：ES 存储，Graphite 查询语法
第一个版本的架构主要以数据写 Kafka，消费 Kafka 进 ES 的套路来设计。这个方案的好处：
- 可以容忍比较大的系统 downtime
- 数据可以多次多种方式加以利用
- ES 存储的写入性能最大化
- ES 的聚合能力比较强，所以不少聚合都可以实时来做
- ES 非常稳定可靠，运维工作较少
第一个版本已经初步实现了监控系统的功能，但是在使用过程中同样暴露了一些问题：
1）ES 存储导致数据容易堆积
ES 是一个非常稳定的全文索引工具，比较适合日志，搜索的场景。但是却不是最好的监控数据的存储方式，主要是写入性能不是很好，必须大批量，高等待的方式写才能达到比较大的量，但是这个比较大的量相对监控数据的场景也略显不够。
而且为了提高写的性能，还需要牺牲数据的实时性（提高 refresh time 来减少磁盘操作，提高写入量）。实时性又是一个高质量的监控系统所需要努力提高的。这就是一个矛盾点，虽然当时能够做到勉强接受，但肯定不是最理想的，当时的数据 latency 需要 30s 以上。
2）数据链路过长
监控数据主要是从 Proxy 进来到 Trigger 告警需要依次经过 6 个组件，任何一个组件出现问题，都可能导致告警漏告或误告。
第二阶段：基于 InfluxDB 存储，打造自研的 Incluster 集群方案，Graphite 查询语法
ES 用于时间序列存储存在不少问题，例如磁盘空间使用大，磁盘 IO 使用多，索引维护复杂，写入和查询速度慢等。当时 InfluxDB 是排名第一的时序数据库，到 2017 年的时候已经比较稳定，所以我们萌生了用 InfluxDB 替换 ES 作为存储的方案。但是 InfluxDB 并没有开源的集群方案，因此我们自研了 Incluster 集群方案。
在元数据管理这块使用了 Raft 来保证一致性和分区容错性。集群大致的实现思路是，客户端通过 Incluster 节点写入数据，Incluster 按照数据分布策略将写入请求转发到相关的 InfluxDB 节点上，查询的时候按照数据分布策略进行数据读取和合并。在用户查询方面，实现了类 Graphite 语法用于配图，兼容上一代语法，从而可以减少用户迁移配图的成本。
第三阶段：ClickHouse 列式存储，SQL 查询语法
2019 年，我们逐步开始推进应用埋点存储的统一接入。在这个阶段，InfluxDB 在高基数场景下，查询表现并不是很好，集群稳定性也受到了较大的挑战。因此我们调研了当时大火的 ClickHouse，开始接入应用埋点，并且提供 SQL 语法查询。携程的机票部门率先接入，在自定义应用埋点场景取得了比较好的效果。
第四阶段：基于开源的 VictoriaMetrics TSDB，PromQL 查询语法
2020 年，随着云原生技术的发展，内部对云监控的需求越来越强烈。因此我们在 2020 年调研并测试了业界开源的 VictoriaMetrics TSDB，这款 TSDB 作为 Prometheus 的远端持久存储解决方案，提供了相较于传统 TSDB 较好的性能和天然兼容 Prometheus 协议的查询语法和接口。
这款 TSDB 经过测试在综合写入性能和查询方面表现较好。目前我们内部主要分了三个大集群，集群规模已经达百余台物理机，成为携程统一的 Metrics 存储方案。
图2
3.7 监控可视化的演进
由于内部使用的可视化工具是基于 Grafana 二次开发，伴随着存储技术的升级，2020 年我们还进行了一次 Grafana2 版本到 6 版本的全面升级，新版本增加了多种新的数据源，所见即所得的告警能力，更多的图表类型展现，可视化方面大大提升了用户体验。
四、平台现状
随着多年的发展，目前平台指标数据量写入量峰值在千万级/秒，查询量数千 qps，接入各类告警规则 10 万+，查询 P99 控制在 1s 内。数据粒度最小支持到 10s 级，时序数据默认保存一年。计算+存储集群规模达百余台物理机，并且主要组件都上了 k8s 平台。数据统计如图 4 所示。
图4
五、目前架构
从数据流向看，目前总体大致架构如图 5 所示，可见数据流和告警是走的最短路径。
1）数据：data->Proxy->TSDB
2）告警：data->Proxy->Trigger
这从根本上规避数据延迟和告警延迟问题。下面会主要介绍 Hickwall 所依赖的几个核心组件。
图5
Collector 组件：
数据采集，提供多种客户端，包括了 Hickwall SDK（应用埋点），Hickwall agent（机器数据采集），Prometheus SDK，Beacon（容器数据采集）。
Proxy 组件：
提供给 Hickwall SDK，Hickwall agent，Prometheus SDK 的统一支持多协议的数据收集服务，主要是 thrift protocol 和 line protocol。作为数据接收的统一入口，承担了流量接入，分发，流量保护，数据统计等功能。Proxy 默认为每个应用 ID 提供了固定的流量配额，具备了基于指标，应用 ID 的限流能力，目前是基于固定时间窗口进行数据量流控。
告警组件：
提供了 Trigger 流式告警和基于 Bosun 的统一 pull 告警。通过推拉结合的告警引擎解决了大规模阈值告警和复杂同环比告警场景。
DownSample 组件：
数据降采样，支持可以配置的聚合采样粒度，节省存储成本。同时提供数据保存更长的时间。
Piper 组件：
统一的告警通知服务，支持告警通知升级。
Transfer 组件：
负责监控数据分发给第三方系统，供数据分析，容量规则，AI 智能告警等用途。
Grafana 看板服务：
所见即所得的查询，提供丰富的图表展现以及监控大盘。
TSDB Cluster：
是最核心的时序存储集群，时序类的查询一般 QPS 都比较高（主要有很多告警规则），通常都是 range 查询，每次查询某一个单一的指标/时间线，或者一组时间线进行聚合。所以对于这类数据都会有专门的时序引擎来支撑，目前主流的时序引擎基本上都是用类似于 LSM Tree 的思想来实现，以适应高吞吐的写入和查询。
ClickHouse Cluster：
ClickHouse 作为优秀的 OLAP 列式数据库，早期是我们采用的第三代时序存储引擎，现在慢慢退居二线，目前现在用来导入一些时序数据和高基数指标数据，提供一些额外的数据分析能力。
Hickwall Portal：
一站式的监控日志告警治理平台，目前提供了指标接入，指标查询，告警配置，通知配置，日志接入，日志管理，机器 agent 治理等模块。
从存储集群来看，TSDB Cluster 的架构如下：
1）总体架构分为三层结构，vminsert 写入层，vmstorage 存储层，vmselect 查询层。这三个组件都可以单独进行扩展，并运行在大多数合适软件上。
2）写入层无状态，支持多协议的写入，写入层支持多协议，包括 InfluxDB，OpenTSDB，Prometheus，Graphite 等。接受程序写入的数据，通过对 metric+tag 组合进行一致性 hash 写入到对应的存储节点，当有存储节点失联，会进行数据重路由分发到好的节点上面。重路由的过程中，由于数据分发策略的变化，可能会导致写入变慢，等待存储节点倒排索引重建完成，就会恢复写入速度正常。
3）存储层有状态，采用 shared nothing 的结构，每个节点数据不共享，独立存储，增加了集群的可用性，简化集群的运维和集群的扩展。支持多租户，采用了 ZSTD 压缩，列式存储，支持副本配置。
存储层的基本原理可以理解为存储了原始的数据，并且会依据查询层发来的 time range 和 label filter 进行数据查找并且返回。在存储层，针对时序数据做了很多存储优化。存储层要求配置一个数据保存的时间，俗称 Retention Period。Retention Period 到期后，会进行倒排索引的清理和重建，cpu 和 io 通常会大幅提升，会影响写入效率。
从压缩来看，压缩能够很好节省内存和磁盘空间，时序数据的压缩特征比较明显，TSDB Cluster 采用先做时序压缩，再做通用压缩的方法。比如，先做 delta-of-delta 计算或者异或计算，然后根据情况做 zig-zag，最后再根据情况做一次 ZSTD 压缩。据测试统计，在生产环境中，每个数据点（8 字节时间戳 + 8 字节 value 共计 16 字节）压缩后小于 1 个字节，最高可达 0.4 字节，能提供比 Gorilla 算法更好的压缩率。
4）查询层无状态，支持 PromQL 查询。
基本原理可以理解为进行查询语法解析，从存储层获取时序数据并且返回标准的格式，查询层往往会进行一些查询 QPS，查询耗时的限制，以保证后端服务不被拖垮。
TSDB 的部署架构图如下：
图 6
六、未来规划
随着可观测性技术的不断发展，仅仅局限于 Metrics 监控是不行的，我们对未来的展望如下。
1）指标分级
指标管理没有优先级，希望提供分级管理的模式。
2）云原生可观测性的探索
eBPF 指标采集的引入，提升主机端的可观测性能力。
3）Logging，Metrics，Tracing 的结合。
多套方案交织：可能要使用至少 Metrics、Logging、Tracing3 种方案，维护代价巨大。在这种多套方案组合的场景下，问题排查需要和多套系统打交道，若这些系统归属不同的团队，还需要和多个团队进行交互才能解决问题，整体的维护和使用代价非常巨大。因此我们希望能够使用一套系统去解决所有类型可观测性数据的采集、存储、分析的功能。
4）兼容业界主流协议，OpenTelemetry 的标准。
OpenTelemetry 旨在提供统一的可观测性数据收集，未来服务端可以提供兼容 OpenTelemetry 协议的接入，拥抱开源社区，我们在保持关注中。
5）agent 边缘计算，前置数据聚合。
现在是服务端基于 Flink 做预聚合，希望可以在 agent 端提供一些预聚合能力，比如采集日志的 agent 能够聚合 Metrics 输出。
一、背景概述
框架Dashboard是一款携程内部历史悠久的自研监控产品，其定位是企业级Metrics监控场景，主要提供用户自定义Metrics接入，并基于此提供实时数据分析和视图展现的面板服务，提供可定制的基于时间序列的各类系统级性能数据和业务指标数据的看板。还可以提供灵活的数据收集接口、分布式的大容量存储和灵活的展现方式。
由于时间较早，那时候业界还没有像样的TSDB产品，类似Prometheus，InfluxDB都是后起之秀，所以Dashboard选型主要使用了HBase来存储Metrics数据。并且基于HBase来实现了TSDB，解决了一些HBase热点问题，同时将部分查询聚合下放到HBase，目的是优化其查询性能，目前看来总体方案依赖HBase/HDFS还是有点重。
近些年，随着携程监控All-in-One产品的提出。对于内部的Metrics存储统一也提出了新的要求。由于Dashboard查询目前存在的诸多问题以及Metrics统一的目标，我们决定替换升级Dashboard现有的HBase存储方案，并且在Metrics场景提供统一的查询层API。
二、整体架构
Dashboard产品主要分了6个组件，包括dashboard-engine，dashboard-gateway，dashboard-writer，dashboard-HBase存储，dashboard-collector，dashboard-agent。目前实时写入数据行数6亿条/分钟，架构图如下：
- dashboard-engine是查询引擎。
- dashboard-gateway是提供给用户的查询界面。
- dashboard-writer是数据写入HBase的组件。
- dashboard-collector是基于Netty实现的Metrics数据收集的服务端。
- dashboard-agent是用户打点的客户端，支持sum，avg，max，min这几种聚合方式。
- dashboard-HBase是基于HBase实现的Metrics存储组件。
产品主要特性如下：
- 支持存储精确到分钟级的基于时间序列的数据。
- 单个指标数据可支持多个tag。
- 展现提供任意形式的视图同时可灵活基于tag进行分组。
三、目前的存在问题
基于HBase的Metrics存储方案虽然具有良好的扩展性，比较高的吞吐，但是随着时间发展，已经不是最优的TSDB方案了，可以归纳总结为如下几个痛点。
- 在TSDB场景查询慢，整体表现不如专业的TSDB。
- HBase热点问题，容易影响数据写入。
- HBase技术栈运维操作很重。
- 采用自研协议，不支持业界标准的Prometheus协议，无法和内部All-in-one监控产品较好的融合。
四、替换难点
- 系统写入数据量大，6亿条/分钟。
- Dashboard数据缺乏治理，很多不合理高维的metrics数据，日志型数据，经过统计，整体基数达上千亿，这对TSDB不友好，这部分需要写入程序做治理。如图2所示是top20基数统计，有很多Metric基数已经上亿。
- Dashboard系统存在时间久，内部有很多程序调用，替换需要做到对用户透明。
五、替换升级方案
从上面的架构来看，目前我们替换的主要是dashboard-writer和dashboard-HBase这两个最核心的组件。为了对用户的平滑迁移，其他组件稍作改动，在dashboard-engine组件上对接新的查询API即可替换升级成功。对于用户侧，查询的界面dashboard-gateway和打点的客户端dashboard-agent还是原有的模式不变，因此整个的替换方案对用户透明。具体如下：
1、dashboard-HBase升级为dashboard-vm
存储从HBase方案替换成VictoriaMetrics+ClickHouse混合存储方案：
- VictoriaMetrics是兼容主流Prometheus协议的TSDB，在TSDB场景下查询效果好，所以会接入绝大多数TSDB数据。
- 基于ClickHouse提供元数据服务，主要为界面的adhoc查询服务，原来这部分元数据是存储在HBase里面，新的方案采用ClickHouse来存储。元数据主要存储了measurement列表，measurement-tagKey列表，measurement-tagKey-tagValue列表这三种结构，目前在ClickHouse创建了一张表来存这些元数据。
本地表结构为：
CREATE TABLE hickwall.downsample_mtv
(`timestamp` DateTime,
`metricName` String,
`tagKey` String,
`tagValue` String,
`datasourceId` UInt8 DEFAULT 40)
ENGINE = ReplicatedMergeTree(‘/clickhouse/tables/hickwall_cluster-{shard}/downsample_mtv’, ‘{replica}’)
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp, metricName, tagKey)
TTL timestamp + toIntervalDay(7)
SETTINGS index_granularity = 8192
分布式表结构为：
CREATE TABLE hickwall.downsample_mtv__dt
(`timestamp` DateTime,
`metricName` String,
`tagKey` String,
`tagValue` String,
`datasourceId` UInt8 DEFAULT 40)
ENGINE = Distributed(hickwall_cluster, hickwall, downsample_mtv, rand())
- ClickHouse存储少量日志型的数据
由于长期缺乏一些治理，Dashboard还存储了一些日志型数据，这类数据是一些基数很大但数据量少的数据，不适合存储在VictoriaMetrics。为了实现所有数据透明迁移，这部分数据经过评估，通过白名单配置的方式接入ClickHouse来存储，需要针对每一个接入的日志型指标来创建表和字段。目前的做法是按照BU维度来建表，并且针对指标tag来创建字段，考虑到接入的日志型指标数量少，所以表的字段数量会相对可控。用机票FLT的表结构举例如下图。
2、Dashboard-writer升级为Dashboard-vmwriter
Dashboard-collector会分流全量的数据到Kafka，Dashboard-vmwriter的工作流程大致是消费Kafka->数据处理->数据写入存储。Dashboard-vmwriter主要实现了以下几个核心的功能：
- Metrics元数据抽取功能，负责抽取出measurement，tagKey，tagValue写入ClickHouse的mtv本地表。这块元数据存储主要依赖了Redis（用于实时写入）和ClickHouse（用于查询）。
- 指标预聚合功能，用于加速查询。对接公司内部的配置中心来下发预聚合的配置，配置格式如下。
下面的配置会生成ClusterName和appid这两个维度组合的credis预聚合指标。
{
“metricName”: “credis.java.latency”,
“tagNames”: [
“ClusterName”,
“appid”
]
}
配置下发后，Dashboard-vmwriter会自动聚合一份预聚合指标存入VictoriaMetrics，指标命名规则为hi_agg.{measurement}_{tag1}_{tag2}_{聚合field}。同样的，查询层API会读取同样的预聚合配置来决定查询预聚合的指标还是原始的指标，默认为所有的measurement维度都开启了一份预聚合的配置，因为在TSDB实现中，查一个measurement的数据会扫描所有的timeseries，查询开销很大，所以这部分直接去查预聚合好的measurement比较合理。
- 数据治理：异常数据自动检测及封禁，目前主要涉及以下方面：
1）基于HyperLogLog的算法来统计measurement级别的基数，如果measurement的基数超级大，比如超过500万，那么就会丢弃一些tag维度。
2）基于Redis和内存cache来统计measurement-tagKey-tagValue的基数，如果某个tagValue增长过快，那么就丢弃这个tag的维度，并且记录下丢弃这种埋点。Redis主要使用了set集合，key的命名是{measurement}_{tagKey}，成员是[tagValue1，tagValue2，… , tagValueN]，主要是通过sismember来判断成员是否存在，sadd来添加成员，scard判断key的成员数量。
写入程序会先在本地内存Cache查找Key的成员是否存在，没有的话会去Redis查找，对Redis的qps是可控的，本地Cache是基于LRU的淘汰策略，本地内存可控。整个过程是在写入的时候实时进行的，也能保证数据的及时性和高性能，写入Redis的元数据也会实时增量同步到ClickHouse的mtv表，这样用户界面也能实时查询到元数据。
3）数据高性能写入，整个消费的线程模型大概是一个进程一个kafka消费线程n个数据处理线程m个数据写入线程。线程之间通过队列来通信，为了在同一个进程内方便数据做预聚合操作。假设配置了4个数据处理线程，那么就会按照measurement做hash，分到4个bucket里面处理，这样同一个measurement的数据会在一个bucket里面处理，也方便后续的指标预聚合处理。
private int computeMetricNameHash(byte[] metricName) {
int hash = Arrays.hashCode(metricName);
hash = (hash == Integer.MIN_VALUE ? 0 : hash);
return hash;
}
byte[] metricName = metricEvent.getName();
hash = computeMetricNameHash(metricName);
buckets[Math.abs(hash) % bucketCount].add(metricEvent);
经过程序埋点测算，正常情况下整体链路的数据写入延迟控制在1s内，大约在百毫秒级。
3、Metrics统一查询层
契约上，兼容了Dashboard原来的查询协议，也支持标准的prometheus协议。
实现上，封装了VictoriaMetics+ClickHouse的统一查询，支持元数据管理，预聚合管理，限流，rollup策略等。
查询层主要提供了以下四个核心接口。
- Data接口：根据measurement，tagKey，tagValue返回时序数据，数据源是VictoriaMetrics。
- Measurement接口：返回limit数量的measurement列表，数据源是ClickHouse。
- Measurement-tagKey接口：返回指定measurement的tagKey列表，数据源是ClickHouse。
- Measurement-tagKey-tagValue接口：返回指定measurement和tagkey的tagValue的列表，数据源是ClickHouse。
如下图第一张所示是新的存储架构，第二张是VictoriaMetrics自身的架构。
需要注意到，整个数据写入层是单机房写单机房的存储集群，是完全的单元化结构。最上层通过统一的数据查询层汇总多个机房的数据进行聚合输出。在可用性方面，任何单一机房的故障仅会影响单机房的数据。
六、替换前后效果对比
1）替换后的查询耗时从MAX，AVG，STD提升近4倍。查询耗时大多落在10-50ms之间。相比之前HBase经常查询超时，整体查询的稳定性也好了很多，见图6，7。
2）写入稳定性提升，彻底解决了因为HBase热点引发的数据积压。
3）替换后支持了更多的优秀的特性，可以基于promQL实现指标的逻辑计算，同比环比，模糊匹配等。
七、未来规划
1）统一查询层接入所有Metrics数据，除了Dashboard，目前内部还有HickWall，Cat有大量Metrics数据没有接入统一查询层，目前采用的是直连openrestry+VictoriaMetrics的方式，openrestry上面做了一些简单的查询逻辑，这块计划后续接入统一查询层，这样内部可以提供统一的元信息管理，预聚合策略等，达到Metrics架构统一。
2）提供统一写入层，总体Metrics目前是近亿级/秒，这块写入目前主要是基于Kafka消费进存储的方式，内部这块写入是有多个应用在处理，如果有统一的写入层那么就能做到写入逻辑统一，和查询层的查询策略也能做到联动，减少重复建设。
3）Metrics的存储统一层提供了较好的典范，内部的日志存储层统一也在如火如荼的进行中，也会往这样的一个方向发展。
