4.分布式服务架构：原理、设计与实战 --- 大数据日志系统的构建

 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.Logstash2.Fluentd3.Flume4.Scribe5.Rsyslog2.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

4.分布式服务架构：原理、设计与实战 --- 大数据日志系统的构建相关推荐

微服务架构原理与开发实战
内容简介最近几年软件开发方法层出不穷,微服务作为一种主流的架构模式一直热度不减.为了帮助广大程序员们更好更快地理解微服务的概念,学习微服务在项目中的实践,本书全面阐述了微服务架构模式的特点.架构思路 ...
如何设计日志系统_架构 - 如何设计一个百亿级日志系统
" 日志是记录系统中各种问题信息的关键,也是一种常见的海量数据. 日志平台为集团所有业务系统提供日志采集.消费.分析.存储.索引和查询的一站式日志服务. 主要为了解决日志分散不方便查看.日志 ...
分布式服务架构：原理、设计与实战
网站更多书籍点击进入>> CiCi岛下载电子版仅供预览及学习交流使用,下载后请24小时内删除,支持正版,喜欢的请购买正版书籍电子书下载(皮皮云盘-点击"普通下载" ...
分布式服务架构精讲pdf文档：原理+设计+实战，（收藏再看）
前言如果你期待对分布式系统有一个更全面的认识,想要了解各个技术在分布式系统中如何应用.分别解决哪些问题.有怎样优秀的实现,推荐阅读.收藏本篇. 分布式.微服务几乎是现在的技术人员必须要了解的架构方向 ...
分布式服务架构：原理设计与实践（读书总结）
文章目录 1. 分布式微服务架构设计原理 1.1 从传统的单体架构到到服务化架构 1.2 从服务化到微服务 1.3 微服务架构的核心要点和实现原理 1.4 Java平台微服务架构的项目组织形式 1.5 ...
连阿里P8都赞不绝口的“分布式架构原理设计笔记”到底有多牛
在分布式系统中,一次业务处理可能需要多个应用来实现,比如用户发送一次下单请求,就涉及到订单系统创建订单,库存系统减库存,而对于一次下单,订单创建与减库存应该是要同时成功或者同时失效,但在分布式系统中, ...
荐书：《分布式服务架构：原理、设计与实战》
荐书:<分布式服务架构:原理.设计与实战> 全面介绍分布式服务架构的原理与设计给出保障线上服务健康.可靠的至佳方案自互联网诞生以来,其简单.敏捷的微服务架构开发理念和实践逐渐成为主流, ...
后台服务架构高性能设计之道
"N 高 N 可",高性能.高并发.高可用.高可靠.可扩展.可维护.可用性等是后台开发耳熟能详的词了,它们中有些词在大部分情况下表达相近意思.本序列文章旨在探讨和总结后台架构设计中 ...
linux后台服务架构高性能设计之道
"N 高 N 可",高性能.高并发.高可用.高可靠.可扩展.可维护.可用性等是后台开发耳熟能详的词了,它们中有些词在大部分情况下表达相近意思.本序列文章旨在探讨和总结后台架构设计中 ...
免费分享：5本架构师书籍，架构解密从分布式到微服务，分布式服务架构：原理、设计与实战，架构真经互联网技术架构的设计原则，架构探险
1.架构即未来现代企业可扩展的Web架构流程和组织 PDF 下载下载地址:http://www.askwinds.com/r-c/down-info-02/6fbd80dc949241298e6a ...

4.分布式服务架构：原理、设计与实战 --- 大数据日志系统的构建

4.分布式服务架构：原理、设计与实战 --- 大数据日志系统的构建相关推荐

最新文章

热门文章