监控本来是为了方便运维维护游戏服务器，当服务器出现异常时能够及时提醒，并能够监视服务器的一些相关情况。然而需求是在不断变更的。这句话一点都没错，写这个工具的时候尤其如此了。
需求迭代，出现的很多情况开始都没有考虑清楚。对于需求做如下的罗列。
迭代一：
刚开始，运维说的比较简单，只要在服务器的机器上面写一个监控，能够监控服务器挂没挂，能够在挂的时候给邮箱发一封邮件。不就是一个监控工具嘛，简单！只要写个工具在，同一个物理主机上跟着服务器一起启动一个就行了，一旦服务器挂掉就能告警发送邮件，并且应运维要求还做了一个小界面供查看。监控了，游戏服务器进程，在线人数，ClientSession数，数据库连接情况等。由于游戏服务器的代码和运维之间是不能有交叉的，并且公司的运维只是保证一下防火墙策略，网络质量，网络资源的分配等。他们直观很抵触直接自己解决，而是甩给了游戏服务器的我们。
迭代二：
运维的需求变更了，因为游戏服务器会部署在多个物理主机上，需要做一个代理端来监视所有物理主机上的服务器运行情况并预警，并且能够测试游戏服务器所在的物理主机与数据库（另外一台服务器了）之间的连接情况。然而游戏服务器是运行在，windows上的，代理所在的系统是一个Linus系统。我就简单实现了如下这种：
迭代三：
这次大致的框架是有了，但是运维还是不很满意。他们的需求又发生了变化。这次主要是功能上。
1、邮件预警的及时性和错误原因
2、可以对游戏服务器一次挂掉实现跟踪，从发送邮件提示游戏服务器异常，到游戏服务器解决能够区分提示提醒。并且运维是多人轮班的，如果能够跟踪解决者更好，并发送邮件提醒其他人。
3、多台游戏服务器所在的物理主机，监控端程序配置简便化
4、Windows下做的UI界面不够美观，并且Linus平台操作存在问题需要调整
5、游戏服务器连接数据库方式不再是ODBC了，调整验证手段！
6、可以实现简单的游戏逻辑操作，查看游戏服务器是否运行正常，对于游戏服务器进入死循环挂死没有很好的监控到，如果能够测试一些游戏功能更好。
这个时候，这已经不是一个监控工具了，逐步向一个监控系统迈进了。但这还不是最恐怖，最恐怖的是还有个迭代四！
迭代四：
当我最终直到他的物理主机的分布模型的时候，我就觉得还是开始想太简单了，还是运维想的太神奇了！由于游戏是在韩国上线，所以游戏服务器是在韩国的物理机上，代理端是在国内的一台机器上，然而对代理端的查看是在另外一台机器上。并且由于涉及到国际通讯的不稳定性，有时候韩国的物理主机可能和国内的机器连接失效，但是其实本身游戏服务器所运作的网络没有什么问题。除了要保证迭代三，提到的功能外，还有如下的一些：
1、对于代理端和国外物理主机之间网络质量进行预警并能够邮件提醒。
2、要保证游戏服务器做停服关服维护的时候，能够不再提醒异常
3、增添删减游戏服务器（开服的时候）的时候，能够很方便的配置
4、能够检测本地网络质量
5、提供分布式操作的要求（不紧要），可以实现一个基于Linux操作端的操作就可以了
6、可以分别对单个物理主机的游戏服务器的监控进行设置和操作
7、还要保证游戏服务器的独立性，不能占用很大的带宽量
8、对于检测周期等能够进行设置，并设置重查的轮训次数设置。不同的检测数据需要做出区分，有的是立即告警，有的则是需要检测几次仍然失败再告警发送邮件。
感觉这要是说监控系统估计也不太合适了，一个典型的分布式监控系统倒是真的。
