日志原理与开发分析这篇完全指南就够了！适应各种规模！_通过开发日志进行数据分析(2)

最新推荐文章于 2024-07-28 16:45:11 发布

2401_84164721

最新推荐文章于 2024-07-28 16:45:11 发布

阅读量834

点赞数 20

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84164721/article/details/138740691

版权

程序员专栏收录该内容

184 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

另外demo2.log内容只有 [ERROR] 和[FATAL]这两个级别的日志，也就是，只有logger.error和logger.fatal两个函数的日志详情被输出到文件中。

如果把ERROR比喻为公开级别，那么像DEBUG/TRACE等就是保密级别了，指定了输出公开信息等话，保密数据是绝对不能打印出来的。

理解一下日志分级

先说级别，不同级别日志会有级别的关键词，像日志中的‘ERROR’， ’DEBUG’ 这些。

既然是级别了就有高低级别之分。

可以用下面的表达式进行级别低到高排列：

TRACE < DEBUG < INFO < WARN < ERROR < FATAL

所以这解释了demo2.js代码中指定了‘error‘级别之后，只有
logger.error 和 logger.fatal 两行日志被打印了。

看懂了吗？就像日常的信息保护级别，指定级别越高越不能暴露更多信息，在程序中级别指定越高，输出的信息越少，同一个道理。

信息量慢慢加大 - 全部日志级别

下图是log4js模块提供的方法和日志级别。
在这里插入图片描述
log4js 提供了getLogger方法，开发者可以调用这个获取一个logger对象，用来输出不同级别日志。

然后，这里是最全面的log4js的提供的日志级别。

重新整理整个日志级别的排列变更如下：

ALL <TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF

上面这个公式务必背诵默写！

这里读者可自行运行文末实例代码。

这里ALL级别相当于整个日志信息都打印，暴露的信息量最多，OFF暴露的信息量是极少的。

雷学委也准备了代码，读者稍后可从文末下载执行。

到这里还不懂，雷学委精心准备了下图，看到这个图已经值了！

在这里插入图片描述

至此，整个日志框架的核心，您已掌握了。

喝杯水，下面继续看实际应用。

实际项目中如何应用日志

配置化日志管理

上面的demo2的代码配置，应该提取日志模块的配置到文件。
在这里插入图片描述
配置放在文件中，可以修改配置不改代码切换日志。

但是应用需要重启，可以代理logger对象实现不重启动态加载。

日志级别的使用建议

通常我们打印‘info’级别日志，记得常规用户行为，如登录/查看更新资料/其他业务访问的log等。

info级别以下的使用

在开发过程中可以使用logger.debug函数去打印程序内部信息，比如打印一些中间变量的值，打印中间处理状态等等。

对于trace级别的日志，这个比较低级别，通常用来本地跟踪代码的执行的详细信息！在服务端，服务器上运行的程序通常不会开启，因为日志量会很大。

对于all级别很少使用，可以根据情况自己定义，很多时候用到trace级别就很够信息量了。

对于info以上的高日志级别

warn级别：打印警告信息，就是可能是错误，或者是忽略的已知错误。
比如系统在调用一个不稳定的接口，有时候别人不稳定只能多次重试，这时候会使用logger.warn方法来打印日志内容”忽略第三方程序调用错误，准备重试“

error级别：顾名思义就是，程序错误，这个可以用来打印错误数据，错误请求的事件信息，比如java中抛出一些CheckedException的时候经常会在catch代码快中调用logger.error来记录此类异常。
这类成为错误记录，更多是程序内部处理，业务方面的错误记录。

fatal级别更多是在NodeJS引擎出现故障，或者JVM（java
虚拟机）这种引擎级别的故障可以用这个级别来打印。针对web应用，像访问底层数据库的失败的时候，也可以用这个fatal级别来记录。
出现这种问题一般是本应用的故障，或者因为网络，操作系统的故障导致的程序故障。

日志格式化问题

如下面的log4js配置一样，加了一个标准输出来展示。
这里的patern: “%d [%p] [%c] - %m%n” 就是我们打印日志的格式。%d是一个占位符，最简单可以理解，就是表示一个时间戳，代表打印日志的时间。
%p %c这些就是占位符，也就是代表了日志级别，日志对象（特定的logger）等。
%m 代表当前如logger.info方法传入的消息。
%n 为换行。
在这里插入图片描述
效果如下：

所有格式定义参考：https://github.com/log4js-node/log4js-node/blob/master/docs/layouts.md

log4js还可以支持将日志写到多个文件中参考：https://github.com/log4js-node/log4js-node/blob/master/docs/multiFile.md

重点说一下，日志格式其实不用过度纠结，但必须在输出准确日志信息的情况下，同时保证整个系统或者多个服务的配置达到统一标准。

统一标准，比如说格式上的输出标准，代码日志输出标准，路径的标准等等。不然容易失控，这需要在架构上达成一致。

日志文件滚动策略

开发的应用通常都是长期运行的，会不停的产生日志。

随着时间推移，把日志写在一个文件也不现实。

而且不利于复查问题，占用大量存储资源，另外，在大文件中搜索关键字速度也降低。

所以需要滚动（Rotate/Rolling）日志，也就是把日志设置一个固定规模，比如写日志到 LeixueweiDemoApp.log 文件，设置最大尺寸，当文件超过最大尺寸自动的创建新文件，同时可以设置最大的日志文件备份，比如保留一个月，半年，甚至更长期的日志。

这是log4js官网的：
在这里插入图片描述
JS的日志配置使用了JSON来呈现是非常直观的。

Java则更多使用logback或者SLF4J + logback/log4j ，配置的内容很像，但是呈现格式不一样，很多是xml文件或者properties文件。

这里可以拿一个XML文件（类似html标签化语义）来看看，如下：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property resource="application.properties" />
    <!-- application.name在application.properties中定义 -->
    <contextName>${application.name}</contextName>
    <!-- 日志级别 -->
    <property name="logLevel" value="INFO" />
    <!-- 日志文件名 -->
    <property name="logFileName" value="LeixueweiDemoApp"/>
    <!-- 保存60天 -->
    <property name="maxHistory" value="60"/>
    <!-- application.logHome在application.properties中定义 -->
    <property name="logPath" value="${application.logHome}/logs/${projectName}"/>
    <!--格式化输出：%d{yyyy-MM-dd HH:mm:ss.SSS} 表示特定时间格式日期，%thread表示线程名，%-5level：级别从左显示5个字符宽度，%msg：日志消息，%n是换行符-->
    <property name = "LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{35} - %msg%n"></property>

    <!-- 控制台输出 -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">           
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
    </appender>


    <!-- 日志记录器，日期滚动记录 -->
    <appender name="FILEAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!--日志文件路径及文件名 -->
        <file>${logPath}/${logFileName}.log</file>
        <!-- 日志滚动策略，按日期记录 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 归档日志文件路径-->
            <fileNamePattern>${logPath}/${logFileName}.%d{yyyy-MM-dd}.log</fileNamePattern>
            <maxHistory>${maxHistory}</maxHistory>
        </rollingPolicy>
        <!-- 追加记录日志 -->
        <append>true</append>
        <!-- 日志文件格式 -->
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
        <!-- 记录info及其以上级别 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>info</level>
        </filter>
    </appender>

	<!--适用上面两个appender-->
    <root level="${logLevel}">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="FILEAppender"/>
    </root>

</configuration>

上面定义了两个log appender 和 root根logger来配置全局logLevel。

其实配置的属性两个技术很相似。

到这里已经变得非常复杂了，但是一个完整的应用日志也就是上面的，文末的代码仓库链接有实例配置。

读到这里，基本可以解决单个应用的日志管理，而且能够做的成熟专业的应用日志处理了。

大规模分布式场景的日志管理与分析

高性能的处理

这里稍微提一下，在应用中打印日志不宜过多，会影响程序性能。比如访问了一个静态页面，服务器直接打印1G的log出来，这就很离谱。

但有时候比如一些重点信息很多，比如在很大请求量的情况下，要保证性能，又想要留住重要的信息跟踪，怎么处理？

这时候可以使用日志队列的方式来解决。

在使用NodeJS情况下，这里又得提到pm2了，使用集群模式运行，把多个worker节点日志发布到master进行统一化处理，减轻写同个日志或者轮转日志的负担。

Java中也有类似的方法，异步处理大量日志，可以查看logback的配置，AsyncAppender。

<appender name="ASYNC\_LOG\_INFO" class="ch.qos.logback.classic.AsyncAppender">
        <!-- 设置为：不丢失日志 -->
        <discardingThreshold>0</discardingThreshold>
        <!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
        <queueSize>${queueSize}</queueSize>
        <appender-ref ref="FILE\_INFO"/>
    </appender>

这个配置的queueSize变量，得跟据应用的实际QPS日志流量来分析，其他参考：http://logback.qos.ch/manual/appenders.html#AsyncAppender

统一日志处理与分析

上面说的很多直接用来做一个应用的日志处理都可以。

统一日志处理说的是把一个大型系统的日志，统一的集中化管理。

重点是：分布式日志集中化管理。

这一点很重要，在运维大型平台的时候，有几百上千台服务器，上面很多服务，很多日志不可能一个一个登录上去看。

所以我们需要使用工具进行集中化，而且做一个大规模的统一分析。

思想是把本服务日志传输到一个中央分析主机，使用高效的分析工具，分析数据的规律

下面是一个简化的日志集中收集处理的架构，应用服务器多，日志收集终端可以把日志放到消息队列，缓冲处理日志。
在这里插入图片描述
这一块可以拓展的解决方案很多，是一个开放问题，后面可以写一篇专门Elastic技术棧的。

快速过一下elastic stack技术组件：

FileBeat：一个收集日志的程序
Logstash: 接收网络端数据，有Pipeline进行日志解构与重组，格式化为结构化数据，方便分析
ElasticSearch：一个高效的存储框架，支持快速数据存储查询
Kibana：一个数据可视化工具，支持快速对接elasticsearch的数据，快速的图表面板制作。

映射到上面的架构图，我们使用elastic stack的组件流程如下：

终端应用服务器日志收集（FileBeat) -> 统一日志处理(Logstash) -> 统一日志存储(ElasticSearch) -> 统一的数据展示面板(Kibana)

这里简单提一下，使用这些组件更多是继续配置整合，参考官网配置和文本的代码REPO即可。

小团队或者小公司可以使用/开发日志收集器（功能类似logstash+filebeat来传输处理日志），然后存储到elastic search来统一分析，最后使用Kibana做很多分析面板，这里就要求所有应用日志的格式统一，打印足够有效信息。

日志数据分析与价值揭示

不给有效数据，再怎么分析也是徒劳。数据采集的量也得足够，不能只来一两条，那是很零散的分布。

下面来看看Kibanan制作的一些数据分析面板

比如监控Nginx 的访问请求情况
在这里插入图片描述
然后还能细致分析到每一个用户请求的响应情况：

这两个图表的数据来源是Nginx组件产生的log（日志）文件，一天的用户请求访问日志的分析。

或者像MITRE 公司展示的各种黑客攻击的活动分析面板

它是一个数据安全领域的组织，下面面板数据来自：https://attackevals.mitre.org/evaluations.html?round=APT29

下面是一周的网络攻击活动统计，有高到低，左边为攻击手段排名，中间为具体技术总量排名，右边为策略排名。
在这里插入图片描述
如上图，把零散的数据导入作出面板，作出图表显现了数据的规律。上面揭示了各种安全攻击的分布，以及使用的主要技术。

这里可以感受到日志数据分析的价值了吧。

自研发平台也可以参考Kibana或者Grafana技术棧，实施日志收集分析方案。

读者可以去elastic网站看demo深度了解一下。

再回顾一下

日志处理与分析跟我们写程序思考是一样的，先把思路捋清楚，找去定标准，找合适的工具，还能挖掘出很多业务规律发现价值，创造营收

本文讲述了下面这些

日志的概念
日志的作用
日志的简单应用
多种日志格式的使用和含义
实际项目如何管理和配置日志
大平台/高并发场景的日志处理与价值分析

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

种日志格式的使用和含义

实际项目如何管理和配置日志
大平台/高并发场景的日志处理与价值分析

[外链图片转存中…(img-0hjVmCdS-1715465560205)]
[外链图片转存中…(img-ItE7OW8h-1715465560206)]
[外链图片转存中…(img-Q5ESY2k5-1715465560206)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

2401_84164721

关注

20
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
日志原理与开发分析这篇完全指南就够了！适应各种规模！_通过开发日志进行数据分析(2)

另外demo2.log内容只有 [ERROR] 和[FATAL]这两个级别的日志，也就是，只有logger.error和logger.fatal两个函数的日志详情被输出到文件中。如果把ERROR比喻为公开级别，那么像DEBUG/TRACE等就是保密级别了，指定了输出公开信息等话，保密数据是绝对不能打印出来的。
复制链接

扫一扫