elk架构

（1）Kafka：接收用户日志的消息队列。
（2）Logstash：做日志解析，统一成JSON输出给Elasticsearch。
（3）Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。
（4）Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。

 

 

在最简范式下将日志处理过程展开，在分布式节点的日志源端（服务器、网络设备、应用中间件）部署agent，将日志发送到集中点。agent的形态是开放型，可以是syslog、logstash等各类工具，在agent内部也遵循一个intput-filter-output的范式。agent本身也可以对日志进行处理，将过滤任务分发到各节点内部，对降低集中节点资源消耗有很大帮助。

agent的日志输出有两条路径：一条是直接发送给日志过滤器，过滤器按照规则对日志进行格式化；另一条是与过滤器进行解耦，异步地将日志消息传递到中介消息队列中，等待过滤器获取日志。

agent与过滤器直接通信存在一定的弊端，由于过滤器承担了消息处理的职能，在消息量过大的情况下，消息处理不及时很可能造成发送过来的日志丢失。另外，由于agent与过滤器之间的同步关系，agent每次发送消息都需要等待过滤器返回，当过滤器缓慢时会影响到anget端的收集。在架构中引入MQ消息队列就是为了避免这两个问题。agent的种类很多，在它的output模块允许的情况下，我们将消息优先放入消息队列中，过滤器主动从消息队列中获取消息。

过滤器承担着主要的日志格式化工作，处理完毕后可以链接到监控管理平台，但最主要的还是将日志传递到搜索引擎平台，进行索引、存储。最后用户从前端图形界面访问，与搜索引擎关联，获取查询数据。在图形化展示方面，需要按照用户的条件组合对数据进行检索展示，固化常用的报表。

日志集中管理架构的组成模块是固定的，但架构本身是弹性的，随着IDC物理环境的变化而变化，在每一个环节上，分散的agent、分布式的消息队列、过滤器可以分区域部署、自伸缩扩容，最终的数据流向是存储到唯一的搜索引擎以供用户查询。