17.6　Chukwa与其他监控系统比较

在了解了Chukwa的特点和如何使用之后，大家或许会问Chukwa监控系统与其他监控系统相比有什么特点，下面我们将通过介绍其他监控系统特点来帮助大家了解Chukwa所具有的特点。

Splunk^[3-6]是一个日志收集和索引分析的商业化系统，它依赖于集中的存储和收集架构，不考虑传输日志的可靠性，然而在高级日志分析领域又有这样的需求：为了满足需求，许多大型互联网公司都已经建了大集群监控和分析高级工具。

存在一些专门的日志收集系统，在这些系统当中，Scribe^[7]是一个开源的监控系统，它的元数据模型比Chukwa简单，消息是key-value对，其优点是灵活，但是缺点是要求用户设计自己的元数据标准，这使得用户之间很难分享源代码。Scribe的部署由多个服务器组成，它们被安排在有向非循环图中，其中的每一个节点对是否提交和存储接收信息都是有具体规定的。相比Chukwa而言，Scribe没有被设计成兼容传统的应用，被监控的系统必须通过Thrift RPC服务发送消息给Scribe。这样的优点在于避免在通常情况下的本地写开销，使消息可以无误地传输；缺点是在对不适用于Scribe的数据源进行收集时需要额外的处理。相对而言，Chukwa处理这样的问题就平滑得多。Scribe在传送上的可靠性也弱于Chukwa。一旦数据被提交到Scribe服务器，服务器将负责处理该数据，而这个服务器为了后续传送会长时间地缓存数据。这就意味着Scribe服务器故障可能造成数据丢失，同时也没有一个端到端的传输保证，这是因为原始发送者没有保留一个副本。客户端在向多个服务器发送消息时，如果在发送失败之前没有找到一个正常工作的Scribe Server，那么数据将会丢失。

另一个相关的系统是Artemis，它是由Microsoft研究设计的，用来调试大规模Dryad集群。Artemis是为针对上下文而专门设计的：它只在本地处理日志，使用DryadLINQ^[9]作为处理引擎。该架构的优点是避免了网络中多个副本的冗余，也使系统资源可以重复利用正在分析和已经分析的结果；缺点是如果一个节点坏掉或暂时不能用，查询会给出错误的结果。Artemis没有被设计成使用长期可靠的存储，因为那需要除本地以外的副本；另外，在本地分析对于监控商业服务来说也是不理想的，因为其分析数据功能可能会干扰正在被监控的系统。

还有一些其他监控系统工具，像Astrolabe、Pier和Ganglia^[10-12]被设计成能帮助用户查询分布式系统监控信息的系统。在所有的情况下，每个被监控机器上的客户端都存储了一定量的数据用于答复查询。因为客户端不收集和存储大数据集的结构化数据，所以它们不适合一般目的的编程模型。它们通过在系统中应用一个特殊的数据聚集策略来实现可扩展性，但是这会耗费较大的系统性能。相比而言，因为Chukwa从收集过程中剥离了分析过程，所以每一个部分部署都可以独立地扩展。

Ganglia擅长实时故障侦测，相对而言，Chukwa会有分钟级的延迟，但考虑到系统能在分钟级处理海量数据，并且能够敏锐侦测到运行变化，同时会对故障诊断有所帮助，而工程师一般不能对秒级别的事件有所反应，所以分钟级的延时是被允许的。