By

这次聊聊mesos+k8s的集中化日志方案。日志通常是由许多文件组成，被分散地储存到不同的地方，所以需要集中化地进行日志的统计和检索。

集中化日志架构

集中化日志架构包括这几个阶段：收集、传输、存储和分析，有时候也许会涉及告警。

  • 收集：通常以代理的形式运行在各个节点上，负责收集日志。我们希望能尽可能地实时，因为当我们重现一个bug的时候，不会愿意再等上好几分钟才能看到当时的操作日志。
  • 传输：把收集到的日志传给存储。这个阶段关注的是可靠性。万一日志丢失的话那可就麻烦了。
  • 存储：按需选择用什么形式的存储。比如要存多久时间？要不要支持扩容？找历史数据的可能性有多大？
  • 分析：不同的分析工具适用于不同的存储。这个也包含可视化的分析及报表导出等等。
  • 告警：出现错误日志的时候通知运维人员。最好还能聚合相同的错误，因为作为运维来说，实在是不想看到同一个类型的错误不停地骚扰过来。

传统日志方案

商业方案splunk几乎拥有市面上最丰富的功能，高可用，可扩展，安全，当然很复杂也很贵。还有一个试图成为splunk的SaaS版本Sumo Logic，包含精简的免费版和收费版。免费方案中比较著名的有Elasticsearch公司（现在叫Elastic公司）的ELK和Apache的Flume+Kafka+Storm。

ELK是Elastic search、Logstash和Kibana三个开源软件的组合。其中logstash可以对日志进行收集、过滤和简单处理，并将其存储到elastic search上，最终供kibana展示（和上一篇的监控很类似啊）。这套方案可以参考新浪的实时日志架构。这一本ELKstack 中文指南也写得非常详细。

Apache的flume扮演者类似logstash的角色来收集数据，storm可以对flume采集到的数据进行实时分析。由于数据的采集和处理速度可能不一致，因此用消息中间件kafka来作为缓冲。但是kafka不可能存储所有的日志数据，所以会用其他的存储系统来负责持久化，如同样由Apache提供的HDFS。这套方案可以参考美团的日志收集系统架构。如果需要对分析后的结果持久化，还可以引入mysql等数据库。

kubernetes方案

虽然也支持logstash，Kubernetes官方使用的是fluentd（有文章称logstash侧重可扩展性而fluentd侧重可靠性）。比方说我们要收集tomcat的日志，可以在tomcat的pod里增加一个fluentd-sidecar-es的辅助容器，指定tomcat容器的日志文件地址，再指定elastic search服务的位置（对于fluentd-sidecar-es这个特定容器来说，是写死在td-agent.conf文件里的），fluentd便会自行将日志文件发送给elastic search。至于kibana，只需指定elastic search的url就能用了。这是kibana的日志页面：

还可以根据日志来配置各种图表，生成很炫的Dashboard。这个是官方的demo：

如果日志不是写到文件系统，而是写到stdout或者stderr，那么kubernetes直接就可以用logs命令看到，就不需要这一整套了。但是一个复杂的web应用，通常还是有复杂的日志文件配置的。