企业IT信息管理人员大多是多重身份，他可能既是管理者又是具体执行者，不可能24小时紧盯监控页面，实时对所有运行监控参数进行分析。管理软件如果能提供智能分析，帮信息管理人员及时预警故障隐患，才算是真正起到作用。BTIM系统从以下四个方面做了重点考虑：
事件的发现的范围是不是够广阔，作为重要的事件管理功能拒绝漏网之鱼是走出成功的第一步。
是否有能有一个高效而准确的发现机制，对于事件发现来说，高效即时是一个很重要的指标，但是因为要即时的发现实件而产生了大量的误高或者无用的垃圾事件，这样的高效即时的发现就没有意义了。怎么去平衡即时和准确是事件发现机制的一个关键点。
事件发生后需要输出，需要告诉相关的人员。事件输送的时间、方式、对象等这些事件发生中需要关注的信息点是否能灵活的组合和配置是需要关注的。
事件的后续处理也应该纳入事件管理的考虑范围。对于事件管理来说，如果系统能帮忙判断一些故障，能自动定位某些故障点，甚至是能自动的解决一些常见的问题，这样的处理方式就比较完美。最后，事件一定要和流程管理相衔接，和ITIL流程管理兼容，具有ITIL的管理思路。
1 事件广泛监控
对于事件来说，首先我们要关注的是事件收集的广泛性。对于业务的事件来说，从上面的分析我们也可以看的出，没有任何的事件可以说完全的不重要可以忽略不理会的。那既然是这样，我们就要把所有的和业务系统相关的事件进行收集，纳入到系统层面进行分析考虑，这样也就要求对于事件的收集要达到事无大小，一览无余的地步。
事件收集的对象包括了从底层的网络设备、线路、流量、到主机的硬件、端口、基于主机上的操作系统、数据库、中间件等等。
然后我们需要考虑的事件收集的是手段问题，在这么广泛的事件收集中我们可以通过以下多种方式来支持事件的收集。
支持Event Log、Syslog。Window主机的Event Log和Unix、Linux主机的Syslog反应了系统的运行状况，可以及时反应系统运行中的问题，系统支持Event Log和Syslog日志的关键字检索功能，用户可以定义自己关心的关键字，当日志中出现相应的关键字时，系统产生告警。
无代理监控技术是真正的无代理，不需要在被管理的主机或者应用上安装任何的软件。代理技术采用多种采集方式达到对网络设备、机房环境、主机、应用和数据库的监控，这些技术包括：
WMI
PerfMon
HTTP/HTTPS
SQL
Ping
DNS
SNMP
Secure Shell (SSH)
TELNET
JDBC
ODBC等
2 事件发现机制
对于事件发现的机制，目前我们使用的比较多的，也是比较常见的技术有两种，一种是被动的接受，把所有的事件先接收下来，然后在进行分析。另外一种是主动分析，把需要进行分析的事件先安排好，让需要分析的事件按照计划进行采集。下面我们比较细致的来解释这两种事件机制的优点和缺点。
2.1、被动事后分析模式
被动事后分析模式是指：所有接收的事件都是系统被动的接受的，主动发出的在设备一方，这种工作模式比较通常的是设备以syslog或者Trip的方式把设备上所有产生的海量事件全部发送给接收端，接受端首先要有一个海量的存储空间来放下这些事件信息，而且需要若干台服务器来进行密集的运算来分析这些事件，把这些事件进行分析、压缩、过滤，关联等等动作。
这种事件处理的模式典型的优点就是接受的事件全，基本上发生过的事件都没有遗漏的接收了下来。有利用后期的分析，特别是对一些不可预知事件的分析。但是缺点也是很明显的对于投资特别大，随着设备增加，会对网络的负荷，存储空间的大小，事件处理服务器的运算能力都有极高的要求。而且这类分析模式由于事件的杂乱性，后期的分析效率比较低，容易造成事件风暴来困扰管理人员。
这类事件处理方式主要用于对于事件需要进行精细分析，而对于投资并不敏感的用户，例如：电信运营商等。
2.2、主动分析事件模式
主动分析事2.件模式是指：在系统预先建立好事件的发现模式，根据管理人员的要求，主动的去采集一些事件，然后进行分析。这类处理模式发起端通常在事件处理中心以SNMP轮询的方式通过一个或者多个线程来进行事件采集。把这些数据采集回来以后，然后再由事件中心进行事件分析，关联，压缩等等动作。
这类事件处理模式的优点是，事件的产生量小，对于资源的效率量大大的降低。而且由于是预先建立的事件发现模式，对于分析这些事件相对效率提高很多，最明显的优点是简单、明确。这类事件处理模式的缺点恰恰是被动事后分析模式的优先，由于是预先定义的事件采集模式，并不是所有的事件都进行采集，这样就有可能会产生遗漏。
这类事件处理方式主要用于对于事件需要进行广度分析，对于事件的类型并不是太复杂，基本通过工作中的经验推断一些事件的发生的。例如：企业用户等。
3 灵活的事件输出
事件发生后，的事件输出最为重要的是通知相关的人员，这是整个事件输出的首要任务。在这个前提下事件中心应提供灵活的报警定义，可满足各种业务需求。管理人员可以根据监控需要，定义故障事件是否触发报警、发送给哪个角色或人员、以及发送的时间段、发送的内容等等 。用户还可设置多种报警方式，当事故发生时，不仅以传统方式习惯的弹出式窗口方式来进行通知用户，还可通过短信、语音、邮件等多种报警方式，全面及时的通知用户。这样就覆盖到客户的对于事件输出的个性话需要，管理人员可以自由的组合某个事件告警可以在不同的时间范围内，通过不同的输出方式，给到不同的人员，显示出不同的事件描述语句。甚至是在管理人员在未确认接受到事件的情况下，事件能定时重复送达，以保证相应的管理人员能收到事件内容。
4 事件的后续处理机制
4.1、提供处理意见
事件通知到管理员后能，按照通常的做法只是提高一个事件的内容就完成了事件告知的任务，但是从管理的角度上来说，都经常说要提供一个知识库之类的说法，但是这种知识库都是结合在系统中的，还需要管理人家进行检索和查询并进行分析后才能找到相应的解决方案。但是我们换一个思路来想问题，如果在事件的告知的同时系统就能够提供出相应的事件处理意见将会为管理人员节省大量的时间，能够更高效率的处理问题。
4.2、主动定位故障位置
当我们了解到业务服务发生故障的时候，首先我们是想是不是能快速的进行故障的定位处理，只有故障进行了准确的定位。接下来才有可能谈起故障的排除和恢复。
对于故障的定位，我们最长见的做法可能是直观的看告警信息，当然这对于一些比较容易判断比较简单的故障可以这样看待。例如：某设备的温度过高，直接的处理办法就是调整这个区域的空调的温度控制值，以达到合理的工作范围。这样的判断是最简单的，但是不幸的是经过统计这样简单的判断在整个事件处理的比例里面占有不到15％。
更多故障是无法通过告警信息来进行判断的，是要通过管理人员的经验和排查才能解决这些看似乎简单的问题。
4.3、自动启动应急预案
事件的发生是复杂的，但是又是具有一定的规类的。在实际的运维工作当中发现在一些特定的事件发生后，只要制定相应的结合应急预案就能在第一事件内通过一些自动化的手段来快速的恢复服务的问题。
特点：
支持监控密度可更改的各类信息点监控，包括所有可访问的SNMP MIB信息点，包括所有BTIM 支持的各类应用、主机、中间件、数据库参数点
支持针对性附加解决方案，支持定义事件的影响度、紧急度
提供接口规范，支持第三方事件检测程序的联入
支持事件的过滤
支持各类检测手段的组合判断，预置事件分析方法
通过告警关联与抑制，提供更广泛的层次化高级智能事件分析能力
支持多渠道（语音、短信、E_mail、屏幕、第三方程序）的故障告警输出，不同对象、不同时段通过不同渠道可以得到附加处理意见的不同事件告警信息
支持事件直接驱动预置处理，联动故障断网隔离处理
除支持门限式事件检测外，BTIM 支持基线告警管理
