云原生时代可观察性的挑战

在单体应用时代，应用部署在单机上，如需要高可靠性多以HA的方式部署，出现问题时可以直接登陆机器用命令查看机器的指标，日志等数据就比较容易能够定位。

但随着应用从单体架构演进到微服务架构，如今云上的应用分布式部署已经是默认选项，而微服务架构下带来了许多新的组件如Service Discovery，Service Router，使得整个架构比传统架构要复杂的多：

k8s的出现，更是带来了更简单可靠的应用部署管理能力，使得服务更容易被拆分，微服务化更加彻底，进一步使系统变得复杂而难以掌控。

CNCF的一个调查也显示，53%的受访者认为使用容器时最大的挑战是复杂性，同时有35%的受访者将可靠性和监控作为部署挑战

目前Serverless的应用也越来越广泛，在传统模式下，如果线上出现问题，我们可以登陆服务器，搜索日志，分析进程，甚至 dump 内存来进行问题分析。到了 Serverless 模式下，用户看不到服务器了，这个时候如果系统出现异常怎么办呢？用户还是需要有丰富的排查诊断工具，能够观测到包括流量、系统指标、依赖服务等各方面综合的状态，以实现快速准确的问题诊断。当围绕 Serverless 模式的全面可观测能力不足的时候，用户必然不会对此感到放心。

新技术新架构的出现使得系统越来越复杂，越是复杂越需要对系统的状态有全面的了解，才能保持线上系统的稳定，因此可观察性(Observability)被越来频繁的提及，那么我们到底需要一个什么样的可观察性工具呢？

可观察性工具的需求

可观察性有三大支柱: Metric、Trace、Log，其中Metric主要用来发现问题，Trace用来定位问题所在的服务，Log可以用来定位导致问题的根因，三者相辅相成，因此要成为一个统一的可观察性平台，对三大支柱的支持缺一不可。

SLS本身拥有强大的日志集中收集处理分析能力，日志模型实际上是一种随机 + 全局模型可以兼容Trace、Event，但时序场景是连续+局部分析模型，使用日志模型在性能和并发上不能满足需求，因需要一个专门用来存储时序数据的存储。

市面上有OpenTSDB，InfluxDB，Prometheus等开源的时序存储具，为什么SLS还需要开发MetricStore呢？实际上目前的时序存储或多或少存在一些问题：

<li data-lake-id="9cac5cfd6e4866696e81882166588eda">规模与弹性：InfluxDB开源版本是不支持集群的，Prometheus自身也只有单机模式以及联邦模式，拓展成分布式需要借助Thanos等工具，在数据规模到一定程度后，开源软件常常就力不从心了</li>
<li data-lake-id="407939242b3ab93a9fdcfdfd9f828440">灵活性：开源软件在各自的领域内都提供了很大的灵活性，但互相之间的配合并不紧密，例如使用Prometheus采集的数据对应的Grafana dashboard并不能直接用在用Telegraf采集的数据上</li>
<li data-lake-id="e04a6e8806aeb7a640affc323ab12df8">统一的分析能力：由于模型的差异，传统上时序数据经常使用特定的query语法，即使是InfluxQL也是SQL方言，并不能很好的和Log，Trace打通</li>
<li data-lake-id="0e2c9b260133b889423ae440fafb0c53">开放开源：对于商业产品，大家常常会担心是否足够开放，能否和原有的开源技术栈进行融合，是否可以在尽可能对不影响原有部署的情况下利用商业产品提供的额外能力</li>

因此，SLS开发了MetricStore，并结合SLS原有的采集、数据加工、分析、可视化、告警等能力，形成统一的解决方案。

MetricStore解决方案

规模与弹性

支撑大规模数据量以及可弹性拓展是SLS原本在日志上拥有的优势，在底层引擎上，SLS是一套纯分布式的存储计算分离架构，设计之初就是面向大规模、多租户的场景，一个时序库由多个Shard组成，数据会均匀存储在多个Shard中，并且Shard可以动态的扩缩容，不影响任何写入/查询。而业界众多开源时序引擎都是采用联邦或计算存储绑定的架构，在大规模场景下经常捉襟见肘。同时我们也做了大量性能优化，使MetricStore的查询性能最优。

架构改进

在PromQL查询引擎上，开源方案通常使用Prometheus的Remote Read API，这有一个致命缺陷: 数据一定要先传输到读取节点再做计算，在对大量数据做查询时，这部分网络开销可能超过计算开销成为瓶颈，而MetricStore因为内置了PromQL引擎，可以下推部分算子，并且可以在内网万兆网络中完成数据的拉取整合，返回聚合后结果，极大的加速了查询效率。

高性能存储模型

MetricStore底层由C/C++编写，充分利用各类硬件/指令优势，存储上使用了多种高效压缩算法（RLE、DeltaOfDelta、Gorilla、Prefix、ZSTD、LZ4等）组合，数据压缩率可达到10到100+倍，单核压缩性能可达30-100M/s。在时序场景，对于MetricName、Labels的查询支持压缩读取，大大提升数据查询性能。

多级缓存

时序场景的查询特点比较强：例如近期数据、查询局部性、持续性等。因此可以使用缓存来提升整体的查询性能。为了尽可能提升缓存的命中率，SLS提供了多层的缓存策略：

<li data-lake-id="9b5bf0bb39b79f1561c6f60145184338">查询结果：直接缓存PromQL的查询结果，相同请求可以直接返回结果，非常适用于多人同时刷屏的场景</li>
<li data-lake-id="9de70c925c25b8d8b66d401ae9b6aaeb">缓存时间线：在Prometheus层把获取到的时间线缓存下来，对于定期运行的Query只需额外获取增量数据即可</li>
<li data-lake-id="03eef76786ff4dcb2ed81d04b0b1d311">缓存Meta数据：SLS的MetricStore总共存在4级Meta，每个不同级别的Meta分别使用不同的缓存策略，尽可能避免Meta加载</li>
<li data-lake-id="0083721f34b07e8394ea14befe54cf21">Segment数据：实际存储的数据会按照分片存储在内存中，避免热点数据频繁读取磁盘</li>
<li data-lake-id="9b2592ee43ab45200c979076df66d6d9">近期数据：近期数据（5min以内）存储在内存中，使用无锁的多线程安全SkipList管理，支持高QPS读写</li>
<li data-lake-id="c0a4f341d729071b6827d68a84e064f0">SSD Cache：SLS采用的混合存储方式，文件都是先写SSD，然后定期搬到HDD，因此近期刷盘的数据都在SSD上</li>

PromQL引擎性能优化

我们在原生PromQL执行引擎上做了多项优化，包括路由、并行读取、部分算子下推、排序优化等，充分利用SLS的硬件资源优势，在大数据量查询时性能可提升近10倍。

经过重重优化后的MetricStore在各项性能指标以及稳定性上面都超越了开源软件，且对用户来说使用更简单，全托管免运维的方式也让用户更加省心。

统一分析能力

可观察性的本质就是对数据做分析，而长久以来Log、Trace和Metrics都使用不同的分析语法，Log、Trace因为更接近于数据库的表结构，因此适用SQL，Metrics数据因为有大量的时序处理，通常使用不同的语法，这使得三者难以进行统一的分析，而MetricStore在完全兼容PromQL的基础上还拓展了PromQL的分析能力，支持SQL+PromQL的混合调用，使得复杂的数据分析成为可能。：

<div class="lake-codeblock-content" style="border: 1px solid rgb(232, 232, 232); max-width: 750px; color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: rgb(249, 249, 249);">
  <div class="CodeMirror-sizer" style="color: rgb(89, 89, 89); margin: 0px; padding: 16px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line-number lake-lm-pad-level-0" style="color: rgb(191, 191, 191); margin: 0px 8px 0px 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"></span><span class="lake-preview-codeblock-content" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="cm-keyword" style="color: rgb(215, 58, 73); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">SELECT</span> promql_query_range<span class="cm-bracket" style="color: rgb(153, 153, 119); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">(</span><span class="cm-string" style="color: rgb(102, 153, 0); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">'some_metric'</span><span class="cm-bracket" style="color: rgb(153, 153, 119); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">)</span> <span class="cm-keyword" style="color: rgb(215, 58, 73); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">FROM</span> metrics

  </div>
</div>

当使用PromQL拿到查询结果后，在SQL中可以做进一步加工: 例如join维表，ip转换，例如:

<li data-lake-id="d3c529a4250fd76a3abf6e8cca6aa656">场景1: 数据label中带有ip，希望join cmdb中的数据做富化，得到机器的管理员，状态，所在机房等信息，以便做进一步判断</li>
<li data-lake-id="e0a65809ed5e5ccfa253ee0aa9086149">场景2: 数据label中带有用户访问ip，希望利用ip库将ip解析为省份，运营商</li>
<li data-lake-id="f5b7dcccd22eadecaf91a64bf69d50f7">场景3: 获得时间线后希望对数据做机器学习，例如时序分解，预测，异常检测等</li>
<li data-lake-id="ffb0d0830864a86104b5af2ca0a54994">场景4: 监控数据通过机器ip join日志数据，获取关联的日志</li>

这些场景通过PromQL本身都无法实现，但SLS借助和SQL的融合使其成为可能。同时用户也可以通过JDBC协议和已有的BI平台对接，无缝使用时序数据，而这些开源方案包括绝大多数商业方案均没有提供此类能力。

开放开源

SLS一贯有拥抱开源的良好传统，在MetricStore上也是一样，开源的数据都可以很容易的接入，且SLS原有的接入渠道例如Logtail，SDK写入等也得以保留，数据写入后可选择使用SLS的dashboard，也可以选择第三方可视化方案如Grafana。

丰富且开放的采集

<li data-lake-id="d2124474506a5aaf6df1a6b3b3619040"><a href="https://help.aliyun.com/document_detail/171781.html" target="_blank">Prometheus Remote Write</a><br>作为一个兼容PromQL的时序存储服务，SLS支持作为Prometheus Remote Write的目标，该方案可使用户无缝切换数据到SLS上，只需配置Remote Write，并且修改Grafana的数据源链接指向MetricStore即可完成Prometheus迁移。</li>
<li data-lake-id="bfb51d80c714503d7f3ba2724ae8e22f"><a href="https://help.aliyun.com/document_detail/188041.html" target="_blank">Telegraf接入</a><br>Telegraf也是一个很流行的数据采集器，logtail兼容了InfluxDB协议，因此可作为Telegraf的Output接收数据，此外我们还开发了全托管的Telegraf模板配置，用户无需自行维护Telegraf，只需要在sls页面上通过Wizard配置即可接入，Logtail将自动管理Telegraf的生命周期，配置下发等，同时还配备了相应的最佳实践Dashboard，开箱即用。<strong><br></strong></li>
<li data-lake-id="1720812338d56a1395e2e301e158b728"><a href="https://github.com/open-telemetry/opentelemetry-collector-contrib" target="_blank">OpenTelemetry接入</a></li>

作为未来云原生可观察性的标准方案，OpenTelemetry目前是CNCF下第二活跃的Project（仅次于Kubernetes，高于Prometheus），未来包括Log、Trace、Metric都会采用OpenTelemetry定义的标准，使这三者可以更好的结合。目前SLS已经提供了OpenTelemetry的接入方式，可以使用官方的Collector把Log、Trace、Metric数据写入到SLS中。

<li data-lake-id="1ec7338b1f2b1fe7bf21d91a03e83a13"><a href="https://help.aliyun.com/document_detail/29063.html" target="_blank">SDK写入</a><br>Prometheus的采集模式比较单一，始终是从一个Exporter Pull数据，对于大部分服务端程序来说这不是问题，但对于一些客户端程序想要写入自定义埋点数据，或者一些边缘计算节点希望上传数据时，因为Prometheus没有写接口，类似的需求难以实现，这时候SDK写入就派上用场了，用户可以使用SLS的各种语言的SDK来写入数据</li>
<li data-lake-id="94d92a995d3bb8b214afe8444c5d5e40"><a href="https://help.aliyun.com/document_detail/171780.html" target="_blank">云监控数据导入</a><br>通过导入云监控数据，用户得以将云资源的监控数据和自定义的监控数据存放到一起，对于混合云的用户尤为实用，不需要再在云上云下维护两套监控系统</li>
<li data-lake-id="b46e7b04d50d3b0c9dc6ae136f4f2373"><a href="https://help.aliyun.com/document_detail/28981.html" target="_blank">原有的各种输入途径</a></li>

如Logtail文件采集、移动端、Flink/Blink写入、BinLog、数据加工、OSS导入等。

丰富的数据接入渠道使得SLS可以化身为DevOps数据中台，对接各类数据进行一站式的分析。

开放可视化

SLS本身有着不错的可视化能力，Dashboard可满足大部分需求。在云原生下众多监控方案都是基于Grafana进行可视化，而近年来Grafana发展速度极快，基本上已经成为云原生中的监控数据可视化标准。因此我们也支持对接Grafana，用户不必改变原有的使用习惯，直接使用Prometheus数据源即可，或者也可以使用Grafana上的SLS数据源，SLS数据源可以使用SQL进行更复杂的处理。此外我们也给Grafana贡献了实用的Dashboard，在grafana.com搜索SLS即可下载。

因为MetricStore兼容Prometheus Query API，因此原先能用于Prometheus的可视化方案均能用于MetricStore。

落地场景

基于以上的能力，MetricStore在阿里巴巴集团内部以及公有云上都服务了大量用户的监控场景落地

场景1：阿里自用云原生监控究极方案

在阿里集团内部，我们服务了最大的基础设施: ASI（Alibaba Serverless infrastructure），是阿里巴巴针对云原生应用设计的统一基础设施。ASI可以认为是一组巨大的K8s集群，单个集群的Node数超过7000台物理机。ASI是面向云原生的，监控自然也使用了目前云原生下的标准监控方案：Prometheus。

最初ASI使用的是单机版Prometheus，随着规模的增大，单一的Prometheus已经无法承载，于是切换到了Thanos方案，并设计了一套多Thanos联合使用的方案 。然而当规模上到数万台物理机、上百万Pod后，Thanos开始逐渐暴露出一系列的问题：

• 写: 由于存储量大，本地磁盘无法存储足够的数据，存储周期短

• 查: 查询时常常需要聚合上百万条时间线，超过千万级的数据点，原生Prometheus的查询非常慢，常常超过分钟级响应，并且负载高，容易hang或者宕机

• 管：为了提高Thanos性能，使用了裸物理机的部署方案，机器申请、上下线、扩容、FailOver恢复等运维代价巨大

Thanos的架构非常复杂，如下图所示：

为了支持双十一业务，ASI需要扩容大量容器，这也意味着会增加大量的监控数据，此时寻找替代的Prometheus存储方案已经迫在眉睫。

MetricStore提供的方案相比要简洁的多，用户并不需要改变原有的Prometheus部署，只需要Remote Write写入就可以了：

ASI团队开始在7月份双写数据到Metric Store进行测试，并在双十一前将75%的集群监控数据的查询切换到Metric Store上，目前每日新增数据200+TB，稳定写入无数据丢失，存储时间从原来的15天增加到30天，报警查询的延迟更是下降了近3倍(18:28为切换时间点):

场景2：从分钟级到秒级

在外部用户中，同样有很多重度依赖MetricStore的客户，某头部互联网公司之前基于OpenTSDB构建了一套分钟级的监控系统，然而在业务量膨胀数倍后开始出现各类性能问题，经常会有几个大Query打爆整个集群的情况出现。

最终客户在调研了众多方案后选择使用SLS的MetricStore功能，实现数十倍的性能提升。

在此性能的基础上，客户开始追求更实时的告警方式，将数据采集、告警间隔从分钟级提升到秒级（5秒），数据量和查询QPS都会上升一个数量级。面对这种情况，用户仅仅是在SLS中分裂了一些Shard即可完成扩容。目前在每天写入超过500亿条数据，查询QPS上千的情况下一直稳定运行（客户压测中可达上万QPS）。

场景3：Log Metric结合

SLS上存储着大量的原始访问日志，很多用户直接基于访问日志来进行分析和监控，由于每次都要全量计算所有的日志，因此监控会浪费巨大的资源而且还达不到很低的延迟。MetricStore上线后，我们利用ScheduledSQL定期计算日志中的指标并写入MetricStore，所有的监控、告警、可视化都可以基于MetricStore中预聚和的指标进行，性能大大提升。同时SLS提供的智能巡检服务可直接基于MetricStore进行巡检，自动发现其中的异常指标并产生告警。接收到告警后，通过预置的可视化报表查看各类指标，在确定一些可疑点后，再跳转到原始访问日志的Logstore去查看详细的报错信息并确定根因。

目前Log Metric这套结合的方案已经应用于SLB访问日志分析、Kubernetes Ingress日志分析中，未来还会推广到更多的AccessLog型场景中，让基于AccessLog的分析、监控、问题排查更加便捷。

总结

SLS时序库的工作离不开集团和社区同学们的帮助，还要感谢集团内外客户们对SLS的信任，在MetricStore上线之初就开始接入各类的数据：因为信任、所以简单。

今年是MetricStore上线第一年，随着用户的增多，数据量的迅速增大，也面临着更大的挑战，我们也将持续优化MetricStore引擎，不断拓展在可观察性领域的想象力。

关键点来了：SLS团队长期招聘人才，欢迎对大数据、监控、可观察性、前端可视化、移动端开发、机器学习等有兴趣的同学前来联系我~~