第9篇:微服务的log(elk)

严格来说日志的ELK 已经是个很"古老"但非常有用的技术, 但居然有公司还是不用 我在某个公司的经历是: 该公司部署了4个tomcat 形成集群, 然后线上排查问题要找log的时候, 只能一个个机器去登录, 或者写脚本down下来 要求上ELK, 被拒绝

作为程序员, 不能无视业务尝试新技术, 但对于一些已经非常成熟能够提升工作效率的玩意, 那肯定要上啊, 所以我不知道那个负责人到底在想啥

ELK 三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana , 它们都是开源软件, 组合而成来形成中央式日志查询架构 这样在各个服务器的日志都会汇总到某个机器, 方便统一的查询和其他处理 像微服务这种随意部署几十个服务集群的, 上ELK之类系统理所当然

(其中, 真正收集log的软件是 filebeat, 确切的名字应该是 EFLK)

我的目标是总结在spring cloud 里集成 ELK, 所以物理机上怎么装就不写了, 网上能找到 这里总结怎么用docker 来完成任务

工程位于: >传统的日志分析是直接从日志文件中 grep / awk 日志信息，这种方式文本搜索慢，难以多维度查询。在大型系统中，往往采用的是分布式部署的架构（不同服务模块部署在不同的服务器节点上）。在出现问题时，需要一套集中化的日志管理工具来收集 / 分析所有节点上的日志，提高定位问题的效率。

ELK Stack 组件包含 Elasticsearch、Logstash、Beats 和 Kibana。早期版本的 ELK 组件只包含 Elasticsearch、Logstash 和 Kibana 三个组件，这就是 “ELK” 三个字母的来源。在 2015 年，ELK 组件增加了 Beats，为了命名方便，以后 ELK 组件的更新迭代版本都统称为 ELK Stash。 依据

下面简单介绍几个组件的负责的职能，因为我们是客户端同学，只要理解大概的用途即可。

另外，ELK Stack 组件往往还需要配合 Kafka 或 Redis 消息队列，这是为了降低数据丢失隐患。在没有消息队列的情况下，如果服务侧组件出现故障，那么会出现数据丢失。而引入消息队列的情况下，在出现故障时数据会被存储下来，降低了数据丢失隐患。

对于客户端同学，更关心的应该在面向分析侧的 Kibana，这一节我们就着重来总结 Kibana 的使用。

数据搜索是 Kibana 最基础也是最主要的功能，在数据探索（Discover）页面可以交互式地探索你的数据。

简单熟悉下页面中的几块区域：

在数据展示区，你可以看到所有筛选后的数据。展开具体一条数据，其中的 msg 字段值就是你的项目中上报的数据（payload）。

在可视化（Visualize）页面可以创建可视化控件，在仪表盘（Dashboards）页面可以把你创建的多个可视化控件整合在一起展示。

ELK(,Logstash,Kibana)搭建实时日志分析平台（开源实时日志分析ELK平台部署）

日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。

通常，日志被分散的储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。

集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用grep、awk和wc等Linux命令能实现检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。

开源实时日志分析ELK平台能够完美的解决我们上述的问题，ELK由、Logstash和Kiabana三个开源工具组成。官方网站：

85是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。

85Logstash是一个完全开源的工具，他可以对你的日志进行收集、分析，并将其存储供以后使用（如，搜索）。

85kibana也是一个开源和免费的工具，他Kibana可以为Logstash和提供的日志分析友好的Web界面，可以帮助您汇总、分析和搜索重要数据日志。工作原理如下所示：

在需要收集日志的所有服务上部署logstash，作为logstashagent（logstashshipper）用于监控并过滤收集日志，将过滤后的内容发送到logstashindexer，logstashindexer将日志收集在一起交给全文搜索服务，可以用进行自定义搜索通过Kibana来结合自定义搜索进行页面展示。

四大组件：

Logstash:logstashserver端用来搜集日志；

:存储各类日志；

Kibana:web化接口用作查寻和可视化日志；

LogstashForwarder:logstashclient端用来通过lumberjack网络协议发送日志到logstashserver；

日志系列：

企业级日志平台新秀Graylog，比ELK轻量多了

日志系统新贵Loki，比ELK轻量多了

1 为什么需要集中的日志系统？

在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。

如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。

作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。

2 日志系统选择与对比

关于企业级日志管理方案，比较主流的是ELK stack和Graylog。

常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：

ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。

splunk是收费的商业项目，不在考虑范围。

3 认识graylog

31 简介

graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。

在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。

32 优势

部署维护简单

资源占用较少

查询语法简单易懂(对比ES的语法…)

内置简单的告警

可以将搜索结果导出为 json

UI 比较友好

33 graylog单机架构图

34 graylog集群架构

4、基于 GrayLog & ELK 的日志监控

Collector

FileBeat：轻巧占用资源少，但是功能有点弱。「想起了一些东西，都是泪」

Fluentd：个人理解在Logstash与FileBeat中间，可以简单处理一些日志，插件丰富「要再研究下」

自己弄：架构图里面只是mysql调用了自己实现的解析工具，但是其实当日志大到一定的量的还是必须自己来的，类似日志抽样、降级、控制频率等功能，是要真真切切的花费大量时间精力下去的一个sidecar并非动动嘴巴就能搞定的。「都是泪」

Queue

Kafka：王者地位「量小的时候也可以不用这个直接朝后面输出，有很多中间方案大家自己脑补」，不同的日志分不同的topic，严格区分日志所属类型，为后续消费打下基础，比如A业务进入A Topic并在日志中打上所属语言类型的Tag。

Consumer

Logstash：其实这个东西也可以作为收集端来使用，就是比较耗费资源有点重，还会莫名其妙挂了「应该是我不会玩」

GrayLog：本人最喜欢的一个组件，集解析、报警、简单分析、Dashboard、日志TTL的综合体，有这个东西吧其实Kibana就没啥用了，毕竟谁没事天天去分析日志。

Storage

ElasticSearch：全文索引Engine，其实并没有官方说的那么牛，当到一定的并发写入、大量查询之后其实根本不是加机器能解决的，怎么分shard，是按照天保存还是按照条数保存「我比较喜欢按照条数保存，这样可以保证每个index都差不多大小，对于reblance是有好处的，重复利用多盘」如何保存是需要不断调整的。「我们这边不讨论MongoDB去存日志，看着都不靠谱」

规范

其实日志系统最关键的是怎么打、什么格式打、但是这个东西需要消耗大量的时间去定义与各个部门Pk，遇到过大量不讲理的输出，直接线上Debug，600k的并发写入，日志又大又臭谁能扛得住「阿里云的SLS是真的很牛」

卷起袖子加油干，少动嘴，多动手，日志很好玩。在容器化的大环境下也越发的重要。

Flunted + Elasticsearch + Kibana的方案，发现有几个缺点：

不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的Java异常打印

不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。

不符合正则表达式匹配的日志行，被全部丢弃。

对比图

总结

虽然两种解决方案在功能上非常相似，但仍有一些差异需要考虑。

两者之间最重要的区别在于，从一开始，Graylog就定位为强大的日志解决方案，而ELK则是大数据解决方案。Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反，ELK是使用Logstash分析已收集的纯文本日志的解决方案，然后解析并将它们传递给ElasticSearch。

在ELK中，Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便，因为它提供了单一应用程序解决方案（不包括ElasticSearch作为灵活的数据存储），具有几乎相同的功能。因此，部署所需的时间更短。此外，与ELK相比，Graylog开箱即用，且具有出色的权限系统，而Kibana则不具备此功能。作为Elasticsearch的粉丝，我更喜欢Graylog而不是ELK，因为它完全符合我在日志管理方面的需求。

Graylog具有直观的GUI，并提供警报、报告和自定义分析功能。最重要的是，它能在多个日志源和跨机房收集数TB的数据。基于这些优势，我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

如果有需要领取免费资料的小伙伴们， 可以点击此处领取资料哦！

ELK

logstash

elasticsearch

kibana

ELK技术栈要点总结

官方文档之安装教程

Mac第三方工具安装

$ brew install logstash

启动命令

$ bin/logstash -f logstash-exampleconf

Logstash根据logstash-exampleconf配置文件对数据源进行数据读取和清洗，并将清洗结果写入指定的目标文件。

logstash命令除了可以使用“-f”指定配置文件外，还可以指定其他参数，具体说明可以参见 官方文档之Command Flags 。

Logstash除了通过命令行参数进行配置外，还可以在logstashyml等setting文件中进行设置，具体说明参见 官方文档之Setting files

配置文件

配置文件结构清晰，但所涉及的插件种类繁多，而且在插件使用过程中还涉及 环境变量使用 和 条件语句使用 等内容。用户可根据需要选择适当的插件和语法实现数据收集和清洗的目标。

##12 Elasticsearch技术

Cluster与Node

Index、Type与Document

Shards与Replicas

启动命令

$ bin/elasticsearch 前端方式启动
$ bin/elasticsearch -d 守护进程方式启动
elasticsearch启动比较简单，也额外创建配置文件，它将收集的数据重新编排存储，以支持数据的全文检索。检索是Elasticsearch最为重要的功能，也是最为复杂的语法。

需要注意的是：elasticsearch不支持在root用户下启动，因此，在启动前，用户需要创建非root用户，并为该用户赋予elasticsearch目录的 *** 作权限，详情参见 >

创建kibana索引

若只需要收集显示nginx的访问日志，则可以建立一个名为nginx+时间的索引 
若是需要收集一个服务器下的多个服务日志，则可以在一个conf下添加多个input并根据type来区分和实现

环境 
1921682112 ES/kibana 
1921682118 logstash/nginx 
1921682117 logstash/mysql/nginx

建立nginx索引

1）在118服的logstash/etc目录下建立的nginxlogconf，添加

input {
   file {
       path => "/usr/local/nginx/logs/accesslog"
       type => "nginx"
   }
}
output {
   elasticsearch {
       hosts => "1921682112:9200"
       index => "nginx-%{+YYYYMMdd}"
       }
}12345678910111213

其中，index即代表对应的索引名称

2）然后启动logstash

[root@localhost etc]# pwd/usr/local/logstash/etc
[root@localhost etc]# /bin/logstash  -f nginxlogconf1234

3）登陆kibana设置索引

4）然后手动访问nginx页面后，可以在kibana的discover界面看到

收集nginx日志和mysql日志

1）把118服的logstash目录复制到117服对应目录下

scp -r logstash/  root@1921682117:/usr/local/logstash1

2）在117服logstash/etc目录下建立allconf

input {
   file {
       path => "/usr/local/nginx/logs/accesslog"
       type => "nginx"
   }
}
input {
   file {
       path => "/var/log/mysqldlog"
       type => "mysql"
   }
}
output {  if [type] == "nginx"{
   elasticsearch {
       hosts => "1921682112:9200"
       index => "nginx-%{+YYYYMMdd}"
       }
}if [type] == "mysql"{
   elasticsearch {
       hosts => "1921682112:9200"
       index => "mysql-%{+YYYYMMdd}"
       }
}
}1234567891011121314151617181920212223242526272829

3）在kibana页面建立mysql索引

4）启动logstash

[root@host107 etc]# pwd/usr/local/logstash/etc
[root@host107 etc]# /bin/logstash -f allconf1234

5）然后启动及关闭mysql服务，就可以看到日志数据

6）同样的，访问nginx页面后，也会收到nginx日志数据

备注： 
1）其中上面的host列显示0000，是因为没有设置主机名，在/etc/hosts下加上 
127001 hostmysqlnginx 
然后hostname hostmysqlnginx 
重启下logstash，就可以看到host

您的ELK服务器将需要的CPU，RAM和存储量取决于您要收集的日志的卷。在本教程中，我们将使用具有以下规格的VPS用于我们的ELK服务器：
OS: CentOS 7
RAM: 4GB
CPU: 2
注：根据自己的服务器资源分配各个节点的资源
安装 Java 8
Elasticsearch和Logstash需要Java，所以我们现在就安装它。我们将安装最新版本的Oracle Java 8，因为这是Elasticsearch推荐的版本。
注：建议本地下载完最新版的JDK，然后上传到服务器的/usr/local/src目录
# JDK下载地址：
>