ELK 架构
static/images/deploy3.png
在互联网项目中，良好的日志监控和分析能保障业务稳定运行，不过一般情况下日志都分散在各个生产服务器，且开发和测试人员无法登陆生产服务器，一般来说只能是运维去取这些日志的数据，当然要是在C/S架构或者有物理实物的，我们也可以通过它本身的日志来查看的，但是针对B/S架构，纯粹的页面的话，仅仅靠F12的话，怕是很难解决问题的，这个时候我们就需要分析后台的服务器日志，看看当时到底做了什么操作，产生了什么请求。甚至这时候就需要一个集中式的日志收集装置，对日志中的关键字进行监控，触发异常时进行报警，协助开发人员查看相关日志。
现在也流行使用ELK来实现这种功能，它是elasticsearch,logstash以及kibana的简称。
日志系统基于elastic stack
ELK 要求本地环境中安装了 JDK 。如果不确定是否已安装,使用的 ELK 是 6.0.0，要求 jdk 版本不低于 JDK8
友情提示：安装 ELK 时，三个应用请选择统一的版本，避免出现一些莫名其妙的问题。
例如：由于版本不统一，导致三个应用间的通讯异常。
建议采用docker进行部署
ELK实战举例
ELK实战举例一，通过ELK组件对Spark作业运行状态监控，搜集Spark环境下运行的日志。经过筛选、过滤并存储可用信息，从而完成对Spark作业运行和完成状态进行监控，实时掌握集群状态，了解作业完成情况，并生成报表，方便运维人员监控和查看。
数据来源可以是各式各样的日志，Logstash配置文件有三个主要模块：input()输入或者说收集数据，定义数据来源；filter()对数据进行过滤，分析等操作；output()输出。input plugin目前支持将近50种，如下表所示：
| Beats | couchdb_changes | Xmpp | eventlog | exec | s3 | file | ganglia | gelf |
|---|---|---|---|---|---|---|---|---|
| Github | Heartbeat | Heroku | http | Sqs | Irc | imap | jdbc | JMX |
| lumberjack | varnishlog | Pipe | snmptrap | generator | Rss | rackspace | RabbitMQ | Redis |
| Sqlite | Elasticsearch | http_poller | Stomp | syslog | TCP | unix | UDP | |
| websocket | drupal_dblog | Zenoss | ZeroMQ | Graphite | Log4j | stdin | wmi | relp |
| Kafka | puppet_facter | Meetup |
数据源搜集到后，然后通过filter过滤形成固定的数据格式。目前支持过滤的类JSON、grep、grok、geoip等,最后output到数据库，比如Redis、Kafka或者直接传送给Elasticsearch。
当数据被存储于Elasticsearch之后，用户可以使用Elasticsearch所提供API来检索信息数据了，如通过REST API执行CURL GET请求搜索指定数据可以使用Kibana进行可视化的数据浏览。另外Kibana有时间过滤功能，运维人员可对某一时间段内数据查询并查看报表，方便快捷。
image.png
ELK对Spark Task 监控
ELK实战举例二，通过ELK组件对系统资源状态监控，使用ELK组件为集群提供日志查询和系统资源监控的例子。
通过各类日志搜集，分析，过滤，存储并通过Kibana展现给用户，供用户实时监控系统资源、节点状态、磁盘、CPU、MEM，以及错误、警告信息等。
(监控机器资源的产生仪表还是建议采用Grafana)
image.png
ELK实战举例三，通过ELK组件对系统负载状态监控
image.png
ELK实战举例四，通过ELK组件对系统日志管理和故障排查。
用户可根据故障发生时间段集中查询相关日志，可通过搜索、筛选、过滤等功能，快速定位问题，从而排查故障。另外，通过对各个应用组件的日志过滤，可快速列举出各个应用对应节点上的Error或Warning日志，从而对故障排查或者对发现产品bug提供快捷途径。
image.png
ELK常见部署架构
2.1 Logstash作为日志收集器
这种架构是比较原始的部署架构，在各应用服务器端分别部署一个Logstash组件，作为日志收集器，然后将Logstash收集到的数据过滤、分析、格式化处理后发送至Elasticsearch存储，最后使用Kibana进行可视化展示，这种架构不足的是：
Logstash比较耗服务器资源，所以会增加应用服务器端的负载压力。
image
2.2 Filebeat作为日志收集器
该架构与第一种架构唯一不同的是：应用端日志收集器换成了Filebeat，Filebeat轻量，占用服务器资源少，所以使用Filebeat作为应用服务器端的日志收集器，一般Filebeat会配合Logstash一起使用，这种部署方式也是目前最常用的架构。
image
2.3 引入缓存队列的部署架构
该架构在第二种架构的基础上引入了Redis缓存队列（还可以是其他消息队列例如Kafka），将Filebeat收集到的数据发送至Redis，然后在通过Logstasth读取Redis中的数据，这种架构主要是解决大数据量下的日志收集方案，使用缓存队列主要是解决数据安全与均衡Logstash与Elasticsearch负载压力。
image
2.4 以上三种架构的总结
第一种部署架构由于资源占用问题，现已很少使用，目前使用最多的是第二种部署架构，至于第三种部署架构个人觉得没有必要引入消息队列，除非有其他需求，因为在数据量较大的情况下，Filebeat 使用压力敏感协议向 Logstash 或 Elasticsearch 发送数据。如果 Logstash 正在繁忙地处理数据，它会告知 Filebeat 减慢读取速度。拥塞解决后，Filebeat 将恢复初始速度并继续发送数据。
image.png
网友评论