背景

我们都知道监控是质量保证很重要的一环，不仅仅是能及时的发现错误。针对特定目标的监控可以帮助我们快速定位问题。那么对于监控的解决方案大家都是怎么做的呢？ 我先来说说我们之前是怎么做的吧。

方案

1. 基于系统级别的监控（CPU，LOAD，内存，网络，磁盘异常），解决方案：运维的同学使用 zabbix 监控
2. 基于进程，端口级别的监控（tomcat 端口，服务端口，系统底层进程），解决方案：我写的一段发包程序监控
3. 基于业务的监控，解决方案：模拟接口测试。我写了一个发包器，定时请求各个服务的接口（http，RPC）。
4. 基于日志的监控（error 监控，关键字监控）。开发的同学规定了所有业务线的标准，然后写的监控服务。也有用 ELK 的

疑惑

1. 首先是环境上的，我们以前有是否监控测试环境的争论。有人的观点是测试环境出现错误不像生产环境那么严重，没必要监控。 我的观点是，针对特定服务的监控有助于提高工作效率。例如以前我们的测试环境管理平台上常年注册了数套环境，上百个服务。一个环境里可能有很多个服务，一个服务挂了普通测试人员很难找到错误，能力差点的就得去找开发解决。其实如果监控告诉他是哪个服务挂了，可能他去重起一下就解决了。
2. 然后是业务监控的争论，关于我写发包器监控 http 和 RPC 接口也有过争论。同样是我赞成监控，有人不赞成
3. 最后是解决方案上的。可以看到专业的监控可能都基于某些开源的解决方案，例如 zabbix，例如 ELK。可是这些都是运维玩得东西，我们以前的测试和开发人员一般都 hold 不住这些。而蛋疼得就在于创业阶段的时候，我们公司压根就没有好的运维，很多都是开发兼职着运维，DBA 啥的。所以在上面的解决方案中日志的监控是我们开发人员写的监控中心。进程，端口和业务的监控是我写的发包器。当时没有特别好的运维同学，我们就用这种方式代替了。这里一个很大的疑问就是各位前辈当时都怎么做的监控？

最大的问题 就是疑惑中的第三点，各位前辈也许能玩转 zabbix，ELK 这些东西，例如思寒。但是我们这些小白该如何搞定监控呢？除了我写的发包器和开发人员作的日志监控中心，还有什么好的办法么？@seveniruby @monkey @doctorq 额，我不记得太多高手的名字哈哈，艾特不了那么多了。大家来讨论一下吧。