这是一个创建于 1768 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天 journalctl 把生产环境搞爆了.
因为用它查看日志的时候, 直接输入了 -G, 从日志头部直接浏览到尾部.
导致 journal 需要从头到尾解析十几个 G 的二进制日志数据, 然后内存 CPU 都爆了, 服务器直接挂掉.
现在觉得 journal 好危险, 虽然今天的故障可以通过加入参数, 减少查询范围解决, 但是搞不好以后还会复现今天的问题.
虽然在使用 journal 的过程遇到各种问题, 一直都觉得是我们没学习到位, 需要深入研究, 一直坚持了下来, 但今天这个故障让我没有信心坚持用这个了.
第 1 条附言 2020-12-10 16:10:20 +08:00
@pigmen 嗯, 一直觉得我们使用上有点问题, 也在 Stack Overflow 之类的论坛发过帖子求助, 网上 journal 相关的帖子也都看了. 至今没有琢磨出一套最佳实践. 还是 2 个人一起研究的, 花了很多时间精力, 惭愧.
因为日志量比较大, 经常还需要分析几天的日志. 所以目前生产环境的配置是:
SystemMaxUse=20G
SystemKeepFree=10G
通过磁盘相关参数限制日志数量
每次查询日志用的命令是:
journalctl CONTAINER_NAME=docker_name
问题是:
这个命令, 每次都是从头解析全部日志, 虽然使用 --since "1 hour ago" 这种方式可以减少日志解析的量, 但是如果忘记加就会复现今天的故障.
因为日志量比较大, 经常还需要分析几天的日志. 所以目前生产环境的配置是:
SystemMaxUse=20G
SystemKeepFree=10G
通过磁盘相关参数限制日志数量
每次查询日志用的命令是:
journalctl CONTAINER_NAME=docker_name
问题是:
这个命令, 每次都是从头解析全部日志, 虽然使用 --since "1 hour ago" 这种方式可以减少日志解析的量, 但是如果忘记加就会复现今天的故障.
第 2 条附言 2020-12-10 16:14:38 +08:00
第 3 条附言 2020-12-10 16:16:31 +08:00
@masker 如果用之前的方式, 日志直接落地到本地磁盘, 我会采用切分多个文件的方式, 基本可以避免今天的故障. 可是用 journal, 因为不清楚怎么样做默认的切割, 所以不知道该怎么避免以后一个新人来了, 不会重复今天的操作, 再次导致故障
第 4 条附言 2020-12-10 16:24:32 +08:00
我想如果继续在生产环境用 journal, 有个前提, 就是通过某种设置, 能彻底避免今天的故障.
或者说以后有新同事来了, 不会在不知情的情况下, 再次触发今天的故障.
如果不用 journal, 日志直接落地磁盘, 我把单个日志文件的大小限制下就 ok 了.
journal 要怎么做, 有什么设置, 可以彻底避免这次的故障呢
或者说以后有新同事来了, 不会在不知情的情况下, 再次触发今天的故障.
如果不用 journal, 日志直接落地磁盘, 我把单个日志文件的大小限制下就 ok 了.
journal 要怎么做, 有什么设置, 可以彻底避免这次的故障呢
 | 1 NilChan 2020-12-10 12:05:09 +08:00  1 学习了。。。 |
 | 2 pigmen 2020-12-10 12:08:55 +08:00 via iPhone 这是用错了导致的 不能说 journal 好危险 照你这么说 rm -rf 岂不是更危险？ |
 | 3 m4d3bug 2020-12-10 12:12:27 +08:00 via Android 指定服务名是好习惯 |
 | 4 AstroProfundis 2020-12-10 12:16:14 +08:00 那 grep 甚至 vim 一个十多 G 的 /var/log/xxx.log 不也一样？ |
 | 5 tin3w5 2020-12-10 12:24:00 +08:00 想起了大学的时候拿到了一台流量很高的 web 服务器权限，用 vim 删日志的时候直接把服务器卡死的境。 |
 | 6 shyling 2020-12-10 13:05:02 +08:00 。。。人的问题，你 vim 一个大文本也会挂，难道说没有信心用 vim 了？ |
 | 7 lvzhiqiang 2020-12-10 13:07:50 +08:00 查看线上日志一定要先看看 应用的负载情况，任何文本方式的“全部”查询都会占用服务器资源，这个和你用什么工具是没有关系的。推荐使用部分查看或者导出到空闲服务器查看。 |
 | 8 kokodayo 2020-12-10 13:08:34 +08:00 -n 限定行数，比如-n100 就只会抓取最后 100 行 |
 | 9 masker 2020-12-10 13:11:33 +08:00 via Android man 一下都不会？又怪工具？ |
 | 10 itechify PRO 习惯每次看日志都 du -h 看下多大 |
 | 11 jhdxr 2020-12-10 13:27:23 +08:00 这么看来突然觉得 emeditor 很良心，大文件自动进行部分加载。。。 |
 | 12 nikolai 2020-12-10 13:36:14 +08:00 每月都定时 vacuum 一次，没这烦恼（手动 doge |
 | 13 shingle 2020-12-10 13:54:42 +08:00 可以配置 log 文件最大的大小啊，超过会自动切分。查看的时候只看实时记录的那个文件就好了 |
 | 14 DinoStray OP @shingle 日志直接落到本地磁盘, 我都是这样做的, 限制单个文件的大小. 用了 journal 就不知道该怎么搞了 |
 | 15 echowuhao 2020-12-10 16:21:05 +08:00 之前，vps 空间都不足，我也没干啥，仔细一看，这个 log 几十 G 。 systemd 这个默认的设置绝对是有问题的。 不是自己学习不好怪工具，而是你工具的有个默认最合适的配置。 用 linux 这么多年，这个配置让我觉得扯淡的。 |
 | 16 Cooky 2020-12-10 16:21:13 +08:00 via Android systemd 一整套缺文档小毛病也不修，不想踩坑就换个日志 deamon 吧 |
 | 17 reasonsyh 2020-12-10 19:55:20 +08:00 alias 设置一下 |
 | 18 chenqh 2020-12-10 20:07:07 +08:00 感觉还是老老实实 supervisord 吧 |
 | 19 chenxytw 2020-12-10 20:20:28 +08:00 生产环境上根本不会保存超过一定数量的日志..... 古老日志全部异步写到专门的日志集群里了... |
Select Language