1.1 系统监控的过程方法
优秀的监控系统可不是由管理员闭门造车一个个脚本写出来（这样写出来的系统往往如同摇摇欲坠的空中楼阁），而是有条不紊地创建出来，管理员创建这样的系统不仅要获得管理层的支持，还需要对环境有清晰的认识—包括程序和计算环境，毕竟这些环境也是他们运维的。
如果对环境认识不清，会很麻烦。还是举例说明这个问题吧：如何确定哪些是关键系统，需要通过特定监控手段判断出它是否出现故障？但是对如此简单的问题，现实中常常会上演这么一幕：
经理：你把我加入到监控系统中，我想接收所有系统的告警消息。
管理员：所有的？
经理：是的，所有的告警消息。
管理员：呃，好的。
——第二天
经理：昨晚传呼机响个不停，害我一夜没合眼。这意味着什么？
管理员：哦，服务器1的/var分区满了，连接站点Site5的VPN隧道时断时续。
经理：你就不能通知我实际的问题吗？
管理员：这些就是实际的问题。
大学、医院及企业等机构之所以必须要通过HIPPA、Sarbanes-Oxley、PCIDSS、SSAE16等认证，就是为了要掌控其IT的过程方面。当今，多数组织无论规模大小，都制定了完善的应急计划，以应对糟糕事情的发生。灾难恢复、业务连续性、危机计划等工作，都是为了确保运维人员对业务的关键系统有所了解，在危机时刻到来时按照步骤操作就能保障系统的正常运行，或者在系统被破坏时能及时恢复。此外，这些认证也同样可以确保管理层为避免关键系统故障而进行过相关检查：如安装冗余设备或保存离站的磁带备份。
无论出于什么理由，这些应急计划的过程方法似乎都遗漏了监控系统。大多数监控系统都是因为1～2个小型技术团队对此有特殊需求，而作为兴趣项目上线的。通常情况下，多数团队都是各自使用自己的监控工具，无视组织内部的其他监控手段，这里似乎没必要连累别人。虽然这种系统监控方式可以满足个人或小团队的一时之需，但当规模扩大时就会慢慢暴露其弱点—由于早期缺乏规划，使其在发展过程中慢慢变成需求实现的堆积，整个系统将会变得十分脆弱，而用户的组织将会成为最终的受害者。
为了理解为何这个问题如此危险，则要考虑到在缺少过程化实施的监控框架的前提下，数百个关键重要的问题基本上无法回答。比如下面这些问题：
·系统监控所消耗的总体带宽是多少？
·为确保监控系统正常运行，客户端所需的UID是什么？
·路由器或者其他系统依赖于什么？
·在主机和监控系统之间，是否有敏感信息以明文传输？
如果有必要为监控某个进程编写一个脚本，那么也同样有必要思考当系统运行的这个脚本故障时会发生什么，或者是否会出现这样的情况：某人的账户被禁用但他写的脚本还在。治标不治本的方式，是迄今为止最常见的系统监控方式，这种方式带来了太多的问题。
我们前面所举的例子中，其核心问题就是没有标准能够明晰地定义什么是一个“问题”，因为监控系统部署时，这些标准还不存在。我们的经理感觉看不到系统的问题，而为他提供了详细信息的时候，他依然感觉没有获得什么有价值的信息。这就是为什么过程方法非常重要。负责监控项目的人在工作前应当明白：哪些系统对组织的正常运作起到关键作用，管理层对于这些系统正常运行时间的期望值是什么。
明确了上面两个问题之后，就能将策略制定为详细的支持和扩展计划两部分。应当对关键系统的优先级及必要部分进行定义。这并不是说例子中的管理员在服务器1的/var分区满了的时候不应发出通知，而是说，在收到通知的时候，他应该明白该通知是什么意思。管理层是希望他立刻修复还是明天再说呢？还应通知谁呢？如果他不响应会发生什么呢？将这些信息定义明确也对管理层有帮助。只有明确地定义了问题的构成，管理层才能提出自己的见解，比如对哪种告警需要问询，可能更重要的是他们什么时候才能回去睡觉。
小公司可能只有一个兼职的系统管理员，很容易陷入治标不治本的监控怪圈。想象一下，一个只有4个人的公司，还需要依照运维制度执行，这种做法看起来不仅愚蠢还浪费时间，但在小型环境中，事故响应处理制度确实更为重要。通过精心构建的监控系统来贯彻深思熟虑的制度，将会使问题得到快速响应并系统化，否则，小公司一旦出现问题就将面临崩溃。
理想情况下，一个监控系统应当执行组织的制度，而非仅仅将问题反映出来。如果管理层期望有人能在10分钟内查看服务器1的所有问题，那么监控系统应当给我们的管理员提供明确的指示（比如优先级）、确认告警消息的机制以及告警的自动升级——例如，超出10分钟的时候通知其他人。
那么我们如何知道哪些系统是关键的呢？因为公司高层为公司正常运营负全责，所以应该由他们来决定，这也是让管理层参与进来的重要原因。如果你认为这开始听起来像灾难恢复计划的工作，那么说明你已经领先了。灾难恢复的工作主要是确定关键系统从而定义恢复的优先级，规划监控平台的时候也一样。实际上，如果已经制定了灾难恢复计划，那么就参照灾难恢复计划继续吧，因为关键系统已经圈定了。
关键系统虽然已由公司高层确定，但不一定都适用同一个原则，例如：“服务器1上的所有问题要在10分钟内查看”，很可能公司高层只是定义了逻辑实体，例如“邮件系统是关键系统”。所以当关键系统确定后，实施人员应该对每个关键系统的组件进行分析。在这个过程中，一定要保证所有利益相关方都参与进来。邮件系统管理员将能提出一些好的想法，比如邮件系统的组成、邮件监控的标准——如果没有这样的标准，那么系统管理员将不可避免地切换回自己的监控工具。 
上述工作要与尽可能多的团队合作，并获取信息，如果无法制定一个解决方案满足所有人的需求，那么至少要满足所有关键系统监控的特定需求。如果已有自定义的监控脚本，千万别错过，尝试将它们整合到系统中。每个小组都趋向于信任自己已经在使用的工具，所以整合这些工具可以使你得到部分的支持。Nagios在这方面的优势很明显，可以按照自身调度计划和新增规则调用外部监控逻辑。