AI 助理
备案控制台
开发者社区 数据库 文章 正文

Oh！MongoDB日志从文本穿越成了图片？咋整！

2018-09-14 2199
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 MongoDB，独享型 2核8GB
推荐场景：
构建全方位客户视图
日志服务 SLS，月写入数据量 50GB 1个月
简介： 摘要： 突发MongoDB集群中的某个分片节点CPU飙高，初步判断是慢查询，现在需要拉取CPU飙高时间段的慢查询。拉取慢查询应该很快，不就是个系统日志吗？而且还做了日志切割一天一个，按道理很快搞定的，谁知当天晚上搞了接近三个小时也没搞定。

摘要：

突发MongoDB集群中的某个分片节点CPU飙高，初步判断是慢查询，现在需要拉取CPU飙高时间段的慢查询。拉取慢查询应该很快，不就是个系统日志吗？而且还做了日志切割一天一个，按道理很快搞定的，谁知当天晚上搞了接近三个小时也没搞定。究竟发生了什么？

进入到日志目录一看，目前保留近7天的日志，每天的日志量在23G~24G，我当时就想怎么数据量这么大！后续发现日志格式本该为普通文本文件确变成了图片格式，究竟为何会文件格式会转变？能否从图片格式中拉取指定时间段的日志呢？经过了一番折腾总算把原因找到了，具体过程请看下文！

数据库明细

  • 数据库：MongoDB集群 4个分片节点
  • 分片节点规格：16核 / 32G CentOS 7.4 64位
  • 数据目录所在磁盘: 300G 49G 252G 17% /data

复现与剖析

拉取日志异常

使用mlogfilter过滤文件时报错说文件非mongodb的日志文件

[root@sh_01 booboo]# mlogfilter shard.log.2018-08-01 --from 2018-08-01T15:00:00.000+0800 --to "+1h" --slow 1000 > /alidata/booboo/tf.1
报错:非mongodb日志格式

回到客户服务器检查日志文件格式，明细如下：

[root@MONGO-SHARD-18 logs]# file *
shard.log:            PCX ver. 2.5 image data
shard.log.2018-07-25: PCX ver. 2.5 image data
shard.log.2018-07-26: PCX ver. 2.5 image data
shard.log.2018-07-27: PCX ver. 2.5 image data
shard.log.2018-07-28: PCX ver. 2.5 image data
shard.log.2018-07-29: PCX ver. 2.5 image data
shard.log.2018-07-30: PCX ver. 2.5 image data
shard.log.2018-07-31: PCX ver. 2.5 image data
shard.log.2018-08-01: PCX ver. 2.5 image data

mongodb的日志正常应该为：ASCII text, with very long lines，但是现在却变成了PCX ver. 2.5 image data。需要弄清楚原因。

日志异常分析

  • 为什么客户每天的日志量达到22个G，并且每天的日志量都是大于等于前一天？很显然，日志截断有问题。
  • 这个是近7天的日志，而日志格式变成了PCX图片格式是为何？
  • 怀疑每次日志轮询时都没有真正截断日志！

分析原日志切割明细

怀疑与echo > 有关，进行验证。

验证echo >与PCX图片头部0a一致

  1. 建一个空文档log；执行echo > log；通过cat -A log 查看文件中插入了一个符号即换行符\n
  2. 通过hexdump -c log 查看测试文件头部显示为ASCII字符 \n
  3. 通过hexdump -d log 查看测试文件头部显示为16进制 00010 即 0a
  4. 通过vim 用16进制查看文档log可以看到log的文件头部为0a，正是PCX图片的头部
  5. 生产环境查看客户有问题的mongodb系统日志文件格式为PCX图片格式
  6. 通过hexdump -c log 显示为ASCII字符，生产日志文件头部与测试的log一致，都是\n
  7. 通过hexdump -d log显示为16进制，生产日志文件头部与测试的log一致00010 即 0a

到此验证成功:通过echo > log的方式会往文件头部新增'0a'

复现MongoDB日志从ASCII text转变为PCX 格式

在测试环境中复现日志从ASCII text变成PCX ver. 2.5 image data

  1. 通过mongo登陆数据库执行大量的插入操作
  2. 通过echo > mongod27017.log 命令尝试清空mongod27017.log
  3. 查看截断后的日志文件格式，变成了very short file (no magic)
  4. 等文档插入完毕
  5. 通过tail -f 查看日志明细，看到确实有日志写入
  6. 查看日志格式，发现变成了PCX ver. 2.5 image data

[root@sh_01 ~]# mongo
MongoDB shell version: 3.2.16
connecting to: test
> db.auth('test_dev','uplooking')
1
> db.t1.find()
{ "_id" : ObjectId("5b5ebb6796b8b74a73ee30f6"), "a" : 1, "b" : 2 }
{ "_id" : ObjectId("5b5ebb6996b8b74a73ee30f7"), "a" : 1, "b" : 1 }
> for (i=1;i<200000;i++){
... db.t1.insert({id:i})}
WriteResult({ "nInserted" : 1 })

[root@sh_01 ~]# cd /alidata/mongodb/logs
[root@sh_01 log]# ll
-rw-r--r-- 1 root root 2182 Aug  3 10:28 mongod27017.log
-rw-r--r-- 1 root root 3100 Aug  2 14:19 mongod27017.log.2018-08-02T07-18-27
-rw-r--r-- 1 root root 1526 Aug  2 15:18 mongod27017.log.2018-08-02T07-18-54
[root@sh_01 log]# file *
mongod27017.log:                     ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines

[root@sh_01 log]# echo > mongod27017.log
[root@sh_01 log]# echo > mongod27017.log
[root@sh_01 log]# ll
total 12
-rw-r--r-- 1 root root    1 Aug  3 10:29 mongod27017.log
-rw-r--r-- 1 root root 3100 Aug  2 14:19 mongod27017.log.2018-08-02T07-18-27
-rw-r--r-- 1 root root 1526 Aug  2 15:18 mongod27017.log.2018-08-02T07-18-54
[root@sh_01 log]# file *
mongod27017.log:                     very short file (no magic)
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines

[root@sh_01 log]# tail -f mongod27017.log

2018-08-03T10:30:21.936+0800 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:43720 #2 (2 connections now open)

[root@sh_01 log]# ll -h
total 12K
-rw-r--r-- 1 root root 2.8K Aug  3 10:30 mongod27017.log
-rw-r--r-- 1 root root 3.1K Aug  2 14:19 mongod27017.log.2018-08-02T07-18-27
-rw-r--r-- 1 root root 1.5K Aug  2 15:18 mongod27017.log.2018-08-02T07-18-54
[root@sh_01 log]# file *
mongod27017.log:                     PCX ver. 2.5 image data
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines


# 一边不断产生日志，一边多次执行echo> 
[root@sh_01 log]# echo > mongod27017.log
[root@sh_01 log]# echo > mongod27017.log
[root@sh_01 log]# file *
mongod27017.log:                     PCX ver. 2.5 image data
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines
mongod27017.log.2018-08-03T03-09-08: PCX ver. 2.5 image data
[root@sh_01 log]# echo > mongod27017.log
[root@sh_01 log]# file *
mongod27017.log:                     very short file (no magic)
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines
mongod27017.log.2018-08-03T03-09-08: PCX ver. 2.5 image data
[root@sh_01 log]# ll -h
total 16K
-rw-r--r-- 1 root root    1 Aug  3 11:28 mongod27017.log
-rw-r--r-- 1 root root 3.1K Aug  2 14:19 mongod27017.log.2018-08-02T07-18-27
-rw-r--r-- 1 root root 1.5K Aug  2 15:18 mongod27017.log.2018-08-02T07-18-54
-rw-r--r-- 1 root root 2.9K Aug  3 11:05 mongod27017.log.2018-08-03T03-09-08
[root@sh_01 log]# file *
mongod27017.log:                     very short file (no magic)
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines
mongod27017.log.2018-08-03T03-09-08: PCX ver. 2.5 image data
[root@sh_01 log]# file *
mongod27017.log:                     PCX ver. 2.5 image data
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines
mongod27017.log.2018-08-03T03-09-08: PCX ver. 2.5 image data
[root@sh_01 log]# hexdump -c mongod27017.log
0000000  \n  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000010  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000850  \0  \0  \0  \0  \0  \0  \0   2   0   1   8   -   0   8   -   0
0000860   3   T   1   1   :   2   9   :   0   6   .   7   2   9   +   0
0000870   8   0   0       I       A   C   C   E   S   S               [
0000880   c   o   n   n   3   ]       U   n   a   u   t   h   o   r   i
0000890   z   e   d   :       n   o   t       a   u   t   h   o   r   i
00008a0   z   e   d       o   n       t   e   s   t       t   o       e
00008b0   x   e   c   u   t   e       c   o   m   m   a   n   d       {
00008c0       f   i   n   d   :       "   t   1   "   ,       f   i   l
00008d0   t   e   r   :       {   }       }  \n

成功复现情况：

  1. 第一次echo > log，文件头部新增\n

  2. 多次echo > log,文件头部如下：

    0000000  \n  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000010  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*

确实是mongodb日志轮询出了问题：

  1. echo > log会往文件头部插入\n即16进制的0a
  2. 在数据库正常运行中，对log文件是加了锁的，强制执行echo > log是无法进行覆盖的，会将所有的数据全部置为0
  3. 强制覆盖后，文件头部变成了无数的空白

待解决问题

  • MongoDB日志轮询方法调整为kill -SIGUSER1 [mongodpid]
  • 修复目前已经变为图片格式的日志，并拉取15点到16点的日志

解决方法

MongoDB日志轮询

测试环境

[root@sh_01 log]# pidof mongod
1828
[root@sh_01 log]# kill -SIGUSER1 1828
-bash: kill: SIGUSER1: invalid signal specification
[root@sh_01 log]# kill -SIGUSR1 1828
[root@sh_01 log]# ll
total 16
-rw-r--r-- 1 root root 1526 Aug  3 11:09 mongod27017.log
-rw-r--r-- 1 root root 3100 Aug  2 14:19 mongod27017.log.2018-08-02T07-18-27
-rw-r--r-- 1 root root 1526 Aug  2 15:18 mongod27017.log.2018-08-02T07-18-54
-rw-r--r-- 1 root root 2942 Aug  3 11:05 mongod27017.log.2018-08-03T03-09-08
[root@sh_01 log]# file *
mongod27017.log:                     ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-27: ASCII text, with very long lines
mongod27017.log.2018-08-02T07-18-54: ASCII text, with very long lines
mongod27017.log.2018-08-03T03-09-08: PCX ver. 2.5 image data

生产环境

修改日志轮询脚本：

[root@MONGO-SHARD-18 logs]# cat /etc/init.d/mongo_logspit.sh 
#!/bin/bash
# 2018/08/02 Apple
#Rotate the MongoDB logs to prevent a single logfile from consuming too much disk space.

cmd=mongod
mongodpath=/opt/mongodb/bin
pidarray=`pidof ${mongodpath}/$cmd`
LOGPATH_SHARD=/data/mongodb/shard1/logs

for pid in $pidarray;do
if [ $pid ]
then
    kill -SIGUSR1 $pid
fi
done
#clear logfile more than 7 days
cd $LOGPATH_SHARD
find ./ -xdev -mtime +7 -name "shard.log.*" -exec rm -f {}  \;

所有的分片都去执行：

kill -SIGUSR1 pidof mongod

分片15操作如下：其他分片同样

[zyadmin@MONGO-SHARD-15 ~]$ sudo -i
[root@MONGO-SHARD-15 ~]# cd /data/mongodb/shard1/logs/
[root@MONGO-SHARD-15 logs]# ll -h
total 1.7G
-rw-r--r-- 1 root root 20G Aug  2 15:27 shard.log
-rw-r--r-- 1 root root 19G Jul 25 23:50 shard.log.2018-07-25
-rw-r--r-- 1 root root 19G Jul 26 23:50 shard.log.2018-07-26
-rw-r--r-- 1 root root 19G Jul 27 23:50 shard.log.2018-07-27
-rw-r--r-- 1 root root 20G Jul 28 23:50 shard.log.2018-07-28
-rw-r--r-- 1 root root 20G Jul 29 23:50 shard.log.2018-07-29
-rw-r--r-- 1 root root 20G Jul 30 23:50 shard.log.2018-07-30
-rw-r--r-- 1 root root 20G Jul 31 23:50 shard.log.2018-07-31
-rw-r--r-- 1 root root 20G Aug  1 23:50 shard.log.2018-08-01
[root@MONGO-SHARD-15 logs]# file *
shard.log:            PCX ver. 2.5 image data
shard.log.2018-07-25: PCX ver. 2.5 image data
shard.log.2018-07-26: PCX ver. 2.5 image data
shard.log.2018-07-27: PCX ver. 2.5 image data
shard.log.2018-07-28: PCX ver. 2.5 image data
shard.log.2018-07-29: PCX ver. 2.5 image data
shard.log.2018-07-30: PCX ver. 2.5 image data
shard.log.2018-07-31: PCX ver. 2.5 image data
shard.log.2018-08-01: PCX ver. 2.5 image data
[root@MONGO-SHARD-15 logs]# kill -SIGUSR1 `pidof mongod`
[root@MONGO-SHARD-15 logs]# file *
shard.log:                     ASCII text, with very long lines
shard.log.2018-07-25:          PCX ver. 2.5 image data
shard.log.2018-07-26:          PCX ver. 2.5 image data
shard.log.2018-07-27:          PCX ver. 2.5 image data
shard.log.2018-07-28:          PCX ver. 2.5 image data
shard.log.2018-07-29:          PCX ver. 2.5 image data
shard.log.2018-07-30:          PCX ver. 2.5 image data
shard.log.2018-07-31:          PCX ver. 2.5 image data
shard.log.2018-08-01:          PCX ver. 2.5 image data
shard.log.2018-08-02T07-27-29: PCX ver. 2.5 image data
[root@MONGO-SHARD-15 logs]# ll -h
total 1.7G
-rw-r--r-- 1 root root 2.0K Aug  2 15:27 shard.log
-rw-r--r-- 1 root root  19G Jul 25 23:50 shard.log.2018-07-25
-rw-r--r-- 1 root root  19G Jul 26 23:50 shard.log.2018-07-26
-rw-r--r-- 1 root root  19G Jul 27 23:50 shard.log.2018-07-27
-rw-r--r-- 1 root root  20G Jul 28 23:50 shard.log.2018-07-28
-rw-r--r-- 1 root root  20G Jul 29 23:50 shard.log.2018-07-29
-rw-r--r-- 1 root root  20G Jul 30 23:50 shard.log.2018-07-30
-rw-r--r-- 1 root root  20G Jul 31 23:50 shard.log.2018-07-31
-rw-r--r-- 1 root root  20G Aug  1 23:50 shard.log.2018-08-01
-rw-r--r-- 1 root root  20G Aug  2 15:27 shard.log.2018-08-02T07-27-29

修复异常日志

修复思路

弄清楚日志变更的原因以及复现过程后，不难发现，日志因为头部变化从而导致文件格式变更。因此推测异常日志的组成如下：

  1. 头部为0a
  2. 中间全部都是0
  3. 最后是正常的字符串记录着mongodb的日志信息，类似于2018-08-03T10:30:21.936+0800 I NETWORK [initandlisten] connection accepted from 127.0.0.1:43720 #2 (2 connections now open)由日志和日志明细组成

因此修复的思路如下：

  • 23G的日志，首先按照大小6G做切分split -b 6G log，切分成4个文件
  • 查看切分后的日志格式，如果最后一个日志为ASCII text则不再切分否则，将最后一个日志继续切分
  • 循环上一步，直到最后一个文件切分出来没有ASCII text为止

操作明细

日志轮询的部署距离现在大概4个月

1.第一次将23G的文件以6G切分成4个文件：xaaxabxacxad，查看4个文件的属性为

xaa:               PCX ver. 2.5 image data
xab:               PCX ver. 2.5 image data
xac:               PCX ver. 2.5 image data
xad:                PCX ver. 2.5 image data

2.重命名xad为x1第二次切分x1 5G，按照1G切分成5份，查看文件属性

xaa:               PCX ver. 2.5 image data
xab:               PCX ver. 2.5 image data
xac:               PCX ver. 2.5 image data
xad:                PCX ver. 2.5 image data
xae:                ASCII text, with very long lines

3.重名xad 为 x2 按照15M的大小切分，查看文件的属性如下

xaa:          PCX ver. 2.5 image data
此处省略。。。
xdo:               PCX ver. 2.5 image data
xdp:               ASCII text, with very long lines
xdq:               ASCII text, with very long lines
xdr:               ASCII text, with very long lines
xds:               ASCII text, with very long lines
xdt:               ASCII text, with very long lines
xdu:               ASCII text, with very long lines
xdv:               UTF-8 Unicode text, with very long lines
xdw:               ASCII text, with very long lines
xdx:               ASCII text, with very long lines
xdy:               ASCII text, with very long lines

4.切分后文件类型为ASCII text的文件中找到15点~16点的文档

[root@sh_01 mongolog_20180801]# head -n 2 xdv
re: "x86_64", version: "Kernel 3.10.0-693.2.2.el7.x86_64" } }
2018-08-01T16:13:44.958+0800 I ACCESS   [conn4972925] Successfully authenticated as principal __system on local
[root@sh_01 mongolog_20180801]# head -n 2 xdu
38422 #4967772 (445 connections now open)
2018-08-01T14:00:10.575+0800 I NETWORK  [thread1] connection accepted from 172.16.0.44:38430 #4967773 (446 connections now open)
  • xdv 的头部是2018-08-01T16:13:44.958+0800,因此可以确定15~16的日志在xdu中
  • xdu记录的日志时间段为2018-08-01T14:00:10.575+0800~2018-08-01T16:13:44.958+0800
  • 重命名xdu为mongolog.18.14_16

分析日志

分析命令

# 获取08月01号下午3点开始到4点执行时间超过5秒的查询
mlogfilter mongolog.18.14_16 --from 2018-08-01T15 --to "+1h" --slow 5000 > slowlog.txt

# 获取08月01号下午3点开始到4点语句的执行次数、用时等统计信息
mloginfo slowlog.txt  --queries > an_slowlog.txt

# 通过mplotqueries进行慢查询散点分布图绘制，且只返回前10个
mplotqueries slowlog.txt --output-file 01.png --logscale --group-limit 10

慢查询散点分布图

[root@sh_01 booboo]# mplotqueries slowlog.txt --output-file 01.png --logscale --group-limit 10
                                                                                          
SCATTER plot
   id   #points  group
    1       692  order.order
    2       615  omdmain.item_region_erp
    3         1  omdmain.customer
()

总结

mongodb日志轮询的问题

  1. echo > log会往文件头部插入\n即16进制的0a
  2. 在数据库正常运行中，对log文件是加了锁的，强制执行echo > log是无法进行覆盖的，会将所有的数据全部置为0
  3. 强制覆盖后，文件头部变成了无数的空白

问题解决

  • MongoDB日志轮询方法调整为kill -SIGUSER1 [mongodpid]
  • 修复目前已经变为图片格式的日志，并拉取15点到16点的日志

更多精彩内容，敬请扫描图中二维码

文章标签：
云数据库 MongoDB 版
日志服务
Shell
NoSQL
监控
数据库
关键词：
云数据库 MongoDB 版日志
mongodb日志服务
日志服务文本
日志服务mongodb
云数据库 MongoDB 版文本
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识，包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用（唯一索引、地理索引、过期索引、全文索引等）、MapReduce操作实现、用户管理、Java对MongoDB的操作支持（基于2.x驱动与3.x驱动的完全讲解）。 通过学习此课程，读者将具备MongoDB数据库的开发能力，并且能够使用MongoDB进行项目开发。 &nbsp; 相关的阿里云产品：云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构，具备安全审计，时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版（ApsaraDB for MongoDB）完全兼容MongoDB协议，基于飞天分布式系统和高可靠存储引擎，提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
驻云科技
目录
相关文章
赵渝强老师
|
3天前
|
存储 NoSQL 安全
【赵渝强老师】MongoDB的Journal日志
MongoDB通过Journal日志保证数据安全，记录检查点后的更新，确保数据库从异常中恢复到有效状态。每个Journal文件100M，存于--dbpath指定的journal子目录。默认已启用Journal日志，可通过--journal参数手动启用。WiredTiger存储引擎使用128KB内存缓冲区，异常关机时可能丢失最多128KB的数据。视频讲解和详细步骤参见附录。
赵渝强老师
34 17
yuanzhengme
|
8月前
|
监控 NoSQL MongoDB
mongoDB查看数据的插入日志
【5月更文挑战第9天】mongoDB查看数据的插入日志
yuanzhengme
469 4
yuanzhengme
|
8月前
|
监控 NoSQL MongoDB
mongoDB查看数据的插入日志
【5月更文挑战第2天】mongoDB查看数据的插入日志
yuanzhengme
383 0
土木林森
|
8月前
|
存储 监控 NoSQL
【MongoDB 专栏】MongoDB 的日志管理与分析
【5月更文挑战第11天】MongoDB日志管理与分析至关重要，包括系统日志和操作日志，用于监控、故障排查和性能优化。合理配置日志详细程度、存储位置和保留策略，使用日志分析工具提升效率，发现性能瓶颈和安全性问题。日志分析有助于优化查询、调整配置，确保数据安全，并可与其他监控系统集成。面对日志量增长的挑战，需采用新技术如分布式存储和数据压缩来保障存储和传输。随着技术发展，不断进化日志管理与分析能力，以支持MongoDB的稳定高效运行。
土木林森
182 2
【MongoDB 专栏】MongoDB 的日志管理与分析
yuanzhengme
|
8月前
|
监控 NoSQL MongoDB
mongoDB查看数据的插入日志
【5月更文挑战第22天】mongoDB查看数据的插入日志
yuanzhengme
62 3
技术蜜糖罐
|
7月前
|
监控 NoSQL MongoDB
MongoDB全文检索: 助力快速精准的文本搜索
MongoDB全文检索: 助力快速精准的文本搜索
技术蜜糖罐
366 0
架构师研究会
|
JSON 缓存 负载均衡
【服务网格架构】Envoy架构概览(9):访问日志,MongoDB,DynamoDB,Redis
【服务网格架构】Envoy架构概览(9):访问日志,MongoDB,DynamoDB,Redis
架构师研究会
128 0
未闻Code
|
NoSQL Shell Linux
一日一技：手动rotate MongoDB的日志
一日一技：手动rotate MongoDB的日志
未闻Code
149 0
蓝染-惣右介
|
2月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法，重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层，允许开发者使用统一的日志接口，而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback，推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback，以及如何使用Lombok简化日志记录。最后，提供了一些日志配置的最佳实践，包括滚动日志、统一日志格式和提高日志性能的方法。
蓝染-惣右介
394 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
运维有小邓
|
19天前
|
监控 安全 Apache
什么是Apache日志？为什么Apache日志分析很重要？
Apache是全球广泛使用的Web服务器软件，支持超过30%的活跃网站。它通过接收和处理HTTP请求，与后端服务器通信，返回响应并记录日志，确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志，对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志，增强Web服务的安全性和可靠性。
运维有小邓
42 9

热门文章

最新文章

  • 1
    一行代码都不改，Golang 应用链路指标日志全知道
  • 2
    阿里云DTS踩坑经验分享系列｜SLS同步至ClickHouse集群
  • 3
    一行代码改进：Logtail的多行日志采集性能提升7倍的奥秘
  • 4
    写了BUG还想跑——闲鱼异常日志问题自动追踪-定位-分发机制
  • 5
    Python脚本：自动化下载视频的日志记录
  • 6
    MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
  • 7
    云上数据安全保护：敏感日志扫描与脱敏实践详解
  • 8
    【赵渝强老师】PostgreSQL的服务器日志文件
  • 9
    3D-Speaker：阿里通义开源的多模态说话人识别项目，支持说话人识别、语种识别、多模态识别、说话人重叠检测和日志记录
  • 10
    要统计Nginx的客户端IP，可以通过分析Nginx的访问日志文件来实现
  • 1
    MongoDB Atlas Vector Search与Amazon Bedrock集成已全面可用
    2645
  • 2
    Fireworks AI和MongoDB：依托您的数据，借助优质模型，助力您开发高速AI应用
    2785
  • 3
    mongoDB查看数据的插入日志
    471
  • 4
    【MongoDB 专栏】MongoDB 在物联网（IoT）领域的应用
    526
  • 5
    【MongoDB 专栏】MongoDB 的分布式事务解决方案
    366
  • 6
    【MongoDB 专栏】MongoDB 的性能基准测试与评估
    312
  • 7
    【MongoDB 专栏】MongoDB 的内存管理与优化
    354
  • 8
    【MongoDB 专栏】MongoDB 的副本集故障转移与恢复
    370
  • 9
    【MongoDB 专栏】MongoDB 的日志管理与分析
    183
  • 10
    【MongoDB 专栏】MongoDB 与 Spring Boot 的集成实践
    260

    • 相关课程

    更多
  • MongoDB精讲课程（下）
  • MongoDB精讲课程（上）
  • MongoDB完全自学手册
  • 云数据库MongoDB版使用教程
  • 快速掌握 MongoDB 数据库
  • MongoDB快速入门

    • 相关电子书

    更多
  • MongoDB多数据中心的方案选型之路
  • 阿里云MongoDB云服务构建
  • 饿了么高级架构师陈东明：MongoDB是如何逐步提高可靠性的

    • 相关实验场景

    更多
  • 云数据库MongoDB快速入门
  • 使用CloudLens管理SLS日志采集
  • 使用CloudLens采集PolarDB日志并进行审计分析
  • 使用CloudLens采集RDS日志并进行审计分析
  • 使用日志服务SLS进行OSS可观测分析
  • 多账号体系下使用日志服务中心化的管理日志

    • 推荐镜像

    更多
  • mongodb
  • postgresql
  • mysql
    • 下一篇
    在华为云 OSC 上快速部署 EMQX MQTT 集群