事件管理革命：监控系统中统一日志和指标
在监控系统的语境下，日志（Logs）和指标（Metrics）通常被分开处理。不过，如果我们站在更高维度审视这两种数据，就会发现它们本质上都是事件（Events）。这为我们简化和优化监控系统中的事件管理提供了一条新的道路。
监控系统中的事件
监控系统中的事件，是指在特定时刻发生的具体现象。事件由三个基本组成部分定义：时间戳、载荷（Payload）和上下文。时间戳记录事件发生的时间，Payload 包含事件的详细信息，上下文提供了辅助信息以更好地理解事件。例如，CloudEvents 定义的事件格式如下：
其中，time 对应事件的时间戳，data 对应事件的 Payload，其他字段，例如 subject 和 type 等，则是上下文信息。
日志（Log）作为一种事件
传统日志处理将日志定义为系统活动的详细记录。日志包含非结构化消息，通常需要复杂的搜索机制来提取有意义的信息，从而进一步提供数据洞察。
把日志映射到上面的事件格式定义中，其消息内容就是 Payload。从这个角度出发，我们能以统一的方式处理日志数据与其他类型的事件。例如，一条 NGINX 访问日志可以转换为以下事件格式：
其中 data 对应到事件的 Payload。其他字段，例如 referrer 和 ip 等，属于事件的上下文信息。当然，time 时间戳是必然有的。
指标（Metric）作为一种事件
另一方面，指标是结构化数据，通常用做趋势分析和异常检测。指标将信息编码在特定字段或值当中，这些字段或值可以被视为 Payload。一个 Prometheus 接口上报的指标可以转换为以下事件格式：
其中 value 对应到事件的 Payload，time 是时间戳，其他字段是事件的上下文，通常被称作标签（Tags）。
日志和指标作为事件的异同
通过将日志和指标各自抽象为一种事件，我们发现日志和指标实际具有相同的结构，只是在 Payload 上有所不同。
两者之间的相同之处为统一处理带来了机会，而 Payload 上的不同则是统一方案主要需要面对的差异。不同的 Payload 需要不同的能力来进行分析：
日志（文本消息）：需要高级搜索功能来理解非结构化数据；
指标（数字值）：依赖聚合函数，用于分析趋势和检测异常。
统一的时间戳和标签上下文是查询优化和数据筛选的共同需求。
统一的事件数据库
现在，不妨想象一下可以存储所有指标和日志等事件的统一数据库将带来的变革。
这种统一可以显著增强我们在不同数据源之间进行关联分析的能力。例如，根因分析将变得非常简单，因为所有相关的事件数据都在一个地方，无需在多个系统和接口之间切换。
统一数据库的优势
增强的关联分析：所有事件在一个地方，便于无缝的关联分析；有助于及早识别模式和检测问题，辅助根因分析并减少警报疲劳。
简化的基础设施：一个数据库服务于多种用途，可以显著减少部署和维护工作量，无需在多个系统之间搭建各种集成倒腾数据。
实时处理和分析：统一数据库可以简化数据处理，提供实时分析能力，带来更快的信息洞察并提升决策速度。
成本效益：整合多个系统，减少硬件和软件成本以及运营开销。
GreptimeDB 如何实现事件管理革命
要想实现统一事件管理的愿景，GreptimeDB 是一个良好的开始。接下来，我们介绍如何在 GreptimeDB 当中实现这一目标。
理想的数据管理平台
GreptimeDB 是一款面向云原生设计的，高效高性能的时序数据库，擅长处理大规模的时序数据。它完全基于 Rust 语言编写，其架构在表引擎、存储引擎、查询引擎和索引框架方面提供了极好的抽象，是我们统一方法的坚实基础。
完整的系统架构图 可从 GreptimeDB 的文档中查看。
用户友好的数据模型
GreptimeDB 提供的时序表抽象对于熟悉关系型数据库的用户来说非常直观。这个模型也适合利用 SQL 做分析，帮助用户轻松地集成到现有数据处理生态当中，查询分析他们的数据，而不会因为引入一个方言带来陡峭的学习曲线。
GreptimeDB 的表引擎会对数据建模，但从用户视角看，其使用体验是 Schemless 的。
增强文本搜索能力
为了完全实现统一数据库的愿景，我们需要进一步增强 GreptimeDB 以支持文本列。通过为文本列添加分词和 倒排索引，我们可以支持强大的文本搜索，帮助用户高效地分析日志。这弥合了非结构化日志和结构化指标之间分析能力的差距。
数据摄取与转换
一个能够处理日志的数据库，需要类似于 ElasticSearch 处理器 的转换功能。日志转换包含多个阶段，每个阶段执行数据转换、过滤或信息补充等任务。GreptimeDB 正在实现这样的功能。
或者，我们可以直接从日志中计算指标，而不是转换它们。
例如，确定应用程序中每分钟的错误频率至关重要，错误超过一定数量表明系统存在问题。虽然 GreptimeDB 的持续聚合能力可以处理这些需求，但是我们仍然需要支持处理日志的 SQL 函数。
优化数据压缩和存储
虽然 GreptimeDB 通过架构设计和基于列存储的文件格式，已经实现了远超同类产品的压缩率，但是我们仍需不断改进数据压缩和存储优化算法。这些改进将进一步减少存储空间需求并提高查询速度，确保系统在数据量增长时依然快速响应。
事件处理的生态集成
最后，统一事件数据库的采用有赖于生态系统集成。事件管理革命的一个关键组成部分是改进当前的可视化工具。这些工具必须能够将事件（日志和指标等）表示在统一的视图中。这种整体视角使用户更容易识别不同数据类型之间的关联、趋势和异常。
总结
最后，统一事件数据库的采用有赖于生态系统集成。事件管理革命的一个关键组成部分是改进当前的可视化工具。这些工具必须能够将事件（日志和指标等）表示在统一的视图中。这种整体视角使用户更容易识别不同数据类型之间的关联、趋势和异常。
拥抱这一变革转变需要创新思维和大胆采用先进技术，但其收益将远远超过付出。随着监控系统的不断发展，统一处理日志、指标和事件的方法终将成为行业标准。GreptimeDB 将朝着统一事件数据库的方向不断迈进，为用户提供更高效的事件存储方案和更强大的事件分析能力。
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
专注于 Infra 技术分享 2022-09-23 加入
分布式、高性能、存储计算分离的开源云原生时序数据库
评论