开源服务内部监控系统（二） ganglia简介
在上文 开源服务内部监控系统（一），简单介绍了一下开源监控系统Graphite。本篇将简单介绍一下颇有名气的Ganglia与个人的使用体验。从功能上讲，Ganglia远比Graphite强大。除了监控服务内部状态之外，Ganglia本身就能做到对服务器节点状态(包括CPU使用,load,memory占用,network占用)的整体监控。
分类 数据后台 下的文章
开源服务内部监控系统（一） graphite简介
开源监控系统，大名鼎鼎的有nagois，catis。公司就有运维采用nagios作服务器与服务状态监控，同时结合插件提供邮件短信报警功能；catis通过snmp协议对服务器进行监控，利用RRDTool绘制漂亮的报表供你做性能分析。
这些是运维人员的利器，然而服务开发人员却很少去使用这样的工具，因为它们难以做到对我们开发的服务内部运行状态的监控。假如，你想监控自己开发服务的响应时间，五分钟一个点去绘制报表，或者监控你的服务各个时间内部缓存命中率等信息，这些工具基本帮上不忙。
从批处理到流式计算的罪与罚 ——storm实践总结
近期是对storm做了不少的研究与分享，包括我之前的一篇文章《数据处理神器storm的理解与思考 ——让你的数据化作行云流水》，无论是看官方的文档，还是看其他第三方文献介绍推荐，总会让你觉得各种高端先进，毕竟它代表了一种比较新潮的设计思想，刚开始接触了解的人更会跃跃欲试。然而storm是否真如看上去那么美？还是说，storm只是另一个喜好新鲜事物的开发者把玩的玩物？这些都需要亲自尝试过才会得知。归根到底，我们应该问的问题是：我们的任务是否适合利用storm来实现？
数据处理神器storm的理解与思考 ——让你的数据化作行云流水
大数据之殇
要问storm是什么?简单答复就是：storm对于实时计算的相当于hadoop对于批处理。两者代表的对大数据处理的两种不同方式与态度，即hadoop代表的批处理方式,与storm为代表的流式计算。
先不扯流式计算是个什么鬼。如果说到大数据分析，大家首先直观就会想到hadoop的批处理方式。不管hadoop的图标上面的大象画得有多萌，出现在大家脑中的画面里的，肯定都会有一个庞然大物，好似几个大力巨神在移山搬海。即然是大数据，你自然需要一个能容纳海量数据的存储，为了兼顾效率与可靠，hdfs、hbase这样的工具应运而生。MapReduce的计算框架在帮你降低编程难度的同时，通过以计算能力去求找数据的方式，减少了数据传输的量，但是仍会有大规模的数据需要集中传输，占用大量带宽。由于批处理是对数据的大量数据的集中处理，强大的计算能力必不可缺，甚至有些场景，巨大的内存使用量也是让你望还却步的。可见批处理的处理思想虽然也有很多分布式的概念在，但总体感觉还是在是以大制大。你量大，我就力气要大。这就导致大存储，大带宽，大计算能力，大内存的需求。所以对很多人来说，这位移山大神不是你请得起的。
闲扯kafka mq
本文主要讲解关于kafka mq的设计思想及个人理解。关于kafka的详细信息，大家可以参考官网的文献document:http://kafka.apache.org/documentation.html这是一篇相当不错的文章，值得仔细研读。
第一个问题：消息队列（Message Queue）是干嘛用的？
首先，要对消息队列有一个基本的理解。不少人虽然在用消息队列，却并没有搞清楚消息队列是干嘛的。