日志管理

随着微服务流行，很多公司都把零碎依照业务边界拆成了很多微服务。因而业务链路贯通着很多微服务节点，导致定位某个申请的日志以及上下游业务的日志会变得十分艰难。为了解决这一痛点， 业界也有诸多成熟计划。如 SkyWalking，Pinpoint 等，但其运维老本和数据存储老本均不可小觑。如果有相应的资源去做那它们天然是不二之选。 但如果你资源无限，那么这里给出一个十分轻量的通过集成 TLog 来解决日志追踪问题的计划。 TLog 是什么？TLog 提供了一种最简略的形式来解决日志追踪问题，它不收集日志，也不须要另外的存储空间，它只是主动的对你的日志进行打标签，主动生成 TraceId 贯通你微服务的一整条链路中。并且提供上下游节点信息。 集成 TLog盘古开发框架已将 TLog 作为缺省规范组件集成进盘古根底模块：pangu-spring-boot-starter。 如何应用第一步：依赖盘古根底模块<dependency> <groupId>com.gitee.pulanos.pangu</groupId> <artifactId>pangu-spring-boot-starter</artifactId></dependency>第二步：启动类调用日志加强办法static { AspectLogEnhance.enhance();}第三步：别离结构盘古消费者微服务和生产者微服务参见如下盘古范例模块。获取代码 pangu-examples-dubbo-service 服务生产者pangu-examples-webapi-dubbo-service-based 服务消费者查看日志输入成果咱们在一个 Dubbo 服务消费者和一个 Dubbo 服务生产者利用中别离做如上配置后，就能够在每个调用链的日志里看到 TLog 自定嵌入的 TraceId 标签值 10812814178142336。如下所示。 生产端：2022-06-23 14:40:50 INFO 47050 - [nio-8080-exec-1] c.x.DemoController : < 0 >< 10812814178142336 > call case1...生产端：2022-06-23 14:40:50 INFO 46395 - [:20881-thread-4] c.x.UserServiceImpl : < 0.1 >< 10812814178142336 > 参数userIn：UserInDto(name=null, userType=1)

云智慧 AIOps 社区是由云智慧发动，针对运维业务场景，提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交换社区。该社区致力于流传 AIOps 技术，旨在与各行业客户、用户、研究者和开发者们独特解决智能运维行业技术难题，推动 AIOps 技术在企业中落地，建设衰弱共赢的AIOps 开发者生态。日志模式解析是将日志从半结构化数据解析为结构化数据的一种算法，能够帮忙咱们疾速理解大量日志的概貌，在日志的自动化剖析过程中，常作为两头步骤，服务于日志后续的异样检测等工作。本技术黑板报中，咱们将围绕三个问题来具体解说日志模式解析：日志模式解析是什么，为什么要做日志模式解析，如何实现日志模式解析。 一、日志模式解析是什么：咱们能够用上面这张图来了解日志模式解析所做的工作： 首先须要明确的是，日志是一种半结构化数据，他是由特定的代码生成的。如上图中，日志音讯：2015-10-18 18:05:29,570 INFO dfs.DataNode$PacketResponder: Received block blk_-562725280853087685 of size 67108864 from /10.251.91.84。就是由代码LOG.info("Received block " + block + " of size " + block.getNumBytes() + " from " + inAddr);生成。日志模式解析的目标就是将日志解析成如上图所示的结构化数据的模式，即从日志中提取出工夫戳、等级、组件、日志模板和参数信息。日志的工夫戳、等级、组件这三个信息通过简略的正则就能够非常容易取得，所以日志模式解析算法真正关注的是日志模板及参数的提取。 什么是日志模板和参数呢？略微有一点代码常识，咱们都能晓得代码LOG.info("Received block " + block + " of size " + block.getNumBytes() + " from " + inAddr)打印出的日志中，都会呈现文本：Received block 、of size 、from，这些文本咱们称为常量，而因为每次打印日志时零碎状态的不同，每条日志打印出的block、block.getNumBytes()、inAddr可能不同，这些文本咱们称为参数。咱们将日志中的常量保留，参数用特定符号<*>代替，这样所生成的文本就是日志的模板。 日志模式解析过程能够了解为是一个倒推日志打印代码的过程，也是一个对日志聚类的过程（雷同模板的日志认为是同一类日志）。不同文章对日志模式解析有不同的称说，日志模板开掘、日志模式发现、日志模式识别、日志聚类等，其实指的都是日志模式解析。 二、为什么要做日志模式解析：日志模式解析是当初很多日志产品中都有的一个性能，为什么大家都要做日志模式解析这件事呢？首先，日志模式解析能够帮忙咱们疾速理解日志概貌，在现在的计算机系统中，日志数量往往十分宏大，一个零碎一天内可能就会产生上百万条日志，人眼间接观测显然不事实，但通过日志模式解析，咱们能够将上百万条日志压缩成几百个模板，这样就能够达到人眼可看的目标（如下图）。 其次，模式解析经常是自动化剖析过程的两头步骤，服务与后续异样检测等工作，因为模式解析后的后果是更易于剖析的。比方，咱们能够通过对某种模式的日志的打印工夫进行剖析，取得模式的周期性，将不合乎周期的点认为是异样；又比方，咱们能够通过剖析失去模式之间的呈现程序关系，如若当咱们发现模式2总是会跟在模式1前面呈现，如果忽然发现在某个工夫，模式2独自呈现了，这大概率也是一个异样；此外，对某种模式参数的占比进行剖析，也能判断异样。 三、如何实现日志模式解析：本技术黑板报一共调研了13种经典日志解析算法，其中大部分出自于综述《Tools and Benchmarks for Automated Log Parsing》中。本技术黑板报中，依据算法的原理，将这些算法分为三类：基于聚类的日志模式解析算法、基于频繁项开掘的日志模式解析算法、基于启发的日志模式解析算法。下图为本技术黑板报中设计到的算法及其分类： ...

我的项目实际 微服务架构中，二次浅封装实际分布式我的项目中，选型与依赖治理一、背景简介我的项目中日志的治理是根底性能之一，不同的用户和场景下对日志都有特定的需要，从而须要用不同的策略进行日志采集和治理，如果是在分布式的我的项目中，日志的体系设计更加简单。 日志类型：业务操作、信息打印、申请链路；角色需要：研发端、用户端、服务级、零碎级； 用户与需要 用户端：外围数据的增删改，业务操作日志；研发端：日志采集与管理策略，异样日志监控；服务级：要害日志打印，问题发现与排查；零碎级：分布式我的项目中链路生成，监控体系；不同的场景中，须要选用不同的技术手段去实现日志采集治理，例如日志打印、操作记录、ELK体系等，留神要防止日志治理导致程序异常中断的状况。 越是简单的零碎设计和业务场景，就越依赖日志的输入信息，在大规模的架构中，通常还会搭建独立的日志平台，提供日志数据的采集、存储、剖析等整套解决方案。 二、Slf4j组件1、外观模式日志的组件恪守外观设计模式，Slf4j作为日志体系的外观对象，定义标准日志的规范，日志能力的具体实现交由各个子模块去实现；Slf4j明确日志对象的加载办法和性能接口，与客户端交互提供日志治理性能； private static final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(Impl.class) ;通常禁止间接应用Logback、Log4j等具体实现组件的API，防止组件替换带来不必要的麻烦，能够做到日志的对立保护。 2、SPI接口从Slf4j和Logback组件交互来看，在日志的应用过程中，根本的切入点即应用Slf4j的接口，辨认并加载Logback中的具体实现；SPI定义的接口标准，通常作为第三方（内部）组件的实现。 上述SPI作为两套组件的连接点，通过源码大抵看下加载过程，追溯LoggerFactory的源码即可： public final class org.slf4j.LoggerFactory { private final static void performInitialization() { bind(); } private final static void bind() { try { StaticLoggerBinder.getSingleton(); } catch (NoClassDefFoundError ncde) { String msg = ncde.getMessage(); if (messageContainsOrgSlf4jImplStaticLoggerBinder(msg)) { Util.report("Failed to load class \"org.slf4j.impl.StaticLoggerBinder\"."); } } }}此处只贴出了几行示意性质的源码，在LoggerFactory中执行初始化绑定关联的时候，如果没有找到具体的日志实现组件，是会报告出相应的异样信息，并且采纳的是System.err输入谬误提醒。 三、自定义组件1、性能封装对于日志（或其余）罕用性能，通常会在代码工程中封装独立的代码包，作为公共依赖，对立治理和保护，对于日志的自定义封装能够参考之前的文档，这里通常波及几个外围点： starter加载：封装包配置成starter组件，能够被框架扫描和加载；aop切面编程：通常在相干办法上增加日志注解，即可自动记录动作；annotation注解：定义日志记录须要标记的外围参数和解决逻辑；至于如何组装日志内容，适配业务语义，以及后续的治理流程，则依据具体场景设计相应的策略即可，比方日志怎么存储、是否实时剖析、是否异步执行等。 2、对象解析在自定义注解中，会波及到对象解析的问题，即在注解中放入要从对象中解析的属性，并且把值拼接到日志内容中，能够加强业务日志的语义可读性。 import org.springframework.expression.Expression;import org.springframework.expression.spel.standard.SpelExpressionParser;public class Test { public static void main(String[] args) { // Map汇合 HashMap<String,Object> infoMap = new HashMap<>() ; infoMap.put("info","Map的形容") ; // List汇合 ArrayList<Object> arrayList = new ArrayList<>() ; arrayList.add("List-00"); arrayList.add("List-01"); // User对象 People oldUser = new People("Wang",infoMap,arrayList) ; People newUser = new People("LiSi",infoMap,arrayList) ; // 包装对象 WrapObj wrapObj = new WrapObj("WrapObject",oldUser,newUser) ; // 对象属性解析 SpelExpressionParser parser = new SpelExpressionParser(); // objName Expression objNameExp = parser.parseExpression("#root.objName"); System.out.println(objNameExp.getValue(wrapObj)); // oldUser Expression oldUserExp = parser.parseExpression("#root.oldUser"); System.out.println(oldUserExp.getValue(wrapObj)); // newUser.userName Expression userNameExp = parser.parseExpression("#root.newUser.userName"); System.out.println(userNameExp.getValue(wrapObj)); // newUser.hashMap[info] Expression ageMapExp = parser.parseExpression("#root.newUser.hashMap[info]"); System.out.println(ageMapExp.getValue(wrapObj)); // oldUser.arrayList[1] Expression arr02Exp = parser.parseExpression("#root.oldUser.arrayList[1]"); System.out.println(arr02Exp.getValue(wrapObj)); }}@Data@AllArgsConstructorclass WrapObj { private String objName ; private People oldUser ; private People newUser ;}@Data@AllArgsConstructorclass People { private String userName ; private HashMap<String,Object> hashMap ; private ArrayList<Object> arrayList ;}留神下面应用的SpelExpressionParser解析器，即Spring框架的原生API；业务中遇到的很多问题，倡议都优先从外围依赖(Spring+JDK)中寻找解决形式，多花工夫相熟零碎中外围组件的全貌，对开发视线和思路会有极大的帮忙。 ...

当咱们公司外部部署很多服务以及测试、正式环境的时候，查看日志就变成了一个十分刚需的需要了。是多个环境的日志对立收集，而后应用 Nginx 对外提供服务，还是应用专用的日志收集服务 ELK 呢？这就变成了一个问题！ 而 Graylog 作为整合计划，应用 Elasticsearch 来存储，应用 MongoDB 来缓存，并且还有带流量管制的（throttling），同时其界面查问简略易用且易于扩大。所以，应用 Graylog 成为了不二之选，为咱们省了不少心。 Filebeat 工具介绍Filebeat 日志文件托运服务Filebeat 是一个日志文件托运工具，在你的服务器上安装客户端后，Filebeat 会主动监控给定的日志目录或者指定的日志文件，追踪读取这些文件，不停的读取，并且转发这些信息到 Elasticsearch 或者 Logstarsh 或者 Graylog 中寄存。 Filebeat 工作流程介绍当你装置并启用 Filebeat 程序的时候，它会启动一个或多个探测器（prospectors）去检测你指定的日志目录或文件。 对于探测器找出的每一个日志文件，Filebeat 都会启动一个收割过程（harvester）。 每一个收割过程读取一个日志文件的最新内容，并发送这些新的日志数据到处理程序（spooler），处理程序会汇合这些事件。 最初 Filebeat 会发送汇合的数据到你指定的地址下来（咱们这里就是发送给 Graylog 服务了）。 Filebeat 图示了解记忆咱们这里不实用 Logstash 服务，次要是因为 Filebeat 相比于 Logstash 更加轻量级。 当咱们须要收集信息的机器配置或资源并不是特地多时，且并没有那么简单的时候，还是倡议应用 Filebeat 来收集日志。 日常应用中，Filebeat 的装置部署形式多样且运行非常稳固。 Filebeat 配置文件配置 Filebeat 工具的外围就是如何编写其对应的配置文件！ 对应 Filebeat 工具的配置次要是通过编写其配置文件来管制的，对于通过 rpm 或者 deb 包来装置的状况，配置文件默认会存储在，/etc/filebeat/filebeat.yml 这个门路上面。而对于，对于 Mac 或者 Win 零碎来说，请查看解压文件中相干文件，其中都有波及。 ...

对于日志收集、解决、剖析的计划，其实是很多，常见的就是ELK组合，即：Elasticsearch + Logstash + Kibana，官方网站：https://www.elastic.co/products 前面随着架构的优化与演进，又引入另一个轻量级的组件 Filebeat，Filebeat和Logstash一样属于日志收集解决工具，基于原先 Logstash-fowarder 的源码革新进去的。与Logstash相比，filebeat更加轻量，占用资源更少。 Logstash 和Fluentd相比，它在效力上体现略逊一筹，故而逐步被fluentd取代，ELK也随之变成EFK。EFK由ElasticSearch、Fluentd和Kiabana三个开源工具组成，这三款开源工具的组合为日志数据提供了分布式的实时收集与剖析的监控零碎。 Fluentd 简介Fluentd 是一个收费，而且齐全开源的日志管理工具，简化了日志的收集、解决、和存储，你能够不须要在保护编写非凡的日志解决脚本。 个性介绍应用json来记录logFluentd应用Json来结构化数据，这让Fluentd对立了数据处理果层，包含日志收集，过滤，并输入日志缓冲（多个源和指标），这使得上游数据处理也变的容易得多。 插件式体系结构Fluentd具备灵便的插件零碎，让社区来扩大它的性能。咱们的300 +社区奉献的插件能够连贯几十个数据源和数据输入。通过应用插件，你能够充分利用你的日志。目前开源社区曾经奉献了上面一些存储插件：MongoDB, Redis, CouchDB,Amazon S3, Amazon SQS, Scribe, 0MQ, AMQP, Delayed, Growl 等等。 最小所需资源Fluentd 应用C和Ruby语言编写，仅须要很少的系统资源，一个运行再30-40MB内存的实例单核每秒能够解决13000次事件。 可靠性fluentd反对基于内存或文件的数据缓冲，以避免数据失落。fluentd还有弱小的容错性，并且可设置高可用性。2000 +的数据驱动的企业依附fluentd，通过他们日志数据的了解和应用来提供更好的产品和服务。 装置https://docs.fluentd.org/inst... Centos 零碎 curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh 启动服务 systemctl start td-agent 更多平台的装置形式：https://docs.fluentd.org/inst... 默认启动是通过td-agent用户启动的，如果须要批改成其它用户，应用上面的办法： [root@centos7 ~]# vim /usr/lib/systemd/system/td-agent.service[Unit]Description=td-agent: Fluentd based data collector for Treasure DataDocumentation=https://docs.treasuredata.com/articles/td-agentAfter=network-online.targetWants=network-online.target[Service]User=td-agent #用户Group=td-agent #用户组LimitNOFILE=65536Environment=LD_PRELOAD=/opt/td-agent/embedded/lib/libjemalloc.soEnvironment=GEM_HOME=/opt/td-agent/embedded/lib/ruby/gems/2.4.0/Environment=GEM_PATH=/opt/td-agent/embedded/lib/ruby/gems/2.4.0/Environment=FLUENT_CONF=/etc/td-agent/td-agent.confEnvironment=FLUENT_PLUGIN=/etc/td-agent/pluginEnvironment=FLUENT_SOCKET=/var/run/td-agent/td-agent.sockEnvironment=TD_AGENT_LOG_FILE=/var/log/td-agent/td-agent.logEnvironment=TD_AGENT_OPTIONS=EnvironmentFile=-/etc/sysconfig/td-agentPIDFile=/var/run/td-agent/td-agent.pidRuntimeDirectory=td-agentType=forkingExecStart=/opt/td-agent/embedded/bin/fluentd --log $TD_AGENT_LOG_FILE --daemon /var/run/td-agent/td-agent.pid $TD_AGENT_OPTIONSExecStop=/bin/kill -TERM ${MAINPID}ExecReload=/bin/kill -HUP ${MAINPID}Restart=alwaysTimeoutStopSec=120配置文件介绍配置文件目录： /etc/td-agent/td-agent.conf ...

背景现在mongodb有一张日志表，保留每天的系统访问信息，由于每天的数量非常大，导致长时间之后表变得非常大，影响插入效率，并且导致无法查询，现在我们需要制定方案来解决这个问题，需求是实现表的按时清理和归档。要求是尽量不修改项目现有的业务代码。并且现在数据库的大概每天产生30至60万条数据，能够平稳的处理。 解决方案方案一：集中清除： 假设在2019年的11月1号开始增加ttl设置为30天后的凌晨1点进行自动删除，然后我们每30天也就是2019年12月1号凌晨0点开始第一次备份数据，这是我们的数据库中会有一个月的数据，备份完成一小时后，开始删除当天数据，当下个月备份的时候，也就是1月1号，我们11月的数据已经自动删除完，这时进行备份，只有12月的数据。 方案二：分散清除： 备份方案与方案一相同，ttl设置为在日志生成后2592000秒（30天）后删除。 两种方案的区别： 第二种方案将删除分散到一天，将压力分散开；不需要更改原有代码只需要数据库设置索引第一种方案将删除放在凌晨，在服务器低峰删除；需要增加删除字段，并自定义删除时间最终选择实施方案一 原因：1. 不需要更改业务代码    2. 按照 mongodb设计如果删除数据时处于数据库高峰，会延后删除，（更改方案：将删除时间设为整天的时间加减某些量如5小时等，会生成错峰） 操作步骤设置mongodb的ttl索引，在一个选中的类型为date的字段上加上ttl索引，参考代码如下，具体实现参照百度。参照实现：ttl 数据库备份，参照百度，使用shell脚本定时备份。参照实现：备份 参考资料

wslog原理利用github.com上无数的slack hook 日志工具sdk遵循 slack hook API 规范 https://api.slack.com/incomin...wslog暴露Http API来收集slack hook api 规范的json日志wslog提供websocket API像前端实时展示收集的日志,提供http api 展示搜索历史日志视频DEMO视频演示地址 https://www.bilibili.com/vide... 1. 为什么要开发这个应用我们程序员再开发中需要不停的查看日志来解决bug,我在google上一直都没有找到一款轻便简洁有效的日志收集应用.而这款应用可以结局一下疼点: linux下查看日志学习曲线较陡, tail/cat/grep/sed 命令眼花缭乱ELK日志服务器部署困难繁琐,其次对机器的性能内存要求很高,ELK基于elasticSearch/java内存无底洞.使用Slack Hook收集日志: 国内网络加载slack界面非常吃力,各种js/css下载失败,更甚对于免费用户日志数量还有数量条数限制(<10000条).钉钉Bot Hooks收集日志: 钉钉办公工具是大资本加剥削工薪阶级的工具(哈哈),你怎么能使用钉钉来解析日志的收集展示呢?2. wslog的优势2.1 部署简单wslog 后端基于golang开发,一次编译多平台可执行文件.wslog UI基于浏览器,支持任意平台.wslog 数据库使用SQLite3和go语言内存数据库,没有任何数据库运维工作和数据库限制.前端代码和后端代码都编译到一个可执行二进制文件中,双击二进制文件就可以执行. 2.2 多平台支持wslog 支持单机运行,可以支持windows/linux服务器运行.支持各种主流操作系统windows/linux/mac/中标麒麟/国产linux操作系统.支持任意架构arm/x86,支持树莓派系统... 2.3 实时日志输出wslog采用websocket通讯,像聊天工具那样实时输出日志,也可以在日志历史列表中快捷查看日志 2.4 日志分类日志从功能来说，可分为诊断日志、统计日志、审计日志. wslog日志支持debug/info/warning/error/fatal等日志级别 2.5 日志全文检索wslog 可以轻松的在数百万条日志中快速的定位你的日志 2.6 全面兼容支持slack-hook日志sdk进入wslog->hook 创建hook,复制hook_url,把hook_url粘贴替换之前slack_hook sdk 配置. 2.7 全面兼容支持slack_hook API的第三方日志收集SDKgo: logrus slackruspython: slack-loggerjava: slack appender for Log4jC#: Microsoft.Extensions.Logging.Slackphp: laravel/lumen slack日志javascript: Slack logger nodejs libraryswift: SwiftyBeaver slack3. 编译/安装可以访问在线demo网站 http://felix.mojotv.cn ...

部署网络应用时，会对请求进行日志保存，用于数据统计分析以及故障排除，但对于高并发请求的服务器，日志文件会迅速增长，快速的消耗磁盘空间，同时，分析一个大文件来排查问题也会非常慢。因此，我们通常需要将日志按照天级别进行存储，并对过旧的日志进行压缩转存或删除，方便节省磁盘空间和进行脚本分析。当我第一次有这种需求的时候，最先想到的是crontab脚本定时执行日志清理脚本。就是先编写一个cleanLog.sh，然后让crontab定期的来执行它。这个方法可行，但是比较麻烦费事，此时一个Linux内置的工具就比较有用了：logrotate。logrotate: Linux日志文件总管logrotate（日志轮转工具）可以自动对日志文件提供截断、压缩以及轮转的功能。logrotate工具默认安装在linux机器上，全局命令在/usr/sbin/logrotate，另外还包含两个配置文件：// 全局配置文件，存储的为公用的默认配置项/etc/logrotate.conf// 子项配置文件夹，该文件夹下提供一些系统级别的日志配置，你的自定义配置也需要配置在这里/etc/logrotate.d/这个工具能做到自动执行的功能，其实还是依赖于crontab工具，只不过这些设定系统自动完成了，我们可以查看crontab系统级别的日运行脚本：$ vim /etc/cron.daily/logrotate#!/bin/sh/usr/sbin/logrotate /etc/logrotate.conf >/dev/null 2>&1EXITVALUE=$?if [ $EXITVALUE != 0 ]; then /usr/bin/logger -t logrotate “ALERT exited abnormally with [$EXITVALUE]“fiexit 0可以看到在crontab的日级别配置文件目录下有一个logrotate子项，它会每天执行logrotate命令，调用的配置为/etc/logrotate.conf。在实际执行中，logrotate命令会先读取/etc/logrotate.conf的配置作为默认项，然后再依次读取/etc/logrotate.d/目录下的各文件配置来覆盖默认项，并执行日志轮转功能。logrotate命令语法：logrotate [OPTION…] <configfile>参数说明：-d, –debug ：debug模式，测试配置文件是否有错误。-f, –force ：强制转储文件。-m, –mail=command ：压缩日志后，发送日志到指定邮箱。-s, –state=statefile ：使用指定的状态文件。-v, –verbose ：显示转储过程。logrotate使用假设我们现在有一个日志文件存储在/home/work/log/nginx.access.log，需要对其每日进行切分为新旧两个日志文件，并删除7天前的旧日志。首先我们创建新的日志轮转配置：$vim /etc/logrotate.d/nginxAccessLog# 指定需要轮转处理的日志文件/home/work/log/nginx.access.log { # 日志文件轮转周期，可用值为: daily/weekly/yearly daily # 新日志文件的权限 create 0664 work work # 轮转次数，即最多存储7个归档日志，会删除最久的归档日志 rotate 7 # 以当前日期作为命名格式 dateext # 轮循结束后，已归档日志使用gzip进行压缩 compress # 与compress共用，最近的一次归档不要压缩 delaycompress # 忽略错误信息 missingok # 日志文件为空，轮循不会继续执行 notifempty # 当日志文件大于指定大小时，才继续执行，单位为bytes（默认）/k/M/G size = 100M # 将日志文件转储后执行的命令，以endscript结尾，命令需要单独成行 postrotate # 重启nginx日志服务，写入到新的文件中去，否则会依然写入重命名后的文件中 /bin/kill -USR1 cat /home/work/run/nginx.pid 2&gt; /dev/null 2> /dev/null || true endscript}在使用前，我们先演练一下，也就是debug模式，此时，不用实际轮循，而是模拟并输出，使用强制执行是因为还没到轮循周期：$logrotate -d -f /etc/logrotate.d/nginxAccessLog reading config file /etc/logrotate.d/nginxAccessLogreading config info for /home/work/log/nginx.access.logHandling 1 logsrotating pattern: /home/work/log/nginx.access.log forced from command line (7 rotations)empty log files are rotated, old logs are removedconsidering log /home/work/log/nginx.access.log log needs rotatingrotating log /home/work/log/nginx.access.log, log->rotateCount is 7dateext suffix ‘-20190228’glob pattern ‘-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]‘glob finding old rotated logs failedrenaming /home/work/log/nginx.access.log to /home/work/log/nginx.access.log-20190228creating new /home/work/log/nginx.access.log mode = 0664 uid = 500 gid = 501running postrotate scriptrunning script with arg /home/work/log/nginx.access.log: " /bin/kill -USR1 cat /home/work/run/nginx.pid 2&gt; /dev/null 2> /dev/null || true"可以看到整个执行流程，以及没有什么报错信息，此时我们直接继续执行：$logrotate -f /etc/logrotate.d/nginxAccessLog$ll /home/work/lnmp/log/ -rw-r–r– 1 work work 0 Feb 28 13:40 nginx.access.log-rw-r–r– 1 work work 5379846 Feb 28 13:37 nginx.access.log-20190228可以看到我们已经对日志进行了切分，最新的日志文件大小为0。以后系统就会对该日志进行自动的轮转管理。参考资料Linux日志文件总管——logrotate：https://linux.cn/article-4126…logrotate-(8) manual page：https://linuxconfig.org/logro…运维中的日志切割操作梳理：https://www.cnblogs.com/kevin… ...

一、 总览本文章不对日志组件进行优劣评价，只是对关系进行对比。在日志中组件中存在这样的几种关系， 这几种关系理解清楚， 有助于我们对日志的引入和使用。二、 日志门面日志门面就是指直接引入我们程序中进行记录日志的日志组件，作为日志门面的这些组件会在程序中直接依赖， 上图中就列举的几种常见的日志门面的组件。像一些软件直接回默认使用一些组件， 比如Spring使用的就是commons-logging, activiti使用的日志门面就是slf4j, 其他的软件也都会选用自己认为好用的日志门面。三、 日志实现除了log4j既是门面又是实现之外， commons-logging和slf4j 都是能直接打印日志的， 都需要依赖一个日志实现来打印日志，上图中也举了几个日志实现。四、桥接方式slf4j默认和logback做了一些桥接的处理，那么桥接的作用是什么呢， 假如我想使用slf4j做为实现的门面，然而同时我想使用log4j作为真正的日志实现，这个时候就需要slf4j-logrj12 jar包， 现在应该可以理解桥接方式了。五、 改变依赖这里的作用是为了避免一些冲突， 例如在这样的场景下，我们使用spring做为开发，而我们开发的软件要使用的是slf4j作为日志门面，这个时候因为Spirng默认使用的是commons-logging作为日志门面，这个时候就会发生一些冲突， 所以我们可以引入jcl-over-slf4j， 通过这个组件把commons-logging覆盖掉， 为了把历史软件内部的依赖覆盖掉， 就可通过这个方式改变依赖。