【Kubernetes 企业项目实战】04、基于 K8s 构建 EFK+logs

目录
一、日志对我们来说到底重不重要？
日志打印的常见级别
二、常见的日志收集方案
2.1 EFK
2.2 ELK Stack
2.3ELK+
2.4 其他方案
三、EFK 组件详细介绍
3.1组件介绍
3.2组件介绍
1）和 Beat 关系
2）是什么？
3）工作原理
4）传输方案
3.3组件介绍
1）工作原理
2）常用 input 模块
3）常用的模块
4）常用
5）常用 code 插件
3.4组件介绍
【【Kubernetes 企业项目实战】04、基于 K8s 构建 EFK+logs】3.5 、、对比分析
1）
2）
3）
4）
5）
6）
k8s 集群角色
IP
主机名
配置
控制节点
192.168.78.143
k8s-
3vcpu / 3Gi 内存
工作节点
192.168.78.144
k8s-node1
3vcpu / 3Gi 内存
工作节点
192.168.78.145
k8s-node2
3vcpu / 3Gi 内存
一、日志对我们来说到底重不重要？
在生产环境或者测试环境，如果某个服务或者业务组件出现问题，如何定位和排查？需要靠日志，日志是定位问题的重要手段，就像办案人员要根据现场留下的线索推断案情一样。
监控和日志是企业必须具备的。
日志打印的常见级别
日志打印通常有四种级别，从高到底分别是：ERROR、WARN、INFO、DEBUG 。应该选用哪种级别是个很重要的问题。
日志级别中的优先级是什么意思？在你的系统中如果开启了某一级别的日志后，就不会打印比它级别低的日志。例如，程序如果开启了 INFO 级别日志，DEBUG 日志就不会打印，通常在生产环境中开启INFO 日志。
那么应该打印什么级别的日志呢？首先我们应该明确谁在看日志。
通常来说，系统出了问题客户不会进到系统对着控制台查看日志输出，所以日志所面对的主体对象必然是软件开发人员(包括测试测试、维护人员) 。
下面我们假设几种场景来帮助我们理解日志级别：
程序开发结束后交由给测试人员进行测试，测试人员根据测试用例发现某个用例的输出和预期不符，此时他的一反应该是查看日志。此时的日志是 INFO 级别日志不会出现 DEBUG 级别的日志，现在就需要根据日志打印分为两种情况决定他下一步操作：
通过查看 INFO 日志发现是由于自己操作失误，造成了程序结果和预期不符合，这种情况不是程序出错，所以并不是 bug，不需要开发人员到场。
通过查看 INFO 日志发现自己的操作正确，根据 INFO 日志查看并不是操作失误造成，这个时候就需要开发人员到场确认。
以上两种情况是理想情况，测试人员仅根据 INFO 级别的日志就能判断出程序的输出结果与预期不符是因为自己操作失误还是程序 bug 。更为现实的情况实际是测试人员并不能根据 INFO 级别的日志判断是否是自己失误还是程序 bug 。
综上，INFO 级别的日志应该是能帮助测试人员判断这是否是一个真正的 bug，而不是自己操作失误造成的。假设测试人员现在已经初步判断这是一个 bug，并且这个 bug 不那么明显，此时就需要开发人员到场确认。开发人员到达现场后，第一步应该是查看 INFO 日志初步作判断验证测试人员的看法，接着如果不能判断出问题所在则应该是将日志级别调整至 DEBUG 级别，打印出DEBUG 级别的日志，通过 DEBUG 日志来分析定位 bug 出在哪里。所以，DEBUG 级别的日志应该是能帮助开发人员分析定位 bug 所在的位置。
ERROR 和 WARN 的级别都比 INFO 要高，所以在设定日志级别在 INFO 时，这两者的日志也会被打印。根据上面 INFO 和 DEBUG 级别的区别以及适用人员可以知道，ERROR 和 WARN 是同时给测试和开发、运维观察的。WARN 级别称之为“警告”，这个“警告”实际上就有点含糊了，它不算错，你可以选择忽视它，但也可以选择重视它。例如，现在一个 WARN 日志打出这么一条日志“系统有崩溃的风险”，这个时候就需要引起足够的重视，它代表现在不会崩溃，但是它有崩溃的风险。或者出现“某用户在短时间内将密码输出很多次过后才进入了系统”，这个时候是不是系统被暴力破解了呢？这个级别日志如同它的字面含义，给你一个警告，你可以选择忽视，也可以重视，但至少它现在不会给系统带来其他影响。