为什么要做监控
线上发布了服务，怎么知道它一切正常，比如发布5台服务器，如何直观了解是否有请求进来，访问一切正常。
当年有一次将线上的库配置到了Beta，这么低级的错误，排错花了一个通宵，十几个人。
某个核心服务挂了，导致大量报错，如何确定到底是哪里出了问题。
SOA带来的问题，调用XX服务出问题，很慢，是否可以衡量？
由于业务系统数量大，每天都会产生大量的系统日志和业务日志，单流式业务的一台服务器产生的日志达400M 想直接查看内容打开可能几分钟，而且内容之多根本无法查看，给开发和运维带来诸多不便，现业务都是分布式的，日志也是分布在每台服务器上，所以查看日志和统计更是效率低下。实时收集分布在不同节点或机器上的日志，供离线或在线查阅及分析来提升工作效率的需求异常迫切，在此背景下，特对公司统一日志平台进行初步架构设计。
在信息化时代，日志的价值是无穷的。为了对系统进行有效的监控、维护、优化、改进，都离不开对日志的收集和分析，接下来我们来看看秉着“短平快”的互联网精神，构建的这套适合现有业务系统的统一日志平台，总体分为业务日志监控平台和软硬件服务监控平台。
业务日志平台总体设计以上是最终的一个最终的一个架构规划，统一日志监控系统负责将所有系统日志和业务日志集中，再通过flume或logstash上传到日志中心(kafka集群)，然后供Storm、Spark及其它系统实时分析处理日志，或直接将日志持久化存储到HDFS供离线数据分析处理，或写入ElasticSearch提供数据查询，或直接发起异常报警或提供指标监控查询。
根据现有业务量来看，以上架构有点“重”，可以作为以后的目标，现阶段来说可以参考以下架构：
以上内容皆以配置为主，对现有业务没有影响，针对于Windows环境可以用FileBeat监控本地日志全量、增量的上传日志，对于一些稳定的日志，比如系统日志或框架日志(如HAproxy访问日志、系统异常日志等)，通过rsyslog写到本地目录local0，然后logstash根据其配置，会将local0中的增量日志上传到日志中心。Java环境下可以采用log4j直接发送到Logstash。
日志处理层可以在Logstash中对日志作简单的分类加工处理再发送出去。
我们可以将日志聚合，根据业务不同，建立不同的索引，存入ElasticSearch提供查询。 发现异常日志时，发往监控中心，向对应的业务方发起报警，发现和预发问题的实时性提高了。统计一些访问日志或调用日志等指标信息，发往监控中心来掌握相关调用趋势。调用链开始做起来了，系统性能瓶颈一目了然了。
日志存储层ElosticSearch中按照不同业务建索引主题（数据库），业务里面再按照需求建类型（表），不需要的历史数据可按需要持久化到HDFS，以减少ES的压力。
展示层KibanaKibana是ELK中的组件，是一个针对Elasticsearch的开源分析及可视化平台，用来搜索、查看交互存储在Elasticsearch索引中的数据。使用Kibana，可以通过各种图表进行高级数据分析及展示。
Kibana让海量数据更容易理解。它操作简单，基于浏览器的用户界面可以快速创建仪表板（dashboard）实时显示Elasticsearch查询动态。
Kibana可以非常方便地把来自Logstash、ES-Hadoop、Beats或第三方技术的数据整合到Elasticsearch，支持的第三方技术包括Apache Flume、Fluentd等。
监控ES的整体健康状态