日志文件

文章目录 默认日志框架--配置全解 日志格式 日志级别 日志输出到控制台 日志输出到文件 spring boot2.2.4官方文档 默认日志框架–配置全解 #日志记录 logging : #日志级别 level : #可以调整不同目录的日志级别(注意：必须指定包，否则报错) root : info com.cd.example.one : trace com.cd.example.two : debug com.cd.example.three : info #日志文件 file : #日志文件完整路径（包含日志文件名） name : D : \idea\logs\example - loggin.log #日志文件目录路径（spring boot默认使用spring.log作为日志文件） #path: D:\idea\log #文件大小（默认10MB） max-size : 10MB #文件保存周期（默认7天，七天之后就会删除） max-history : 7 #日志输出格式 pattern : #在控制台输出的日志格式 console : - %d { yyyy - MM - dd HH : mm : ss } - %clr(% - 5level) - [ %thread ] - %logger { 50 } - - %clr(%msg) %n #在文件输出的日志格式 file

前言 这篇博文以课程课件为蓝本来探讨logrotate和自动化日志处理的一系列课题，细节和深层次原理部分略有删减， 是一篇被课程耽误了的技术博文。 既然谈的很直白，是一篇被课程耽误了的技术博文，如若有打着博客做引导或者拿着开源工具不开源之类的讨伐和道德绑架，恕不回复。 这里是分割线，不废话了，直接切入正文，对课程有兴趣，想深入理解logrotate的朋友可以关注文末课程介绍:） 1.日志切割的概念、必要性和基本思路 1.1 什么是日志切割 日志切割是指当应用或系统的日志文件达到设定的触发条件（如按照一定的时间周期：每天，按照大小：500MB），对其进行切割/分割处理，类似截断处理，把原本容量比较大的日志文件“劫走”转存为另外一个日志文件留存归档，这一刻之后产生的日志，继续输出到文件头被重置为0的日志文件中。 变化的部分 ：日志文件的容量（瘦身变小），日志文件的个数（多出一份被切割下的历史日志） 不变的部分 ：日志文件名不变 此外，一段时间后，我们还需要删除时间久远的日志文件，整个过程也被俗称为日志滚动(log rotation)。 1.2 为什么要进行日志切割 在线应用（包括操作系统）在长期运行过程中，会产生很多过程日志记录，通常是应用程序记录的一些对系统管理员或者程序开发者有用的信息的文件，诸如正在执行什么、发生了什么错误等一系列信息。 随着日志记录的不断积累，日志文件越来越大

waterdrop过滤处理日志文件，将数据入库 安装waterdrop 使用wget下载waterdrop 的安装包 wget xxxxx 解压至你需要的目录 unzip xxx(包位置) xxx(解压位置) 这里如果unzip 报错，请自己下载对应命令。 在目录的 config 中设置依赖环境，java Spark vim ./waterdrop-env.sh #!/usr/bin/env bash # Home directory of spark distribution. SPARK_HOME=/extends/soft/spark-2.4.4 JAVA_HOME=/usr/java/jdk1.8.0_202-amd64 HADOOP_HOME=/extends/soft/hadoop-2.7.4 进入一个config 复制之前的一个示例，进行修改。 建立 config 配置文件进行处理数据 因为我这边的做的处理是读取log 日志。筛选有效数据。进行存入 配置文件贴出 ###### ###### This config file is a demonstration of batch processing in waterdrop config ###### spark { # You can set spark configuration here # see

Zabbix 日志文件监控 一、给运行Zabbix agent的用户授予要监控日志的读取权限。 1. 執行下面的命令，追加app的可讀權限： setfacl -m u:app:r-- /var/log/messages 2. 修改logrotate配置 sed -i '/kill/a\/usr\/bin\/setfacl -m u:app:r-- \/var\/log\/messages' /etc/logrotate.d/syslog 二、在OS Template添加监控Item，主要Type要选主动模式，Key填写从目标文件中提取感兴趣的值，而不是在找到正则表达式匹配时返回整行。 三、添加Triggers，表达式的意思说如果匹配到监控日志里有该关键字发出告警，如果60s过后没匹配到则告警取消。 四、'Hostname'参数与前端的主机名要一致，否则告警在dashboard上会显示与主机不一致。 /etc/zabbix/zabbix_agentd.conf 五、效果 参考： https://www.zabbix.com/documentation/4.0/manual/config/items/itemtypes/log_items 来源： https://www.cnblogs.com/Dev0ps/p/12346660.html

Oracle DataGuard是Oracle自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用性方案。 DataGuard可以提供Oracle数据库的冗灾、数据保护、故障恢复等，实现数据库快速切换与灾难性恢复。在生产数据库的保证"事务一致性"时，使用生产库的物理全备份创建备库，备库会通过生产库传输过来的归档日志或重做条目自动维护备用数据库。 DataGuard数据同步技术有以下优势： 1） Oracle数据库自身内置的功能，与每个Oracle新版本的新特性都完全兼容，且不需要另外付费。 2） 配置管理较简单，不需要熟悉其他第三方的软件产品。 3） 物理Standby数据库支持任何类型的数据对象和数据类型； 4） 逻辑Standby数据库处于打开状态，可以在保持数据同步的同时执行查询等操作。 5） 在最大保护模式下，可确保数据的零丢失。 一、架构 Oracle DataGuard由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可以分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，不受操作系统的限制。 1.Primary 数据库

zookeeper服务器会产生三类日志：事务日志、快照日志和log4j日志。 在zookeeper默认配置文件zoo.cfg（可以修改文件名）中有一个配置项dataDir，该配置项用于配置zookeeper快照日志和事务日志的存储地址。在官方提供的默认参考配置文件zoo_sample.cfg中，只有dataDir配置项。其实在实际应用中，还可以为事务日志专门配置存储地址，配置项名称为dataLogDir，在zoo_sample.cfg中并未体现出来。在没有dataLogDir配置项的时候，zookeeper默认将事务日志文件和快照日志文件都存储在dataDir对应的目录下。建议将事务日志（dataLogDir）与快照日志（dataLog）单独配置，因为当zookeeper集群进行频繁的数据读写操作是，会产生大量的事务日志信息，将两类日志分开存储会提高系统性能，而且，可以允许将两类日志存在在不同的存储介质上，减少磁盘压力。log4j用于记录zookeeper集群服务器运行日志，该日志的配置地址在conf/目录下的log4j.properties文件中，该文件中有一个配置项为“zookeeper.log.dir=.”，表示log4j日志文件在与执行程序（zkServer.sh）在同一目录下。当执行zkServer.sh 时，在该文件夹下会产生zookeeper.out日志文件

告警日志介绍 告警日志文件是一类特殊的跟踪文件（trace file）。告警日志文件命名一般为alert_<SID>.log，其中SID为ORACLE数据库实例名称。数据库告警日志是按时间顺序记录message和错误信息。 告警日志位置 在ORACLE 10g中，BACKGROUND_DUMP_DEST参数确定了告警日志的位置，但是告警日志的文件名无法修改，告警日志的名称为：alert_<SID>.log ,其中<SID>是实例的名称。BACKGROUND_DUMP_DEST参数是动态的。 SQL> show parameter background_dump_dest; NAME TYPE VALUE --------------------- ----------- ------------------------------ background_dump_dest string /u01/app/oracle/admin/GSP/bdump SQL> 告警日志以及所有后台跟踪文件都会被写至BACKGROUND_DUMP_DEST参数所指定的目录。 在ORACLE 11g 以及ORACLE 12c中，告警日志文件的位置有了变化。主要是因为引入了ADR(Automatic Diagnostic Repository:一个存放数据库诊断日志、跟踪文件的目录)

这个作业属于哪个课程 2020春|S班(福州大学) 这个作业要求在哪里 软工实践寒假作业(2/2) 作业的目标 学习使用Git、学习和了解效能分析及个人软件开发流程（PSP） 作业正文 其他参考文献 《构建之法》 阅读心得 ........... 个人软件开发流程（PSP） PSP2.1 Personal Software Process Stages 预估耗时(min) 实际耗时(min) Planning 计划 Estimate 估计这个任务需要多少时间 Development 开发 Analysis 需求分析 (包括学习新技术) 90 90 Design Spec 生成设计文档 Design Review 设计复审 Coding Standard 代码规范 (为目前的开发制定合适的规范) 30 30 Design 具体设计 Coding 具体编码 300 510 Code Review 代码复审 Test 测试（自我测试，修改代码，提交修改） 180 150 Reporting 报告 60 Test Repor 测试报告 Size Measurement 计算工作量 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 合计 解题过程 坎坷的学习经历 当我看到作业的时候第一反应是啥也不会，虽然好像有挺长时间的

转自 http://blog.csdn.net/indexman/article/details/7746948 以下易容翻译自oracle dba官方文档，不足之处还望指出。 管理重做日志文件 学习目标： 1.解释重做日志文件的目的 2.描述重做日志文件的结构 3.学会控制日志切换与检查点 4.多元化管理重做日志文件 5.使用OMF管理重做日志文件 1.概念介绍： 重做日志文件通过记录数据的所有改变情况对系统或介质故障提供恢复机制。 1）重做日志文件以组的形式存在 2）一个oracle数据库至少需要两组,每组至少有一文件 3）在一组里的每一重做日志文件叫做成员 The redo log files are used only for recovery. 2.重做日志文件结构： 1）重做日志文件组 a.一组相同的副本联机重做日志文件被称为一个联机重做日志组。 b.LGWR进程并发的往日志组里所有重做日志文件写入相同信息 2）重做日志文件 a.一个组每个成员用于同一log sequence numbers和相同的大小 b.每次oracle服务器开始写入日志组时分配日志序列号来唯一标识每个重做日志文件 c.当前的日志序列号存储在控制文件和所有数据文件的头部 3.重做日志如何工作？ 1）重做日志以循环的方式使用 2）当一个重做日志文件写满，LGWR进程将移动到下一日志组 a

重做日志文件时为了数据库恢复的物理文件，其中保存了数据库的变更操作信息。 通过重做日志文件通常是通过重做（REDO）或者是回退（UNDO）实现的。 重做（REDO）就是有些原因到导致事务对数据库的操作的修改在写入数据文件之前丢失了，此时就可以利用重做日志文件做该事务对数据库的变更。 回退（UNDO）如果用户在事务提交之前想回滚事务，那么可以利用重做日志文件撤销事务对数据库所做的变更。 重做日志文件的工作原理：每个数据库至少有两个重做日志文件，采用循环邪写的方式进行工作。这样就能保证当一个重做日志文件在进行归档时，还有另一个重做日志文件可用。当一个重做日志文件被写满后，后台进行就 开始写下一个重做日志文件。当所有的重做日志文件都写满后，LGWR进程再重新开始写入第一个重做日志文件，开始新的循环。 通常LGWR进程再开始下一个重做日志之前要确定： 该重做日志文件中的所有重做记录所对应的变更操作结果必须全部写入数据文件中。如果数据库处于“归档模式”，要确定对该重做日志文件进行了归档。 重做日志文件切换与日志序列号 重做日志文件切换是指LGWR对一个重做日志文件停止写入，开始对另一个重做日志文件写入的过程。 日志序列号：当每次发生重做日志切换时，数据库赋予重做日志文件一个日志序列号（log sequence number）,LGWR进程将该序列号写入相应的重做日志文件。