Chukwa 是一个开源的用于监控大型分布式系统的数据收集系统。它构建在 hadoop 的 hdfs 和 map/reduce 框架之上的，继承了 hadoop 的可伸缩性和鲁棒性。Chukwa 还包含了一个强大和灵活的工具集，可用于展示、监控和分析已收集的数据。
Chukwa不是什么？
- Chukwa不是一个单机系统，在单个节点部署一个Chukwa 系统基本没有什么用处，Chukwa是一个构建在hadoop基础上的分布式日志处理系统。换言之在搭建Chukwa环境之前需要先构建一个hadoop 环境,然后在hadoop的基础上构建Chukwa环境。
- Chukwa 不是一个实时错误监控系统，在解决这个问题方面ganglia、nagios等等系统已经做得很好了，这些系统对数据的敏感性都可以达到秒级。 Chukwa分析的是数据是分钟级别的,它认为像集群的整体 cpu 使用率这样的数据延迟几分钟拿到不是什么问题。
- Chukwa不是一个封闭的系统，虽然Chukwa自带了许多针对hadoop集群的分析项，但是这并不是说它只能监控和分析hadoop。 Chukwa提供了一个对大数据量日志类数据采集、存储、分析和展示的全套解决方案和框架，在这类数据生命周期的各个阶段 Chukwa 都提供了近乎完美的解决方案。 </ul>
- Chukwa可以用于监控大规模(2000+ 以上的节点, 每天产生数据量在T级别) hadoop 集群的整体运行情况并对它们的日志进行分析。
- 对于集群的用户而言:Chukwa展示他们的作业已经运行了多久，占用了多少资源，还有多少资源可用，一个作业是为什么失败了，一个读写操作在哪个节点出了问题。
- 对于集群的运维工程师而言:Chukwa展示了集群中的硬件错误，集群的性能变化，集群的资源瓶颈在哪里。
- 对于集群的管理者而言:Chukwa展示了集群的资源消耗情况，集群的整体作业执行情况，可以用以辅助预算和集群资源协调。
- 对于集群的开发者而言:Chukwa展示了集群中主要的性能瓶颈，经常出现的错误，从而可以着力重点解决重要问题。 </ul>
- agents : 负责采集最原始的数据,并发送给 collectors
- adaptor : 直接采集数据的接口和工具,一个 agent 可以管理多个 adaptor 的数据采集
- collectors 负责收集 agents 收送来的数据,并定时写入集群中
- map/reduce jobs 定时启动,负责把集群中的数据分类、排序、去重和合并
- HICC 负责数据的展示 </ul>
- 使用 mdl 语言把集群上的数据抽取到mysql数据库中，对近一周的数据完整保存，超过一周的数据按数据离现在的时间长短作稀释，离现在越久的数据所保存的数据时间间隔越长。通过mysql来作数据源展示数据。
- 使用hbase或类似的技术直接把索引化的数据在存储在集群上。 </ul>
- Collector将Agent发送的数据写入到logs*.done。同 时会将文件输出到postProcess目录下。否则如果操作失败，则会将输出结果移动到dataSinkArchives/InError /[yyyyMMdd]/*/*.done。
- PostProcessManager 每隔几分钟执行一次，负责将postProcess目录下的文件进行合并，去重，排序等操作。运行完毕之后，将数据会写入到 repos 目录。目录下会按照cluster name,data type等分目录存放。
- 在以上的操作中，Demux将是我们下来要关注的内容，很多的数据处理都会在这里进行。我们也可以自己定义自己的数据类型的Demux processor。 </ol>
Chukwa 是什么
Chukwa的系统架构
Chukwa旨在为分布式数据收集和大数据处理提供一个灵活、强大的平台，这个平台不仅现时可用，而且能够与时俱进的利用更新的存储技术（比如 HDFS、Hbase等），当这些存储技术变得成熟时。为了保持这种灵活性，Chukwa被设计成收集和处理层级的管道线，在各个层级之间有非常明确和狭 窄的界面，下图为Chukwa架构示意图：
Chukwa有以下5个主要组成部分：
相关设计
1、adaptors 和 agents
在每个数据的产生端(基本上是集群中每一个节点上), Chukwa 使用一个Agent来采集它感兴趣的数据，每一类数据通过一个Adaptor来实现, 数据的类型(Data Model)在相应的配置中指定。默认Chukwa对以下常见的数据来源已经提供了相应的Adaptor：命令行输出、log文件和http Sender等，这些Adaptor会定期运行(比如每分钟读一次df的结果)或事件驱动地执行(比如kernel打了一条错误日志)。如果这些 Adaptor 还不够用，用户也可以方便地自己实现一个Adaptor来满足需求。为防止数据采集端的Agent出现故障Chukwa的Agent采用了所谓的 ‘watchdog’机制，会自动重启终止的数据采集进程防止原始数据的丢失。另一方面，对于重复采集的数据,在Chukwa的数据处理过程中会自动对它 们进行去重，这样就可以对于关键的数据在多台机器上部署相同的Agent从而实现容错的功能。
2、collectors
agents采集到的数据是存储到hadoop集群上的。hadoop集群擅长于处理少量大文件，而对于大量小文件的处理则不是它的强项，针对这一 点Chukwa设计了collector这个角色，用于把数据先进行部分合并再写入集群，防止大量小文件的写入。另一方面，为防止collector成为 性能瓶颈或成为单点产生故障， Chukwa允许和鼓励设置多个collector。agents随机地从collectors列表中选择一个collector传输数据，如果一个 collector失败或繁忙就换下一个collector，从而可以实现负载的均衡。实践证明多个collector的负载几乎是平均的。
3、demux 和 archive
放在集群上的数据是通过map/reduce作业来实现数据分析的。在map/reduce阶段，Chukwa提供了demux和archive任 务两种内置的作业类型。demux作业负责对数据的分类、排序和去重，在agent中提到了数据类型(DataType)的概念，由collector写 入集群中的数据都有自己的类型，demux作业在执行过程中通过数据类型和配置文件中指定的数据处理类执行相应的数据分析工作，一般是把非结构化的数据结 构化，抽取中其中的数据属性。由于demux的本质是一个map/reduce作业，所以我们可以根据自己的需求制定自己的demux作业进行各种复杂的 逻辑分析。Chukwa 提供的demux interface可以用java语言来方便地扩展。而archive作业则负责把同类型的数据文件合并，一方面保证了同一类的数据都在一起便于进一步分 析, 另一方面减少文件数量减轻 hadoop 集群的存储压力。
4、dbadmin
放在集群上的数据虽然可以满足数据的长期存储和大数据量计算需求但是不便于展示，为此Chukwa做了两方面的努力：
到 Chukwa 0.4.0 版本为止, Chukwa 都是用的第一种方法，但是第二种方法更优雅也更方便一些。
5、hicc
hicc是Chukwa的数据展示端的名字，在展示端Chukwa提供了一些默认的数据展示widget，可以使用“列表”、“曲线图”、“多曲线 图”、“柱状图”、“面积图式展示一类或多类数据给用户直观的数据趋势展示。而且，在 hicc 展示端对不断生成的新数据和历史数据采用 robin 策略防止数据的不断增长增大服务器压力并对数据在时间轴上“稀释”可以提供长时间段的数据展示。从本质上hicc是用jetty来实现的一个web服务 端，内部用的是jsp技术和javascript技术，各种需要展示的数据类型和页面的局都可以通过简直地拖拽方式来实现，更复杂的数据展示方式可以使用 sql语言组合出各种需要的数据。如果这样还不能满足需求动手修改它的jsp代码就可以了
6、其它数据接口
如果对原始数据还有新的需要用户还可以通过map/reduce作业或pig语言直接访问集群上的原始数据以生成所需要的结果。Chukwa 还提供了命令行的接口，可以直接访问到集群上数据。
7、默认数据支持
对于集群各节点的cpu使用率、内存使用率、硬盘使用率、集群整体的 cpu 平均使用率、集群整体的内存使用率、集群整体的存储使用率、集群文件数变化、作业数变化等等hadoop相关数据，从采集到展示的一整套流程Chukwa 都提供了内建的支持，只需要配置一下就可以使用。可以看出，Chukwa从数据的产生、收集、存储、分析到展示的整个生命周期都提供了全面的支持。
了解了主要部件后，也许有读者已经在脑海中有了大致的数据流程图了。是的，它就是这么简单：数据被 Agent 收集，并传送到 Collector，由 Collector 写入 HDFS，然后由 Map-Reduce job 进行数据的预处理。
内部数据处理时序介绍
