每天积累一点，一年后你会发现，自己变化很大

一、安装开发环境1.确保安装的java环境是1.6或以上；2.设置JAVA_HOME环境变量（java SDK所安装的目录）    # export JAVA_HOME=..root of Java distribution..    # export PATH=$PATH:$JAVA_HOME/bin3.可以使用以下指令查看java的版本    # java -ver

要想实现获取IP并显示在log中必须先了解log4j自带的两个类MDC和NDC NDC和MDC是log4j用于存储应用程序的上下文信息（context infomation），从而便于在log中使用这些上下文信息。NDC采用了一个类似栈的机制来push存储上下文信息，每一个线程都独立地储存上下文信息。比如说一个servlet就可以针对每一个request创建对应的NDC，储

template的使用 刚开始的时候，每次实验都去改/etc/elasticsearch/elasticsearch.yml配置文件。事实上在template里修改settings更方便而且灵活！当然最主要的，还是调节里面的properties设定，合理的控制store和analyze了。 template设定也有多种方法。最简单的就是和存储数据一样POST上去。长期的办法，就是写成j

elasticsearch的config文件夹里面有两个配置文件：elasticsearch.yml和logging.yml，第一个是es的基本配置文件，第二个是日志配置文件，es也是使用log4j来记录日志的，所以logging.yml里的设置按普通log4j配置文件来设置就行了。下面主要讲解下elasticsearch.yml这个文件中可配置的东西。 配置es的集群名称，默认是elas

flume-ng是时下比较流行的日志收集方案，log4j也是Java领域内常用的日志组件。那有什么简单的办法把他们结合起来呢？背景：通常，我们的应用程序已经在使用log4j来记录日志了，有一天我们的日志需要导入到其他地方（同时文本日志暂时也不想丢），用来分析（hdfs）或者检索（elasticsearch），我们就想到通过一个数据管道来做这件事情，flume似乎是一个不错的选择。

在讲解日志架构之前，先介绍一下我们野狗的业务。我们的业务共有两类SDK，基于两种连接技术。第一类是WebSocket长连接或用Long polling模拟的长连接，另外一类是HTTP REST短连接。大家看这张图，野狗的业务架构分为两层，第一层是接入层，包括NodeJs接入层、Nginx Rest API接入层；第二层是核心业务处理层，包括数据处理和Push server同步推

日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。通常，日志被分散的储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开

自从Hadoop集群搭建以来，我们一直使用的是Gzip进行压缩当时，我对gzip压缩过的文件和原始的log文件分别跑MapReduce测试，最终执行速度基本差不多而且Hadoop原生支持Gzip解压，所以，当时就直接采用了Gzip压缩的方式关于Lzo压缩，twitter有一篇文章，介绍的比较详细，见这里：Lzo压缩相比Gzip压缩，有如下特点：压缩解压的速度

转载地址：http://www.ibm.com/developerworks/cn/data/library/bd-1404flumerevolution/index.html背景Cloudera 开发的分布式日志收集系统 Flume，是 Hadoop 周边组件之一。其可以实时的将分布在不同节点、机器上的日志收集到 hdfs 中。Flume 初始的发行版本目前被统称为 Flum

背景UAE(UC App Engine)是一个UC内部的PaaS平台，总体架构有点类似CloudFoundry，包括：快速部署：支持Node.js、Play!、PHP等框架信息透明：运维过程、系统状态、业务状况灰度试错：IP灰度、地域灰度基础服务：key-value存储、MySQL高可用、图片平台等这里它不是主角，不作详细介绍。有数百个Web应用运行

kafka的优点：kafka的思路很好，充分利用了磁盘顺序写入数据，数据读取也是走顺序读的路子，存储的性能超级好，只要几个节点就能处理大量的消息了；另外，它突破了常规的一些消息中间件由服务端来记录消息消费状态的传统，彻底由客户端自己来记录究竟处理到哪里了，失败也罢成功也罢，客户端本来是最清楚的了，由它来记录消费状态是最适合不过了；kafka的缺点：同一个话题的消息，可以按照业务

Scribe: 是facebook开源的日志收集系统。它能够从各种日志源上收集日志，存储到一个中央存储系统(可以是NFS，分布式文件系统等)上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案.有scribe agent(收集)，scribe(接受数据，topic的数据发送给不同的对象。eg,hdfs)，存储系统组成(scribe支持非常多的store

kafka入门java例子 分布式日志消息队列

转自：对互联网海量数据实时计算的理解1. 实时计算的概念互联网领域的实时计算一般都是针对海量数据进行的，除了像非实时计算的需求（如计算结果准确）以外，实时计算最重要的一个需求是能够实时响应计算结果，一般要求为秒级。个人理解，互联网行业的实时计算可以分为以下两种应用场景：1）  数据源是实时的不间断的，要求对用户的响应时间也是实时的。主要用于互联网流式数据处理。所谓流式数据是

我使用的kafka版本是：0.7.2jdk版本是：1.6.0_20http://kafka.apache.org/07/quickstart.html官方给的示例并不是很完整，以下代码是经过我补充的并且编译后能运行的。Producer Code[java] view plaincopyimport 

Kafka[1]是linkedin用于日志处理的分布式消息队列，linkedin的日志数据容量大，但对可靠性要求不高，其日志数据主要包括用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）。 当前很多的消息队列服务提供可靠交付保证，并默认是即时消费（不适合离线）。高可靠交付对linkedin的日志不是必须的，故可通过降低可靠性来提高性能，同时

log4j2[2.1] log4j2的配置文件格式可以是JSON,或者XML。 一般是在classpath路径中查找log4j2.json，或者log4j2.xml， 或者也可以通过系统参数来设置配置文件，比如（一般这个用在命令行启动的应用）： Java代码  -Dlog4j.configurationFile=path/to/log4j2.xml