事件加工处理平台的必要性，事件管理平台介绍

本文讲了事件加工处理平台的必要性，事件管理平台介绍。

对于日志分析大家可能并不陌生，在分布式计算、大数据处理和 Spark 等开源分析框架的支持下，每天可以对潜在的数百万日志进行分析。事件加工法

事件分析则和日志分析是两个完全不同的领域，事件分析对实时性的要求更高，需要磨平事件领域中从半结构化到结构化的消息转换管道，实现查询检索，可视化等功能。但是目前针对流式的事件做分析的可用工具非常少，这对于期望使用 Serverless 架构或 EDA（事件驱动）架构的开发者会非常不便。

基于事件的特征，无法追溯事件内容，无法跟踪事件流转，无法对事件做可视化分析成为了事件驱动架构演进的绊脚石。为了解决事件领域中针对流式事件做分析的难题，近日发布了针对事件 / 消息领域的全新分析工具 --实时事件分析平台。下面简要对实时事件分析平台的内容进行介绍。事件加工器

实时事件分析平台简介

实时事件分析平台依托基于事件的实时处理引擎，提供数值检索、可视化分析、多组态分析、事件轨迹、事件溯源和 Schema 管理等能力。实时事件分析平台具有无入侵、无需数据上报，低成本，操作快捷等特点，通过简单的引导式交互，即可快速实现基于事件的流式查询与分析。

实时事件分析平台依托基于事件的实时处理引擎，提供数值检索，可视化分析，多组态分析，事件轨迹，事件溯源，Schema 管理等能力。实时事件具有无入侵，无需数据上报，低成本，操作快捷等特点，通过简单的引导式交互，即可快速实现基于事件的流式查询与分析。

事件处理平台的必要性

回到之前的图，我们增加了适配层和服务器管理的部分。那么增加了监控方式之后，又会变成什么样呢？因为我们的要处理的监控结果，根据监控手段不同也不尽相同。如果是syslog，出来的就是一条信息；如果是SNMP或者gRPC监控，就可能是一个趋势（流量趋势），或者一组指标（内存、CPU利用率）等。这种情况下，我们需要如何处理它们呢？

于是，一般我们就会引入类似软件的分层概念，将信息处理进行层处理。最上层只负责对接运维人员和处理平台，它只以最标准的接口接收下层的事件。而下层则通过适配算法，处理各个平台的信息，将自己对应的平台信息上送。这样做的好处是所有事件都能通过统一的方式处理。而不同平台的事件也可以灵活进行对接。无论是下层增加一个监控通道，还是增加一条告警，都可以进行轻松扩展。加工中心事件

新图是这个样子的，我做了一些优化。同时为了更好的说明事件管理平台可以对接多个系统，我又增加了以前提到的探测平台和巡检平台（其实它们也可归于监控平台的一种，后续再详细介绍）。

事件处理平台的维护工作量

以后我只要介绍一个平台，就会单独说一下需要的一些工作量。在我的脑海里，我觉得再自动化的系统，最终都需要人来维护，特别是平台的草创期。而其中，维护所需要的工作量可说是最枯燥、最多、也是最容易被忽略的。

那么按照之前说的，需要人工的工作量都集中在事件的定义、对接上。它要求我们制定准确的标准以及该事件需要如何处理。这里做的越精确，最终维护的工作量就越好。如果定义不准确，要不重要的告警看不到，要不告警漫天飞处理不完，要不运维的兄弟看到告警一脸懵逼，不知道如何是好。数据加工事件提醒