日志文件

在CentOS 7开始使用的systemd使用了journal日志，这个日志的管理方式和以往使用syslog的方式不同，可以通过管理工具维护。 使用 df -h 检查磁盘文件，可以看到 /run 目录下有日志目录 /run/log/journal ，占用了数G空间 Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 8.5G 4.2G 4.4G 49% / tmpfs 16G 1.6G 15G 11% /run 在日志目录下有很多历史累积的日志。 检查当前journal使用磁盘量 journalctl --disk-usage 清理方法可以采用按照日期清理，或者按照允许保留的容量清理 journalctl --vacuum-time=2d journalctl --vacuum-size=500M 如果要手工删除日志文件，则在删除前需要先轮转一次journal日志 systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald.service 要启用日志限制持久化配置，可以修改 /etc/systemd/journald.conf SystemMaxUse=16M ForwardToSyslog=no 然后重启 systemctl

一.背景 Linux服务器上，程序运行一段时间后，日志可能占满了磁盘，导致磁盘可用空间告警，这时就需要批量清空（非删除）日志文件 二.错误做法 一般可能会写个批量删除的脚本，定时去运行，形如： #!/bin/bash # 查看/opt目录下，所有日志文件及大小 find /opt -name *.log | xargs du -sh # 删除/opt目录下所有的日志文件 find /opt -name *.log | xargs rm -rf 上面的命令可以完成删除的效果，但会引入一些问题，因为日志文件可能此时正在被程序使用，直接删除后，导致程序日志无法写入（删除后无法自动创建），必须重启服务后才能自动创建日志文件并再次写入。 这也正是我们查看日志时提示日志文件不存在，但系统进程存在而且系统可正常使用的原因所在。 三.正确做法 正确的做法是： 1. 删除非当天的日志文件；（一般程序日志会配置日切，每日一个文件） 2. 清空当天的日志文件； #!/bin/bash # 查看/opt目录下，所有【非当天】的日志文件及大小 find /opt -name *.log.* | xargs du -sh # 删除/opt目录下所有【非当天】的日志文件 find /opt -name *.log.* | xargs rm -rf # 查看/opt目录下，所有【当天】日志文件及大小 find

#include <stdio.h> #include<windows.h> #include <time.h> #define Line __LINE__ #define File __FILE__ void WriteLog(const char *file, int line, char * msg) { SYSTEMTIME st; GetLocalTime(&st); FILE *fp; fp=fopen("D:\\log.txt","at"); fprintf(fp,"MyLogInfo: %d-%d-%d %d:%d:%d %s:%d: % s\n",st.wYear,st.wMonth,st.wDay,st.wHour,st.wMinute,st.wSecond, file,line, msg); printf(" %d-%d-%d %d:%d:%d %s:%d: %s\n",st.wYear,st.wMonth,st.wDay,st.wHour,st.wMinute,st.wSecond, file,line, msg); fclose(fp); // OutputDebugStringA(msg); } int main(int , char**) { WriteLog(File,Line, " now error...."); return 0; }

1 日志管理 1.1 Nginx日志描述 通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息；通过错误日志，你可以得到系统某个服务或server的性能瓶颈等。因此，将日志好好利用，你可以得到很多有价值的信息。 1.2 Nginx日志格式 打开nginx.conf配置文件：vim /usr/local/nginx/conf/nginx.conf 日志部分内容： #access_log logs/access.log main; 日志生成的到Nginx根目录logs/access.log文件，默认使用“main”日志格式，也可以自定义格式。 默认“main”日志格式： 参数明细表： $remote_addr 客户端的ip地址(代理服务器，显示代理服务ip) $remote_user 用于记录远程客户端的用户名称（一般为“-”） $time_local 用于记录访问时间和时区 $request 用于记录请求的url以及请求方法 $status 响应状态码，例如：200成功、404页面找不到等。 $body_bytes_sent 给客户端发送的文件主体内容字节数 $http_user_agent 用户所使用的代理（一般为浏览器） $http_x_forwarded_for 可以记录客户端IP，通过代理服务器来记录客户端的ip地址 $http_referer

查看容器日志 先使用 docker run -it --rm -d -p 80:80 nginx:1.15.8-alpine 命令启动一个nginx容器。如果没有异常，会得到容器ID如 d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00 的长串。再使用 curl -i http://127.0.0.1 访问服务，确认nginx容器正常启动运行。最后使用 docker logs -f d24 查看容器的日志输出，大概如下： ? 1 172.17.0.1 - - [24/Mar/2019:03:51:21 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-" 一般来说使用容器ID的前3位即可 以上就是我们查看容器日志的日常方法了，非常简单实用。 容器日志文件存储 容器的日志会以json文件方式存储在本地磁盘，可以使用下面方式查看文件路径 docker inspect d42 | grep Log 可以找到: "LogPath": "/var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00

linux定时清理tomcat日志文件 需求：最近公司服务器发现磁盘经常会被占满，查其原因是因为大量的日志文件。所有需要每天定时去清理过期的日志文件 一：编写脚本 [Shell] 纯文本查看 复制代码 ? 1 [root@localhost home] # vim clean_catalina.sh 添加内容如下： [Shell] 纯文本查看 复制代码 ? 1 2 3 4 5 6 # 删除 /opt/java/tomcat7/logs/下5天前,文件名称包含"201"的logs find /opt/java/tomcat7/logs/ -mtime +5 -name "*201?*" - exec rm -rf {} \; # 清空 /opt/java/tomcat7/logs/下的catalina.out echo " " > /opt/java/tomcat7/logs/catalina .out 赋权 [Shell] 纯文本查看 复制代码 ? 1 [root@localhost home] # chmod 755 clean_catalina.sh 二：设置定时执行clean_catalina.sh脚本 [root@localhost home]# crontab -e 添加内容如下： 10 0 * * * /home/clean_catalina.sh 三：重启定时任务

logback优点 比较吸引的几个优点如下： 内核重写，初始化内存加载更小 文档比较齐全 支持自动重新加载配置文件，扫描过程快且安全，它并不需要另外创建一个扫描线程 支持自动去除旧的日志文件，可以控制已经产生日志文件的最大数量 logback加载 在项目中引入logback依赖： <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback.version}</version> </dependency> 启动项目时，logback会按照如下顺序扫描配置文件： 在系统配置文件System Properties中寻找是否有logback.configurationFile对应的value 在classpath下寻找是否有logback.groovy（即logback支持groovy与xml两种配置方式） 在classpath下寻找是否有logback-test.xml 在classpath下寻找是否有logback.xml 以上任何一项找到了，就不进行后续扫描，按照对应的配置进行logback的初始化，可从控制台输出信息中查看加载的配置文件。 当所有以上四项都找不到的情况下，logback会调用 ch.qos.logback

USE DB_MPS_20181210 GO ALTER DATABASE DB_MPS_20181210 SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE DB_MPS_20181210 SET RECOVERY SIMPLE --更改为简单模式 GO USE DB_MPS_20181210 GO DBCC SHRINKFILE ('数据库日志名',2, TRUNCATEONLY) --设置压缩后的日志大小为2M，且释放的空间不归还给操作系统 GO USE DB_MPS_20181210 GO ALTER DATABASE DB_MPS_20181210 SET RECOVERY FULL WITH NO_WAIT GO ALTER DATABASE DB_MPS_20181210 SET RECOVERY FULL --还原为完全模式 GO --上面的数据库日志名,可以用以下的语句进行查询 USE DB_MPS_20181210 GO SELECT FILE_ID, NAME FROM SYS.DATABASE_FILES; GO 参考： https://www.cnblogs.com/zdyang/p/11718197.html 来源： CSDN 作者： ^_^laoz^_^ 链接： https://blog.csdn

log-structed 日志结构 哈希索引 SSTable 与 LSM树 日志文件的压缩 分段 合并 page-oriented 面向页面 B树 数据库 聚集索引 非聚集索引 多列索引 数据分析 列存储 1 最简单的数据库 #!/bin/bash db_set () { echo "$1,$2" >> database } db_get () { grep "^$1," database | sed -e "s/^$1,//" | tail -n 1 } 最简单的数据库，日志结构，写很快，读很慢。可以看出，对于日志结构的数据库，要在读操作上做优化。 为了加快读，可以添加索引。但是索引会拖慢写操作，因此只给需要频繁读的字段添加索引。 2 哈希索引 最容易想到的一种索引策略就是哈希索引。 数据以追加写的方式存储在文件中，内存里保留一个哈希表，key 为索引字段的值，value 为偏移量，如下图所示。该方法适用于键值更新频繁的场景，并且键的总量放在内存中可以hold得住。 Bitcask 就是基于哈希索引的，详见 Bitcask 存储模型 压缩、分段、合并 以上讨论的数据库都是追加日志的，这就需要考虑在日志文件过大时，对文件进行压缩、分段、合并等操作。 数据库的历史指令可能重复对一个键进行操作，显然只需要保留每个键的最新更新就行，这就需要对数据库文件进行分段压缩。在压缩时

Linux计划任务与日志的管理 本节所讲内容： 16.1 计划任务-at-cron-计划任务使用方法 16.1.1 计划任务的应用场景 计划任务在实际运用很多，现结合日常工作的实际例外列举几个： 1、管理的SQL 2008数据库时结合计划任务对重要数据库备份 2、管理的SQL 2008数据库时结合计划任务与批处理对规定时间前的备份数据进行删除 4、管理的WEB服务器会结合计划任务备份相关数据到其他服务器上 5、管理的WEB服务器会结合计划任务删除不需要的访问日志数据 等等 由此可见计划任务在我们的实际运维工作中得到很广泛的运用 16.1.2 crond 和 atd 说明 crond是定时性的，每隔一定的周期就要重复来做这个事情 atd是突发性的，只是在特定时间执行一次任务，完成后就结束 1）at计划任务的使用 [root@node-1 ~]# rpm -aq |grep atd [root@node-1 ~]# yum -y install at [root@node-1 ~]# systemctl start atd [root@node-1 ~]# systemctl status atd ● atd.service - Job spooling tools Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled