事件管理是每个企业管理系统的支柱，因为正是事件的流描述了企业中的各种活动。通过协调或处理这些事件，企业开始被管理。

我们中的一位，Jarra，一直在为一家大型计算机公司承包，该公司正在部署 Unicenter TNG 以监控外包系统。大多数系统都是基于 UNIX 的。众所周知，Unicenter TNG 代理是基于 SNMP 的。在花费大量时间调整代理以接近他决定监控的内容以及如何进行监控之后，他得出了以下结论

我们开始思考如何在保持超薄客户端的同时，在事件管理器中维护它们的状态。那时我们想到了使用我们创造的主要参数“生存时间”。就在那时，EMU（事件管理实用程序）诞生了。发送到 EMU 的每个事件消息都必须设置生存时间。它决定了消息在数据库中保留多长时间后被删除。如果生存时间略大于轮询间隔，则消息将保留在数据库中，直到我们停止重新发送它。换句话说，消息将仅在警报持续期间保留在数据库中。

EMU 是一个全面的事件管理系统，对它可以为您做什么没有任何限制。它利用了 Linux/UNIX 实用程序和脚本语言的全部功能。请记住，软件是为我们服务的，而不是反过来。

事件管理系统通常由四个组件组成：监控管理器、监控代理、事件管理器和事件控制台。

监控代理通常以固定的时间间隔轮询资源（例如文件系统），以便跟踪其状态变化。这些变化会传达给管理器。管理器处理传入的资源状态变化，并将它们转发到事件管理器或更新其维护的业务规则。监控管理器也可以轮询资源状态信息。

资源可以是任何类型的，例如文件系统、进程、磁盘、交换空间、应用程序或已登录用户。

一些监控代理，例如 Unicenter TNG，是围绕 SNMP 构建的。在这些系统中，代理使用陷阱来通知监控管理器状态变化。陷阱使用 UDP 协议发送，因此无法保证其交付。这个缺点必须通过管理器定期轮询来弥补，从而独立于陷阱收集资源状态。

SNMP 代理维护其监控的每个资源的状态信息。此信息通常也由监控管理器维护。代理和管理器都将资源状态存储在数据库中。这是基于 SNMP 的监控的关键设计特征。让我们考虑一个文件系统示例。如果阈值设置为 90%，则在超过此阈值时会发出警报。资源的状态变为 critical（严重）。它必须保持在 critical 状态，直到文件系统被清理干净。然后状态更改回 normal（正常）。

维护资源状态和资源层次结构的需求导致 SNMP 代理编码相当复杂。因此，扩展现有代理并非易事。此外，还需要 C 编码技能和对源代码的访问权限。

监控代理将事件转发到事件管理器，事件管理器通常执行某种事件处理，例如将消息与预定义的字符串匹配，并在匹配的情况下触发操作。Unicenter TNG 提供了一种用于匹配消息并对其执行操作的语言。该语言非常简单，因此不足以执行更复杂的关联和操作。

事件控制台是供管理人员使用的前端。它允许我们“查看”事件。其设计决定了其可用性和效率。代表一个警报的事件应显示为一个事件，而不是在每次轮询时获得一个单独可见的事件。为了轻松跟踪事件，人们力求将其显示表示保持在最低限度。否则，它们会在 IT 人员注意到它们之前滚动出视野。

在企业管理领域，有几个主要的参与者，最著名的是 Tivoli、BMC 和 Unicenter TNG。所有这些都努力争取其他软件和硬件供应商对其 API 的支持。最终，他们努力销售其产品中的所有企业管理组件。我们发现这对最终客户不利。企业管理是关于使用来自独立供应商的最佳产品，这些产品可以轻松集成。这种集成应该通过单个标准 API 或命令行和脚本接口来完成。作为 UNIX 类型，我们更喜欢命令行界面和脚本。这样，我们可以拦截在企业管理组件之间传递的消息。如果需要集成新产品，则可以真正地将其插入。

EMU 是在 Linux 下开发的灵活且易于集成的事件管理工具。它由管理器和代理组成。事实上，它将监控和事件管理器集成到一个程序中。代理是非常简单的脚本，由 cron 调用。这些脚本以固定的时间间隔运行，可能每五分钟一次。每次运行都会扫描其监控的资源，将其阈值与配置文件进行比较。如果超过阈值，则会向管理器发送消息。

EMU 采用生存时间，这被证明是跨代理轮询维护资源状态的一种简单方法。假设一个每五分钟运行一次的代理发现了一个资源问题。在每次轮询时，它都会向管理器发送警报消息。在这种情况下，生存时间将设置为略大于五分钟，即 330 秒。管理器将维护发送的第一个消息及其更新。如果在特定消息的 330 秒生存时间内未收到更新，则消息将被删除，并且假定问题已得到解决。这种简单的方法使我们能够编写简单的代理（最好是脚本），这些代理扫描受监控的资源并在每次轮询时发送其发现。管理器负责其余的工作。事实上，由于 EMU，由几行代码组成的代理可以监控非常复杂的资源。

EMU 提供了 ASCII 和 Tcl/Tk 接口。它们代表一个用于查看事件的控制台。控制台显示所有必要的信息，以使 IT 人员了解最新情况。每个事件都由资源 ID 唯一表示，资源 ID 由受监控系统的hostname（主机名）和 object ID（对象 ID）组成。来自同一资源 ID 的所有更新都被视为一个可显示的事件，而所有单个更新都存储在事件日志文件中。如果在代理特定的生存时间内未收到资源 ID 的更新，则事件消息将从控制台中删除。

资源 ID 的示例有 dumbo.company.com.au:/usr/local、tcc2345:sendmail 和 brk23:tz45。冒号前的第一个字段指定主机名；第二个字段是唯一的资源名称。单个系统上的两个资源不能具有相同的资源 ID，因为 EMU 会将它们视为同一资源。

管理器的输入接口是 emsg，这是一个使用 TCP 套接字向管理器发送消息的小型实用程序。虽然管理器是用 Perl 编写的，但 emsg 是用 C 编写的，以便于在任何受监控平台上轻松部署。事实上，Jarra 目前正在为一家公司承包，以便在 Linux、Compaq Tru64 UNIX、Solaris、AIX、IRIX、Sinix、Ultrix 和 VMS 上安装 emsg。

通过调用输入、删除和输出脚本，集成接口被发挥到了极致。根据消息类型，这些脚本在收到消息、删除消息或处理消息时发出。所有消息属性都作为环境变量传递给脚本。通过这种方式，我们实现了与 Unicenter TNG 事件管理的集成。TNG 控制台控制的区域实际上是 EMU 控制台的精确映像，因此使其更加可用和高效。

EMU 的构建考虑了分布式处理。多个管理器可以在单个或多个系统上运行，从而形成反映公司需求的层次结构。通过 EMU 真正开放的架构，可以轻松地同步多个管理器、构建故障转移配置或扩展其功能。

EMU 由管理器 (gemu)、清理器 (gemucleaner)、emsg 代理 (emsg1) 和控制台/浏览器 (eb, xeb) 组成。管理器和清理器必须在同一节点上运行。清理器进程管理消息过期。为了提供灵活性，只有一个选项传递给 gemu、gemucleaner 和 eb——特定服务器正在运行的端口号。gemucleaner 和 eb 都使用 emsg 向 EMU 发送删除消息。

gemu、gemucleaner 和 eb 使用的配置文件存储在 /usr/local/emu/conf/端口号.cfg 中。配置文件描述了 EMU 数据库（基于 DBM）的位置、日志文件的位置、gemucleaner 的扫描间隔等。每个服务器都将根据端口号访问其自己的配置文件。如果适合您的站点，请将数据库放在 /usr/local/emu/端口号/db 下。每个端口/服务器都将在 /usr/local/emu/端口号 下的名为 logs 和 actions 的子目录中存储日志文件和操作脚本。二进制文件/脚本是共享的，并存储在 /usr/local/emu/bin 中。

配置文件中的一个选项是 emsg 的位置。如果为您的站点上的各个平台编译的 emsg 存储在 /usr/local/emu/EMSG 目录中，您就可以在工作站本地运行 eb（EMU 浏览器/控制台）。这是通过将 /usr/local/emu 目录导出为只读来实现的。此目录将作为 /usr/local/emu 挂载在工作站上。通过创建一个指向 /usr/local/emu/EMSG/emsg.平台 的符号链接 /usr/local/bin/emsg 并将 /usr/local/emu/bin 放在您的搜索路径中，eb 将在本地运行，同时显示来自服务器的事件消息。

根据 EMU 配置要处理的操作，它运行的用户 ID 可以是“emu”或“root”。

对于输入、删除和输出脚本，消息属性（例如，主机名、消息文本）作为环境变量传递。这些可以轻松地用于触发操作。最好有一个启动器脚本，该脚本根据消息属性调用其他特定于任务的脚本。因此，将减少管理器系统上的工作负载。输出脚本可用于选择性地将消息转发到更高级别的 EMU 或第三方系统。输入脚本可用作阻止基于日历处理某些消息的障碍。如果此脚本返回的值大于 0，则消息将被丢弃。删除消息可用于与第三方系统同步。

生存时间可以指定为秒、分钟、小时或 HH:MM 格式的固定时间。生存时间为 -1 表示无限，关联的消息将以反色显示（通过 eb），并且清理器不会使其过期。将消息清除的唯一方法是在控制台上使用删除命令。这允许批处理作业或备份失败等待直到它们被确认。生存时间设置为 0 用于所谓的直通消息。它们不存储在 EMU 数据库中（它们记录在日志文件中），但旨在触发操作。

图 1. 基于 ASCII 的 EMU 消息浏览器

eb 控制台提供了消息的基本显示。新消息以粗体显示以引起我们的注意。消息可以被删除/确认或注释。消息注释缩进显示在每条消息下方。它们用于通知其他人有关详细信息，例如已记录的工作请求。控制台上显示的消息时间是发送第一条消息的系统上的本地时间。它有助于识别问题何时发生。

图 2. 基于 GUI 的 EMU 消息浏览器

EMU 为每天维护一个单独的日志文件。此日志文件存储所有收到的消息，包括其属性，例如主机名、消息文本和类。消息属性用竖线分隔，以便于在脚本中进行处理或上传电子表格。

emsg 的 class 选项可以在许多强大的方式中使用。在监控系统时，最好使用它来识别受监控资源的类层次结构；例如，/LINUX/PRO 指定进程子系统，或 /LINUX/FS 指定文件系统子系统。在某种程度上，它类似于 SNMP OID；但是，emsg 类更加灵活，并且可以在需要时立即创建。公司应制定一份标准文档，详细说明要使用的类格式。它很可能反映他们的业务、资源和升级层次结构。

在纯 SNMP 环境中，消息随 OID 号码一起到达，许多人发现该号码难以理解且不切实际。通过使用类，信息不仅易于阅读，而且还适用于消息过滤、转发、操作等。例如，数据库消息的类可以设置为 /IT/ORACLE。收到此类消息后，DBA 可能会被呼叫来处理问题。

在本节中，演示了一个用于文件系统监控的简单示例代理。考虑了系统的重要方面以及权衡。为了使示例简单，使用的配置文件将忽略每个文件系统的最小磁盘空间限制。此代理的代码如清单 1 所示。

清单 1。

一旦选择了资源，我们必须确定监控资源的方式是否存在周期性。对于周期性监控，我们需要知道应该多久监控一次资源。间隔越短，代理的资源密集度越高。但是，如果选择的间隔太大，我们可能会错过早期阶段的警报。对于我们的文件系统代理，我们将选择五分钟的间隔。

接下来，需要建立生存时间。考虑到五分钟的轮询间隔，我们将选择六分钟的生存时间。请记住，这必须始终大于轮询间隔，以保持事件显示的“连续性”。为了实现定期轮询，代理将从 cron 运行。

一旦有了代理，所有需要做的就是决定它将在哪个用户下运行，并为五分钟间隔的提交创建一个 cron 作业。事实上，清单 1 中的简单代码是一个功能齐全的代理，用于监控具有 10% 警报限制的文件系统。

现在，让我们把一个简单的输出操作脚本放在一起。我们将使用 EMU 监控事件流。为了实现这一点，创建了一个名为 events 的目录。此目录存储文件名反映事件名称的文件。如果文件存在，则表示它描述的事件处于活动状态。一旦文件被删除，事件就结束了。考虑一个 SAP_ORACLE 备份必须在早上 6 点之前完成的场景。如果在早上 6 点之后找到备份事件文件，则表明备份运行超时，或者备份脚本崩溃而没有机会删除该文件。

SAP_ORACLE 备份脚本如下所示

#!/usr/bin/ksh
emsg -n emuserver -p 2345 -t 0 -s 3 -w
icecream\
-c ADD_EVENT -m SAP_ORACLE_BACKUP
# start backup
.
.
.
# backup finished
emsg -n emuserver -p 2345 -t 0 -s 3 -w
icecream\
-c DEL_EVENT -m SAP_ORACLE_BACKUP

创建或删除事件文件的输出操作脚本如下所示

if [ "$E_CLASS" = "ADD_EVENT" ];then
        touch /usr/local/emu/events/$E_MSG
fi
if [ "$E_CLASS" = "DEL_EVENT" ];then
        rm /usr/local/emu/events/$E_MSG
fi

if [ "$E_RHOST" = "dumbo" ];then
        exit 1
else
        exit 0
fi

事件管理和资源监控是一个复杂的主题，因此我们试图仅触及其最重要的方面。我们相信，通过提供一个免费工具，企业事件管理将成为大多数站点的必备工具。Linux 是 EMU 的最佳平台，因为要充分利用其功能，开放且工具丰富的环境是必要的。请访问我们的网站 http://www.jarrix.com.au/ 以获取有关 EMU 前沿的最新进展。通过全球范围内的协作，可以构建有价值的 EMU 代理存储库。如果您有想法或编写了代理，请告诉我们，我们将将其发布在 EMU 主页上。如果您尚未这样做，请下载 EMU 并深入探索企业管理广阔而令人兴奋的领域。

资源