借此宝贵机会，openGemini自信的向全球云原生开发者发出试用邀请，同时传递了两个声音：

1. 应对可观测性领域技术挑战，openGemini始终支持openTelemetry统一的采集协议和遥测格式。

2. openGemini已完成对Metrics和Logs两类遥测数据存储支持，效果优异。

a) 在Metric存储方面，通过标签索引、列存引擎持续优化，已具备性价比领先性。

b) 在Log存储方面，已取得技术突破性进展，相比Elasticsearch，在实验环境下，1亿条日志数据的文本索引构建时间减少60%，索引占用内存空间减少65%，日志关键词精确匹配、模糊匹配等查询性能提升均在60%以上。

c) 在未来可预见的时间里，将支持Tracing存储，彻底解决高基维(High Cardinality Tag Value)问题，实现Metric、Log和Trace数据在同一数据库系统内完成关联分析，成为真正意义上的可观测性领域的数据存储底座。

● 什么是可观测性？

可观测性（Observability）一词最早出现在控制论领域，指系统可以由其外部输出推断其内部状态的程度，有着几十年的历史。2018年，CNCF率先将可观测性一词引入IT领域，随着近年来云原生技术的进一步发展，在带来效率、可用性提升的同时也增加了复杂度，希望通过可观测性这种手段，将系统的复杂度降到最低，因此可观测性被推到了前所未有的重要地位。

Gartner将应用可观测性（Applied Observability）列为“2023年十大战略技术趋势”之一，并指出，到2026年，70%成功实现可观测性的企业机构，将能够降低决策延迟，帮助目标业务或IT流程建立竞争优势。

● 云原生时代的可观测性有哪些技术挑战？

我们发现，随着IT系统规模不断增大，为加快问题发现和解决问题的速度，监控指标数量将越来越多，指标采集的粒度也变得越来越小，数据量呈现指数级增长。这种现象在云上尤为明显，以华为云为例，每秒将有数千万指标数据产生，每天收集的指标和日志数据量高达数十TB，这些数据将会被全部存储下来，用于告警、异常检测、实时监控，故障定位等。

很明显，如此海量的数据，给可观测性系统带来性能、存储成本、数据分析、系统运维等前所未有的技术挑战。

1. 高并发，低时延

大量服务和应用产生海量时间线和遥测数据，每秒写入流量高达数百MB，而绝大部分查询时延必须维持在ms级才能满足系统要求，这对后端存储系统的并发和处理延时提出了新的挑战。

2. 数据存储成本敏感

海量数据存储，必然带来存储成本的快速升高，这使得后端存储系统既要有出色的性能，还要控制存储成本，要求越来越高。

3. 系统复杂度高，运维压力大

随着业务越来越多，多种技术栈搭配使用，导致系统复杂度越来越高，运维人员将面临比以往更大的运维压力。

4. 数据分散，数据关联分析困难

由于监控数据分散，数据格式不统一，故障发生后，运维工程师花费大量精力排查问题，无法快速和准确的定位问题，治标不治本。

● 面对挑战，如何破局？

首先，我们需要解决采集数据格式统一的问题，方便问题定位和数据关联分析。openTelemetry对指标、调用链和日志等数据做了统一的定义，并且是开源软件，它提供了丰富的SDK，数据采集十分便利。

其次，我们还需要解决时序数据，数据分散存储的问题，指标、调用链、日志均为典型的时序数据，使用openGemini进行统一存储是非常合理的选择。为此，openGemini实现了统一接口，通过OTel Collector可以直接将数据写入数据库。

最后，我们还要解决openGemini的性能问题，以满足海量数据的写入和查询要求。openGemini有针对性的进行了大量优化设计，比如向量化、GC优化、LSM tree时序优化、数据预处理技术、流式计算等，取得了良好效果，更具竞争力，主要表现在如下几个方面：

指标数据存储方面，相比ClickHouse、InfluxDB等均有明显的读写性能优势。

数据压缩方面，相比其他NoSQL数据库，存储空间节约90%。

日志存储方面，openGemini采用一种全新的CLV索引算法，实验环境下，相比Elasticsearch，文本索引构建时间更短，内存空间占用更少，查询效率提升60%以上。

● 总结

时至openGemini开源半年之际，我们有幸第一次站在KubeCon EU 2023的舞台上向全球开发者介绍了openGemini在可观测性方面的成果与进展。

openGemini已向可观测性领域一系列技术挑战发起冲锋，我们人单力薄，欢迎企业、开源爱好者参与进来，解决我们共同的问题。

社区合作联系方式：http://opengemini.org/contact-us