最近几个月都在忙着日志系统的架构。设计出一套比较高可用，高吞吐的日志系统，并能符合我们的业务需求。最终的架构如下：
研发会把业务日志写成json格式，然后写入本地的文件，我们在服务器上安装logstash软件，负责采集，由于是json格式，所以指定codec=》json格式，这样能大大提高logstash的采集速度。
由于可能担心日志文件的巨大，后续处理不过来，所以我们设置了一个中间件kafka，临时存储文件，kafka真的很好用，主要得益于他的日志文件存储，一段时间又可以自动删除。又引入了Partition 和 cousumer group的概念。partition 的出现 对消息的顺序不是要求那么高的话，可以分成多个partition供多个消费者使用。大大的提高消费速度。cousumer group 可以让 queue 变成 广播，一个消息被多次消费。这样可以解决消息的多次利用存储。
hadoop 主要做整个日志平台的 文件存储。收集所有的日志并以文件格式存储。在hadoop存储的问题我主要是遇到了，json格式的业务日志跟系统日志如果存储在一起，目前的方案是通过从kafka分不同的topic去实现，当然后来发现也可以通过字段过滤去解决。现在我把日志分为 rizhi 和 xt_rizhi。rizhi存储的都是json 而 xt_rizhi主要存储的是非json格式的jboss日志。
elasticsearch 主要是做我们的搜索引起使用。方便我们以后对线上业务的统计。由于日志巨大，可能日志保存的天数会比较短。
influxdb 主要是为了记录研发要求的 落库的数据，influxdb 无论性能上 还是 跟logstash 配合上 都比mysql更好。主要是通过字段的过滤，写入指定数据。
output {
if [method] == “listByUser” {
# stdout {
# codec => rubydebug
# }
influxdb {
# data_points => {
# “host” => “%{host}”
# “hostname” => “%{hostname}”
# “uri” => “%{uri}”
# “timestamp” => “%{timestamp}”
# “remoteAddr” => “%{remoteAddr}”
# }
use_event_fields_for_data_points => true
exclude_fields => [“@version”,”@timestamp”,”kafka”]
allow_time_override => true
measurement => “%{logger}”
host => “10.25.85.52”
db => “test”
user => “test1”
password => “test123”
codec => “json”
# exclude_fields => [“@version”,”@timestamp”]
}
}
}
这样下来也满足研发和运维的需求，所有的日志汇总，运维做一下简单的分析，文件全部存储在hadoop。放一部分数据到influxdb防止以后要查看使用。