tomcat 常见的日志类型：
1.tomcat 存取日志
该日志名称为 localhost_access_log.*.txt 位于 tomcat log 目录下，该日志清晰的记录了http服务请求的来源，响应时间，返回的http代码等，可用于
统计服务的成功数和失败数，也可以用于统计接口的响应时间，还可以用于统计服务的请求数和吞吐量等。
2.tomcat 控制台日志
该日志通常名为 catalina.out，位于 tomcat log 目录下，包含tomcat 是否成功启动，启动所使用的时间，以及应用打印的控制台日志等信息。
3.tomcat 本地日志
该日志通常名为 localhost.*.txt，位于 tomcat log 目录下，程序异常时没有被捕获时会被一直抛出到容器厂，容器处理后记录在这个日志下。
业务系统应用日志：一般使用 Commons logging, Log4j, Slf4j, Logback, Log4j2
性能日志：可以对提供的服务接口，依赖的接口，关键的程序路径等统计响应时间。
远程服务调用日志：一个服务可能依赖于其他服务，通常使用rpc或者rest服务进行调用。
4.1 开源日志框架的原理分析与应用实践
4.1.1 JDK Logger
JDK Logger 将日志分为9个级别：all,finer,fine,config,info,warning,serere,off，次级依次升高。
4.1.2 Apache Commons Logging
Apache Commons Logging(简称 Commons Logging，又名 JCL，即 Jakata Commons Loggins)只提供了日志接口，具体的实现则在运行时根据配置
动态查找日志的实现框架，它的出现避免了和具体的日志实现框架直接耦合。在实际开发过程中，开发者可以选择第三方日志组件来搭配使用，例如Log4j。
4.1.3 Apache Log4j
Apache Log4j 日志框架。
4.1.4 Slf4j
4.1.5 Logback
4.1.6 Apache Log4j
4.2 日志系统的优化和最佳实践
4.2.1 开发人员的日志意识
1.开发代码时要有意识的设想代码出现问题的场景，针对出问题的场景记录关键的程序运行的信息，这样在代码出问题时才能通过日志恢复程序运行的过程，
才容易定位问题。
2.打印日志时必须包含环境信息，环境信息是指在打印日志时可获得的帮助开发人员定位问题的信息，包括：用户ID，角色，参数，返回值，逻辑判断结果，
循环次数，异常信息等。
3.对异常等错误信息必须打印错误级别及以上级别的日志，对线上日志要定期检查，没有异常日志产生的服务才是健康的服务。
4.生产环境将关闭的日志必须在打印日志前进行判断，以此来提高执行效率
5.必须使用占位符的方式替代字符串链接，这样程序更简洁，并且性能有所提高。
6.对关键业务步骤必须打点并记录耗时和结果信息等。
4.2.2 日志级别的设置
通常来说，线上使用 info 级别信息就够了，但是刚刚交付的项目服务质量还不稳定。下面是一些最佳实践：
1.QA环境可以使用 debug 级别以下的日志
2.刚刚上线的应用还没有达到稳定期，使用 debug 级别的日志
3.上线后稳定的应用，使用info级别的日志
4.常年不出问题的应用使用error级别的日志即可
对于不同的情况应该使用的日志级别如下：
1.使用trace 级别的日志输出最细粒度的信息事件，通过这些信息可以跟踪程序执行的任一步骤
2.使用debug 级别的日志输出细粒度的信息事件，这些信息对调试应用程序非常有用
3.使用info 级别的日志输出粗粒度的信息事件，突出强调应用程序运行的关键逻辑和过程
4.使用warn 级别的日志输出可能出现的错误，或者输出潜在发生错误的环境信息，或者打印用户输入的非法信息
5.使用error 级别的输出错误事件，但仍然不影响系统的继续运行，
6.fatal 级别代表严重的错误事件，将会导致应用程序的退出
4.2.3 日志的数量和大小
我们要控制日志的输出量，因此只打印关键信息。不要随便把对象的json序列化后打印出来，另外对单条日志要有所限制。
4.2.4 切割方式
4.2.5 日志格式的配置
4.2.6 一行日志导致的线上事故
4.3 大数据日志系统的原理与设计
4.3.1 通用架构和设计
大数据日志系统的采集器部署在每个应用服务器上，它们监控本地的日志文件，然后发送到对应的缓冲队列节点。
解析器集群会监听缓冲队列集群，通常会把基于行的文本日志转换成json格式的数据，以便于后续的存储。
解析器集群的节点将日志转换成json格式的数据后，会把日志存储在有序的存储系统中并建立索引，为后续的客户端提供搜索服务。
最后，包括运维人员，开发人员等，会使用日志展示系统来查看和分析日志，或者以日志存储系统的数据未基础构建和报警系统。
4.3.2 日志采集器
Logstash,Fluentd,Flume,Scribe 和 Rsyslog 等都是采集日志的常用工具。其中，Logstash和Fluentd比较常用。
1.场景的日志采集器
1.Logstash
2.Fluentd
3.Flume
4.Scribe
5.Rsyslog
2.Logstash 和 Fluentd 的对比
1.支持的平台
Logstash 可以在任何支持JVM的平台执行；Fluentd 暂时不支持windows.
2.传输的方式
Logstash 内部缺乏一个持久的消息队列，用redis的缓存做持久。Fluentd 本身自带有缓存系统。
3.性能
单台机器 Logstash 比 Fluentd 多消耗内存 几十M。Logstash 提供了一个轻量级解决方案 Elastic Beats。
Fluentd 也提供了以C语言实现的轻量级的版本 Fluent Bit。还有Go实现的 Fluentd Forwarder。
4.插件系统
最大的不同就是插件的管理方式。
5.事件路由方式
Logstash 使用可编程的方式进行事件路由，适合开发者；而Fluentd使用标记配置的方式路由。
Logstash 路由所有的数据到一个流，然后使用类型 if-then 的语句来选择不同的发送目标。
3.日志采集的最佳实践
采集器存储文件"指纹"及行位置到本地的一个文件中，文件指纹通常是指文件的inode，即使文件重命名，文件的inode也不会发生变化。因此，采集器
通常追踪的是文件的inode信息和行号，文件名的修改并不影响inode信息，只是影响了它所在的文件目录的信息，但是如果文件被压缩后，inode实际发生了
变化，则文件以及称为另外一个文件了，这时需要手工处理。
4.3.3 日志缓冲队列
虽然日志采集器和日志解析器可以直接通信，但是还是建议在它们之间增加一个队列缓冲区。因为如果没有队列缓，当日志解析器负载较高的时候，会拖住日志
采集器，导致日志采集器变慢，至少会影响日志推送的速度，如果采集器的内部缓存或者内存被吃光，则会导致日志丢失，由于日志采集器和应用服务器部署在一起，
所以也可能会导致应用服务器的正常运行。
可以使用kafka，redis 或者 rabbitMQ 等作为日志缓冲队列。kafka 性能最好。
4.3.4 日志解析器
日志解析器从日志缓冲队列中读取日志，解析日志，转换日志，然后以json的格式存储到后续的日志存储中。我们可以使用Logstash和Fluentd作为日志解析器，
当然，我们也可以自己开发，或者使用 Storm，Spark 等流式计算提取更复杂的指标后再进行存储。
4.3.5 日志存储和搜索
日志解析器从解析后的日志中提取的指标等，最后都存入了日志存储系统中，在日志存储系统中进行索引，并支持后续的搜索，由于日志量巨大，信息量巨大，
查询样式多变，所以一般使用全文搜索的搜索引擎技术，例如ElasticSearch,Solr等。
无论我们使用多个个节点的nosql 来做日志的存储和搜索系统，只要日志量足够大，久而久之，存储系统都会被填满磁盘，大量的，不用的数据会被存储在系统中，
导致搜索性能下降。推荐定期对数据进行整理，归档和删除等操作。
1.如果存在较长时间的日志仍然需要被较长查询，则我们需要定期整理这些日志的索引，让它们与时俱进，提供更高的查询效率
2.如果是偶尔被查询，则建议归档。需要的时候再进行解压
3.如果没有查询，则清理
4.3.6 日志展示系统
Kibana.
4.3.7 监控和报警
既然日志被结构化后车窗到日志存储和搜索系统中，我们就可以基于这些数据构建监控和报警系统，通过定时的在日志存储和搜索系统中查找服务和某一数据指标，
然后与预定义的阈值进行比较。
4.3.8 日志系统的容量和性能评估
假设有一个大数据日志处理系统，每天处理来自200台机器的2TB日志，每条日志在1kb左右，监控报警不能超过5分钟，单台服务器产生日志的峰值吞吐量约为10000/s，
所有应用服务器瞬间的日志峰值之和约为 1000000/s。
首先，每天的2TB日志来自200台机器，每台机器每秒处理的平均日志量为：
2TB/1KB/200台/(24*60*60) = 115/s
每台机器每秒处理115，单台服务器产生日志的峰值吞吐量约为10000/s，所以，Logstash 或者 Fluentd 都能满足。
所有应用服务器瞬间的日志峰值之和约为 1000000/s，加入我们选择kafka 作为日志缓存队列，kafka 在普通pc上的吞吐量为 100000/s，我们需要10台kafka。由于处理的日志
在1kb左右，所以我们需要计算kafka的网络IO是否满足性能：
100w/10台 * 1kb = 100MB
即峰值为tps时，单台kafka每秒处理 100000的日志量，网络IO需要满足能够承受 100MB/s的负载量，假设使用kafka节点都是千兆网卡，则正好满足需求。
这里假设一条日志在日志解析器上处理成功并且存储在日志存储系统中需要20ms，每秒峰值时需要处理100w条日志，则一共需要的时间为：
100w * 20ms = 2万s
因为延迟要求不能超过5分钟，所以我们需要在5分钟内处理完峰值的数据，则需要的并发数为：
2万s / 5分钟 = 66.67 并发数
也就是说需要333个核心处理器处理峰值时的1000000/s的吞吐量，假设我们使用4核cpu,8G内存的虚拟机或者docker,那么攻需要处理机：
66/4=16台
这里需要16台日志解析器来处理峰值吞吐量为 1000000/s
再冗余5倍，推荐使用docker。
4.4 ELK系统的构建与使用
4.4.1 Elasticsearch
4.4.2 Logstash
4.4.3 Kibana
1721
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
