蚊章汇 - 日志
type: channel
link: https://linuxcn.bwsl.wang/tag/%E6%97%A5%E5%BF%97/
items: systemd 日志维护指南（附实例）
items: 如何在 Linux 中实时监控日志文件（桌面和服务器）
items: Kubernetes 集群日志基础
items: 使用 logrotate 命令轮转和归档日志
items: 如何在 Linux 中实时监控日志文件
items: 如何使 Jenkins 日志更可读
items: 用 Loki 和 fzf 进阶你的 Shell 历史记录
items: 通过集中日志记录来减少安全风险
items: 使用这个 Python 工具分析你的 Web 服务器日志文件
items: 在 Linux 系统中手动滚动日志

systemd 日志维护指南（附实例）
type: item
date: 2023-02-10T15:29:00+08:00
description: systemd 内置了很多管理系统日志的功能。在本指南中，我们将介绍如何管理系统日志，并对其采取轮换、归档和清除日志等操作。我们还解释了手动系统日志清理方法和使用配置文件的变化。如果你的 Linux 发行版支持 systemd，那么从启动时开始，它每秒钟都会从系统的所有进程和应用程序中收集日志。所有这些日志事件都由 systemd 的 journald 守护程序管理。journald 收集所有的日志（信息、警告、错误等），并将其作为二进制数据存储在磁盘文件中。由于日志保留在磁盘中，而且每秒钟都在收集，所以它占用了巨大的磁盘空间；特别是对于旧的系统、服务器来说。例如，在我的一个运行了一年左右的测试系统中，日志文件的大小是 GB 级的。如果你管理多个系统、服务器，建议一定要正确管理 journald 日志，以便高效运行。让我们来看看如何管理日志文件。systemd 日志维护使用 systemd 的 journalctl 工具，你可以查询这些日志，对其进行各种操作。例如，查看不同启动时的日志文件，检查特定进程或应用程序的最后警告和错误。如果你对这些不了解，我建议你在学习本指南之前先快速浏览一下此教程：使用 journalctl 查看和分析 systemd 日志（附实例） 》。物理日记的日志文件在哪里？systemd 的 journald 守护进程在每次启动时都会收集日志。这意味着，它根据启动情况对日志文件进行分类。日志以二进制形式存储在路径 /var/log/journal，文件夹为机器 ID。比如说：另外，请记住，根据系统配置，运行时日志文件被存储在 /run/log/journal/。而这些在每次启动时都会被删除。我可以手动删除日志文件吗？你可以，但不要这样做。相反，请按照下面的说明，使用 journalctl 工具清除日志文件以释放磁盘空间。systemd 的日志文件占用了多少磁盘空间？打开一个终端，运行以下命令。journalctl --disk-usage 这应该为你提供系统中的日志文件实际使用的数量。如果你有一个图形化的桌面环境，你可以打开文件管理器，浏览路径 /var/log/journal，并检查属性。systemd 日志清理过程清理日志文件的有效方法应该是通过 journald.conf 配置文件来完成。正常情况下，即使 journalctl 提供了删除日志文件的工具，你也不应该手动删除这些文件。让我们来看看如何 手动 删除它，然后我将解释 journald.conf 中的配置变化，这样你就不需要时不时地手动删除文件；相反，systemd 会根据你的配置自动处理它。手动删除首先，你必须 flush 和 rotate 日志文件。 轮换 rotate 是将当前活动的日志文件归档，并立即开始创建一个新的日志文件继续记录日志。 冲洗 flush 开关要求日志守护进程将存储在 /run/log/journal/ 中的所有日志数据冲入 /var/log/journal/，如果持久性存储被启用的话。然后，在 flush 和 rotate 之后，你需要用 vacuum-size、vacuum-time 和 vacuum-files 选项运行 journalctl 来强制 systemd 清除日志。例 1：sudo journalctl --flush --rotate sudo journalctl --vacuum-time=1s 上面这组命令会删除所有存档的日志文件，直到最后一秒。这有效地清除了一切。因此，在运行该命令时要小心。清理完毕后：你也可以根据你的需要在 --vacuum-time 的数字后面提供以下后缀：s：秒m：分钟h：小时days：天months：月weeks：周years：年例 2：sudo journalctl --flush --rotate sudo journalctl --vacuum-size=400M 这将清除所有存档的日志文件，并保留最后 400MB 的文件。记住这个开关只适用于存档的日志文件，不适用于活动的日志文件。你也可以使用后缀，如下所示。K：KBM：MBG：GB例 3：sudo journalctl --flush --rotate sudo journalctl --vacuum-files=2 vacuum-files 选项会清除所有低于指定数量的日志文件。因此，在上面的例子中，只有最后两个日志文件被保留，其他的都被删除。同样，这只对存档的文件有效。如果你愿意，你可以把两种选项结合起来，但我建议不要这样做。然而，如果同时使用两个选项，请确保先用 --rotate 选项运行。使用配置文件自动删除虽然上述方法很好，也很容易使用，但建议你使用 journald 配置文件来控制日志文件的清理…

如何在 Linux 中实时监控日志文件（桌面和服务器）
type: item
date: 2022-08-20T03:46:00+08:00
description: 本教程介绍了如何实时监控 Linux 日志文件（桌面、服务器或应用）以进行诊断和故障排除。当你在 Linux 桌面、服务器或任何应用中遇到问题时，你首先会查看单独的日志文件。日志文件通常是文本流和来自应用的带有时间戳的消息。它可以帮助你缩小特定问题的范围，并使你能够找到问题的原因。它还可以帮助从网络获得帮助。一般来说，所有的日志文件都位于 /var/log。此目录包含特定应用和服务的扩展名为 .log 的日志文件，它还包含了其他含有日志的独立目录。所以，如果你想监控一堆日志文件或特定的一个，这里有一些方法可以做到。Linux 实时监控日志文件使用 tail 命令tail 命令是实时跟踪日志文件的最基本方式。特别是如果你在只有终端而没有 GUI 的服务器中。这很有帮助。基本语法如下：tail /path/to/log/file 用法：可以使用开关 -f 跟踪实时更新的日志文件。例如，如果要关注 syslog，可以使用以下命令。tail -f /var/log/syslog 你可以使用单个命令监控多个日志文件：tail -f /var/log/syslog /var/log/dmesg 如果要监视 HTTP 或 sftp 或任何服务器，可以在此命令中使用它们各自的日志文件。请记住，上述命令需要管理员权限。使用 lnav（日志文件浏览器）lnav 是一个出色的程序，你可以用它来用彩色编码的信息以更有条理的方式监控日志文件。在 Linux 系统中，这个工具不是默认安装的。你可以用下面的命令来安装它：Ubuntu：sudo apt install lnav Fedora：sudo dnf install lnav lnav 的好处在于，如果你不想安装它，你可以下载其预编译的可执行文件并在任何地方运行它，甚至可以从 U 盘上运行。无需设置，并加载了功能。使用 lnav，你可以通过 SQL 查询日志文件，以及其他很酷的功能，你可以在其官方网站上学习。安装后，你可以在具有管理员权限的终端上运行 lnav，它会默认显示 /var/log 中的所有日志并开始实时监控。关于 systemd 的 journalctl 的一个说明当今所有现代 Linux 发行版都主要使用 systemd。 systemd 提供了运行 Linux 操作系统的基本框架和组件。 systemd 通过 journalctl 提供日志服务，这有助于管理来自所有 systemd 服务的日志。你还可以使用以下命令实时监控各个 systemd 服务和日志。journalctl -f 以下是一些特定的 journalctl 命令，可用于多种情况。你可以将这些与上面的 -f 选项结合使用以开始实时监控。对于紧急系统消息，请使用：journalctl -p 0 显示带有解释的错误：journalctl -xb -p 3 使用时间控制过滤：journalctl --since "2022-12-04 06:00:00" journalctl --since "2022-12-03" --until "2022-12-05 03:00:00" journalctl --since yesterday journalctl --since 09:00 --until "1 hour ago" 如果你想了解更多关于 journalctl 的详细信息，我已经在这写了份 指南。结束语我希望这些命令和技巧可以帮助你找到桌面或服务器中问题/错误的根本原因。有关更多详细信息，你可以随时参考手册页并使用各种选项。如果你对本文有任何意见或想法，请使用下面的评论栏告诉我。干杯。via: https://www.debugpoint.com/monitor-log-files-real-time/作者：Arindam 选题：lkxed 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

Kubernetes 集群日志基础
type: item
date: 2022-01-02T18:58:21+08:00
description: 探索 Kubernetes 中不同容器日志记录模式的工作原理。服务器和应用程序日志记录是开发人员、运维人员和安全团队了解应用程序在其生产环境中运行状态的重要工具。日志记录使运维人员能够确定应用程序和所需组件是否运行平稳，并检测是否发生了异常情况，以便他们能够对这种情况做出反应。对于开发人员，日志记录提供了在开发期间和之后对代码进行故障排除的可见性。在生产环境中，开发人员通常依赖于没有调试工具的日志记录工具。在加上系统的日志记录，开发人员可以与运维人员携手合作，有效地解决问题。日志记录工具最重要的受益者是安全团队，尤其是在云原生的环境中。能够从应用程序和系统日志中收集信息使得安全团队能够分析来自身份验证、应用程序访问恶意软件活动的数据，并在需要时进行响应。Kubernetes 是领先的容器平台，越来越多的应用程序通过 Kubernetes 部署到生产环境。我相信了解 Kubernetes 的日志架构是一项非常重要的工作，每个开发、运维和安全团队都需要认真对待。在本文中，我将讨论 Kubernetes 中不同容器日志记录模式的工作原理。系统日志记录和应用日志记录在深入研究 Kubernetes 日志记录架构之前，我想探索不同的日志记录方法以及这两种功能如何成为 Kubernetes 日志记录的关键特性。有两种类型的系统组件：在容器中运行的组件和不在容器中运行的组件。例如：Kubernetes 调度者和 kube-proxy 运行在容器中。kubelet 和容器运行时不在容器中运行。与容器日志类似，系统容器日志存储在 /var/log 目录中，你应该定期轮换它们。在这里，我研究的是容器日志记录。首先，我看一下集群级别的日志记录以及为什么它对集群运维人员很重要。集群日志提供有关集群如何执行的信息。诸如为什么 吊舱 Pod 被下线或节点死亡之类的信息。集群日志记录还可以捕获诸如集群和应用程序访问以及应用程序如何利用计算资源等信息。总体而言，集群日志记录工具为集群运维人员提供操作集群和安全有用的信息。捕获容器日志的另一种方法是通过应用程序的本机日志记录工具。现代应用程序设计很可能具有日志记录机制，可帮助开发人员通过标准输出 （stdout） 和错误流 （stderr） 解决应用程序性能问题。为了拥有有效的日志记录工具，Kubernetes 实现需要应用程序和系统日志记录组件。Kubernetes 容器日志的 3 种类型如今，在大多数的 Kubernetes 实现中，你可以看到三种主要的集群级日志记录方法。节点级日志代理用于日志记录的 挎斗 Sidecar 容器应用程序将应用程序日志直接暴露给日志后端节点级日志代理我想考虑节点级日志代理。你通常使用 DaemonSet 作为部署策略来实现这些，以便在所有 Kubernetes 节点中部署一个吊舱（充当日志代理）。然后，该日志代理被配置为从所有 Kubernetes 节点读取日志。你通常将代理配置为读取节点 /var/logs 目录捕获 stdout/stderr 流并将其发送到日志记录后端存储。下图显示了在所有节点中作为代理运行的节点级日志记录。以使用 fluentd 方法为例设置节点级日志记录，你需要执行以下操作：1、首先，你需要创建一个名为 fluentdd 的服务账户。Fluentd 吊舱使用此服务账户来访问 Kubernetes API，你需要在日志命名空间中使用标签 app: fluentd 创建它们：#fluentd-SA.yaml apiVersion: v1 kind: ServiceAccount metadata: name: fluentd namespace: logging labels: app: fluentd 你可以在此 仓库 中查看完整示例。2、接着，你需要创建一个名称为 fluentd-configmap 的 ConfigMap。这为 fluentd daemonset 提供了一个配置文件，其中包含所有必需的属性。#fluentd-daemonset.yaml apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: fluentd namespace: logging labels: app: fluentd kubernetes.io/cluster-service: "true" spec: selector: matchLabels: app: fluentd kubernetes.io/cluster-service: "true" template: metadata: labels: app: fluentd kubernetes.io/cluster-service: "t…

使用 logrotate 命令轮转和归档日志
type: item
date: 2021-10-22T19:38:44+08:00
description: 使用此 Linux 命令保持日志文件更新。日志非常适合找出应用程序在做什么或对可能的问题进行故障排除。几乎我们处理的每个应用程序都会生成日志，我们希望我们自己开发的应用程序也生成日志。日志越详细，我们拥有的信息就越多。但放任不管，日志可能会增长到无法管理的大小，反过来，它们可能会成为它们自己的问题。因此，最好将它们进行裁剪，保留我们需要的那些，并将其余的归档。基本功能logrotate 实用程序在管理日志方面非常出色。它可以轮转日志、压缩日志、通过电子邮件发送日志、删除日志、归档日志，并在你需要时开始记录最新的。运行 logrotate 非常简单——只需要运行 logrotate -vs state-file config-file。在上面的命令中，v 选项开启详细模式，s 指定一个状态文件，最后的 config-file 是配置文件，你可以指定需要做什么。实战演练让我们看看在我们的系统上静默运行的 logrotate 配置，它管理我们在 /var/log 目录中找到的大量日志。查看该目录中的当前文件。你是否看到很多 *.[number].gz 文件？这就是 logrotate 正在做的。你可以在 /etc/logrotate.d/rsyslog 下找到此配置文件。我的配置文件如下：/var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate reload rsyslog > /dev/null 2>&1 || true endscript } /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate reload rsyslog > /dev/null 2>&1 || true endscript } 该文件首先定义了轮转 /var/log/syslog 文件的说明，这些说明包含在后面的花括号中。以下是它们的含义：rotate 7: 保留最近 7 次轮转的日志。然后开始删除超出的。daily: 每天轮转日志，与 rotate 7 一起使用，这意味着日志将保留过去 7 天。其它选项是每周、每月、每年。还有一个大小参数，如果日志文件的大小增加超过指定的限制（例如，大小 10k、大小 10M、大小 10G 等），则将轮转日志文件。如果未指定任何内容，日志将在运行 logrotate 时轮转。你甚至可以在 cron 中运行 logrotate 以便在更具体的时间间隔内使用它。missingok: 如果日志文件缺失也没关系。不要惊慌。notifempty: 日志文件为空时不轮转。compress: 开启压缩，使用 nocompress 关闭它。delaycompress: 如果压缩已打开，则将压缩延迟到下一次轮转。这允许至少存在一个轮转但未压缩的文件。如果你希望昨天的日志保持未压缩以便进行故障排除，那么此配置会很有用。如果某些程序在重新启动/重新加载之前可能仍然写入旧文件，这也很有帮助，例如 Apache。postrotate/endscript: 轮转后运行此部分中的脚本。有助于做清理工作。还有一个 prerotate/endscript 用于在轮转开始之前执行操作。你能弄清楚下一节对上面配置中提到的所有文件做了什么吗？第二节中唯一多出的参数是 sharedscripts，它告诉 logrotate 在所有日志轮转完成之前不要运行 postrotate/endscript 中的部分。它可以防止脚本在每一次轮转时执行，只在最后一次轮转完成时执行。看点新的东西我使用下面的配置来处理我系统上的 Nginx 的访问和错误日志。/var/log/nginx/access.log /var/log/nginx/error.log { size 1 missingok notifempty create 544 www-data adm rotate 30 compress delaycompress dateext dateformat -%Y-%m-%d-%s sharedscripts ex…

如何在 Linux 中实时监控日志文件
type: item
date: 2021-08-30T16:26:18+08:00
description: 本教程解释了如何实时监控 Linux 日志文件（桌面、服务器或应用），以进行诊断和故障排除。当你在你的 Linux 桌面、服务器或任何应用中遇到问题时，你会首先查看各自的日志文件。日志文件通常是来自应用的文本和信息流，上面有一个时间戳。它可以帮助你缩小具体的实例，并帮助你找到任何问题的原因。它也可以帮助从网络上获得援助。一般来说，所有的日志文件都位于 /var/log 中。这个目录包含以 .log 为扩展名的特定应用、服务的日志文件，它还包含单独的其他目录，这些目录包含其日志文件。所以说，如果你想监控一堆日志文件或特定的日志文件。这里有一些你可以做到方法。实时监控 Linux 日志文件使用 tail 命令使用 tail 命令是实时跟踪日志文件的最基本方法。特别是，如果你所在的服务器只有一个终端，没有 GUI。这是很有帮助的。比如：tail /path/to/log/file 使用开关 -f 来跟踪日志文件，它是实时更新的。例如，如果你想跟踪 syslog，你可以使用以下命令：tail -f /var/log/syslog 你可以用一个命令监控多个日志文件，使用：tail -f /var/log/syslog /var/log/dmesg 如果你想监控 http 或 sftp 或任何服务器，你也可以在这个命令中监控它们各自的日志文件。记住，上述命令需要管理员权限。使用 lnav（日志文件浏览器）lnav 是一个很好的工具，你可以用它来通过彩色编码的信息以更有条理的方式监控日志文件。在 Linux 系统中，它不是默认安装的。你可以用下面的命令来安装它：sudo apt install lnav ### Ubuntu sudo dnf install lnav ### Fedora 好的是，如果你不想安装它，你可以直接下载其预编译的可执行文件，然后在任何地方运行。甚至从 U 盘上也可以。它不需要设置，而且有很多功能。使用 lnav，你可以通过 SQL 查询日志文件，以及其他很酷的功能，你可以在它的 官方网站 上了解。一旦安装，你可以简单地用管理员权限从终端运行 lnav，它将默认显示 /var/log 中的所有日志并开始实时监控。关于 systemd 的 journalctl 说明今天所有的现代 Linux 发行版大多使用 systemd。systemd 提供了运行 Linux 操作系统的基本框架和组件。systemd 通过 journalctl 提供日志服务，帮助管理所有 systemd 服务的日志。你还可以通过以下命令实时监控各个 systemd 服务和日志。journalctl -f 下面是一些具体的 journalctl 命令，可以在一些情况下使用。你可以将这些命令与上面的 -f 开关结合起来，开始实时监控。对紧急系统信息，使用：journalctl -p 0 显示带有解释的错误：journalctl -xb -p 3 使用时间控制来过滤输出：journalctl --since "2020-12-04 06:00:00" journalctl --since "2020-12-03" --until "2020-12-05 03:00:00" journalctl --since yesterday journalctl --since 09:00 --until "1 hour ago" 如果你想了解更多关于 journalctl 的细节，我已经写了一个 指南。结束语我希望这些命令和技巧能帮助你找出桌面或服务器问题/错误的根本原因。对于更多的细节，你可以随时参考手册，摆弄各种开关。如果你对这篇文章有什么意见或看法，请在下面的评论栏告诉我。加油。via: https://www.debugpoint.com/2021/08/monitor-log-files-real-time/作者：Arindam 选题：lujun9972 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

如何使 Jenkins 日志更可读
type: item
date: 2021-05-15T17:30:25+08:00
description: Jenkins 的默认日志难以阅读，但日志本不必如此。Jenkins 是一个自由开源的自动化服务器，用于构建、测试和部署代码。它是 持续集成 Continuous Integration （CI）、 持续交付 Continuous Delivery （CD）的基础，可以为开发人员每天节约几小时，并保护他们免受失败的代码上线的影响。一旦代码失效或开发人员需要查看测试输出时，Jenkins 提供了日志文件以供检查。默认的 Jenkins 管道 Pipeline 日志可能难以阅读。这篇关于 Jenkins 日志的基础知识的总结文章提供了一些技巧（和代码），说明了如何提升它们的可读性。你获得什么Jenkins 管道分为 几个阶段。Jenkins 自动记录每个阶段的开始，记录内容如下：[Pipeline] // stage [Pipeline] stage (hide) [Pipeline] { (Apply all openshift resources) [Pipeline] dir 上文显示的内容没有太大区分度，重要的内容（如阶段的开始）未突出显示。在多达数百行的管道日志中，要找到一个阶段的起始和另外一个阶段的终止位置可能会很艰巨。当随意浏览日志寻找一个特定的阶段的时候，这种艰巨尤其明显。Jenkins 管道是由 Groovy 和 Shell 脚本混合编写的。在 Groovy 代码中，日志记录很少。很多时候，日志是由命令中的不起眼的文本组成，没有详细信息。在 Shell 脚本中，打开了调试模式（set -x），所以每条命令都会被完全 具现化 realized （变量被解除引用并打印出数值）并详细记录，输出也是如此。鉴于日志可能有很多内容，通读日志获取相关信息可能很繁琐。由于在管道中被处理，并跟着一个 Shell 脚本的 Groovy 日志可读性差，它们很多时候缺少上下文：[Pipeline] dir Running in /home/jenkins/agent/workspace/devop-master/devops-server-pipeline/my-repo-dir/src [Pipeline] { (hide) [Pipeline] findFiles [Pipeline] findFiles [Pipeline] readYaml [Pipeline] } 我可以知道我正在使用的目录，并且知道我正在使用 Jenkins 的步骤搜索文件、读取 YAML 文件。但是我在寻找什么？我找到并读取的内容是什么？能做什么？我很高兴你这么问，因为这里有一些简单的做法和一些小的代码片段可以提供帮助。首先，代码如下：def echoBanner(def ... msgs) { echo createBanner(msgs) } def errorBanner(def ... msgs) { error(createBanner(msgs)) } def createBanner(def ... msgs) { return """ =========================================== ${msgFlatten(null, msgs).join("\n ")} =========================================== """ } // flatten function hack included in case Jenkins security // is set to preclude calling Groovy flatten() static method // NOTE: works well on all nested collections except a Map def msgFlatten(def list, def msgs) { list = list ?: [] if (!(msgs instanceof String) && !(msgs instanceof GString)) { msgs.each { msg -> list = msgFlatten(list, msg) } } else { list += msgs } return list } 将这段代码添加到每个管道的末尾，也可以 加载一个 Groovy 文件 或者使其成为 Jenkins 共享库 的一部分，这样更有效。在每个阶段起始处（或者在阶段中的特定位置），只需调用 echoBanner：echoBanner("MY STAGE", ["DOING SOMETHING 1", "DOING SOMETHING 2"]) 你的 Jenkins 日志会展示如下： =========…

用 Loki 和 fzf 进阶你的 Shell 历史记录
type: item
date: 2021-01-06T23:50:00+08:00
description: Loki 扩展了 Prometheus 用于度量监测和日志聚合的模型。Loki 是一个 Apache 2.0 许可的开源日志聚合框架，由 Grafana 实验室设计，并在不断发展的社区的巨大支持之下建立。它也是我每天为之努力的项目。在这篇文章中，我将不只是谈论 Loki 如何工作，而是提供一个实际操作的介绍，以解决实际问题。问题：一个持久的集中式 Shell 历史记录我喜欢我的 shell 历史，一直是 CTRL+R 的狂热用户。大约一年前，我的终端生活发生了翻天覆地的变化，我的同行 Dieter Plaetinck 向我介绍了命令行模糊查找器 fzf。突然间，在命令中搜索就从这样：变成了这样：虽然 fzf 极大地提高了我的生活质量，但围绕着我的 shell 历史记录，还是缺少了一些片段：终端突然关闭、电脑崩溃、死机、整盘加密密钥被遗忘等情况下会丢失 shell 历史记录。想从我的所有电脑上访问我的 shell 历史记录。我认为我的 shell 历史记录是文件：它是一个重要的故事，我不想失去。将 Loki 与我的 shell 历史结合起来，有助于解决这些问题和更多问题。关于 LokiLoki 采用了开源 Prometheus 项目用于度量的直观的标签模型，并将其扩展到日志聚合的世界。这使得开发人员和运维人员能够使用相同的标签集在他们的度量和日志之间无缝切换。即使你没有使用 Prometheus，也有很多理由说明 Loki 可能很适合你的日志存储需求：低开销： Loki 不做全文日志索引；它只创建你放在日志上的标签的索引。保持小的索引大大降低了 Loki 的运维要求。我在 树莓派 上运行我的 loki-shell 项目，该项目使用 Loki 来存储 shell 历史记录，只使用了 50MB 多一点的内存。*成本低：**日志内容被压缩并存储在对象存储中，如 Amazon S3、Google 云存储、Azure Blob，甚至可以直接存储在文件系统中。我们的目标是使用价格低廉且持久的存储。灵活性： Loki 以单个二进制文件的形式提供，可以直接下载并运行，也可以作为 Docker 镜像在任何容器环境中运行。在 Kubernetes 中可以用一个 Helm 海图 快速上手。如果你对日志工具的要求很高，可以看看运行在 Grafana 实验室的 生产环境。它使用开源的 Jsonnet 和 Tanka 部署了同样的 Loki 镜像作为离散的构件，以实现大规模的水平扩展、高可用性、复制、读写路径的分别扩展、高度可并行的查询等。总而言之，Loki 的方法是保留一个关于你的日志元数据的小索引（标签），并将未索引的、压缩的日志内容存储在廉价的对象存储中，以使操作更容易和更便宜。该应用程序被构建为单进程运行，并很容易演变成一个高可用的分布式系统。你可以通过并行化和查询的分片，在较大的日志工作负载上获得较高的查询性能 —— 有点像为你的日志设计的 MapReduce。此外，这个功能是任何人都可以免费使用的。与其 Grafana 开放观测性平台一样，Grafana 实验室致力于将 Loki 打造成一个任何人都可以使用的全功能、全开放的日志聚合软件。开始吧我在树莓派上运行 Loki，并将我的 shell 历史记录异地存储在 S3 bucket 中。当我按下 CTRL+R，Loki 的 LogCLI 命令行界面会发起几个批处理请求，传输至 fzf。下面是一个例子，上半部分显示的是树莓派上的 Loki 服务器日志。准备试试？下面的指南将帮助你设置和运行 Loki，与你的 shell 历史记录集成。为了让本教程保持简洁，此设置将 Loki 本地运行在你的计算机上，并在文件系统上存储所有文件。在 loki-shell 的 GitHub 版本库，你可以找到所有这一切，以及如何设置一个更复杂的安装的信息。请注意，本教程不会改变任何围绕你的历史记录的现有行为，所以 你现有的 shell 历史记录命令和历史记录设置不会被触动。相反，这将用 Bash 中的 $PROMPT_COMMAND 和 Zsh 中的 precmd 复制命令历史记录到 Loki。在 CTRL+R 方面，它重载了 fzf 用来访问 CTRL+R 命令的函数。因此试一试是安全的，如果你觉得不喜欢它，只需按照 GitHub 版本库中的 卸载步骤 来删除所有痕迹。你的 shell 历史记录不会被触及。第一步：安装 fzf安装 fzf 有几种方法，但我更喜欢 Git 方法：git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf ~/.fzf/install 对所有的问题提示说 yes。如果你已经安装了 fzf，确保你已经启用了键绑定（即，确保当…

通过集中日志记录来减少安全风险
type: item
date: 2020-09-08T07:10:42+08:00
description: 集中日志并结构化待处理的日志数据可缓解与缺少日志相关的风险日志记录和日志分析对于保护基础设施安全来说至关重要，尤其是当我们考虑到通用漏洞的时候。这篇文章基于我在 FOSDEM'19 上的闪电秀《Let's use centralized log collection to make incident response teams happy》，目的是提高大家对日志匮乏这种安全问题的重视，提供一种避免风险的方法，并且倡议更多的安全实践（利益声明: 我为 NXLog 工作）。为什么要收集日志？为什么要集中日志记录？确切的说，日志是写入磁盘的仅追加的记录序列。在实际生活中，日志可以在你尝试寻找异常的根源时帮助你调查基础设施的问题。当你有多个使用自己的标准与格式的日志的异构系统，并且想用一种可靠的方法来接收和处理它们的时候，挑战就来临了。这通常以元数据为代价的。集中日志记录解决方案需要共性，这种共性常常会去除许多开源日志记录工具所提供的丰富的元数据。日志记录与监控匮乏的安全风险 开源 Web 应用程序安全项目 Open Web Application Security Project （OWASP）是一个为业界贡献了许多杰出项目（包括许多专注于软件安全的工具）的非营利组织。OWASP 定期为应用开发人员和维护者报告最危险的安全挑战。在最新一版《10 项最严重的 Web 应用程序安全风险》中，OWASP 将日志记录和监控匮乏加入了列表中。OWASP 警告下列情况会导致日志记录、检测、监控和主动响应的匮乏：未记录重要的可审计性事件，如：登录、登录失败和高额交易。告警和错误事件未能产生、产生不足或不清晰的日志信息。日志信息仅在本地存储。对于实时或准实时的主动攻击，应用程序无法检测、处理和告警。可以通过集中日志记录（例如，不仅将日志本地存储）和结构化日志数据以进一步分析来缓解上述情形（例如，在告警仪表盘和安全套件中）。举例来说, 假设一个 DNS 查询会导向名为 hacked.badsite.net 的恶意网站。通过 DNS 监控，管理员监控并且主动的分析 DNS 请求与响应。DNS 监控的效果依赖于充足的日志记录与收集来发现潜在问题，同样也依赖于结构化 DNS 日志的结果来进一步分析。2019-01-29 Time (GMT) Source Destination Protocol-Info 12:42:42.112898 SOURCE_IP xxx.xx.xx.x DNS Standard query 0x1de7 A hacked.badsite.net 你可以在 NXLog 社区版 中自己尝试一下这个例子，也可以尝试其他例子和代码片段。 （再次声明：我为 NXLog 工作）重要的一点：非结构化数据与结构化数据花费一点时间来考虑下日志数据格式是很重要的。例如，让我们来考虑以下日志消息：debug1: Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2 这段日志包含了一个预定义的结构，例如冒号前面的元数据关键词（debug1）然而，余下的日志字段是一个未结构化的字符串（Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2）。因此，即便这个消息是人类可轻松阅读的格式，但它不是一个计算机容易解析的格式。非结构化的事件数据存在局限性，包括难以解析、搜索和分析日志。重要的元数据通常以一种自由字符串的形式作为非结构化数据字段，就像上面的例子一样。日志管理员会在他们尝试标准化/归一化日志数据与集中日志源的过程中遇到这个问题。接下来怎么做除了集中和结构化日志之外，确保你收集了正确的日志数据——Sysmon、PowerShell、Windows 事件日志、DNS 调试日志、ETW、内核监控、文件完整性监控、数据库日志、外部云日志等等。同样也要选用适当的工具和流程来来收集、汇总和帮助理解数据。希望这对你从不同日志源中集中日志收集提供了一个起点：将日志发送到仪表盘、监控软件、分析软件以及像安全性资讯与事件管理（SIEM）套件等外部源。你的集中日志策略会是怎么样？请在评论中分享你的想法。via: https://opensource.com/article/19/2/reducing-security-risks-centralized-logging作者：Hannah Suarez 选题：lujun9972 译者：leommxj 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

使用这个 Python 工具分析你的 Web 服务器日志文件
type: item
date: 2020-08-14T00:01:59+08:00
description: 这个 Python 模块可以以多种格式收集网站使用日志并输出良好结构化数据以进行分析。是否想知道有多少访问者访问过你的网站？或哪个页面、文章或下载最受欢迎？如果你是自托管的博客或网站，那么无论你使用的是 Apache、Nginx 还是 Microsoft IIS（是的，没错），lars都可以为你提供帮助。Lars 是 Python 写的 Web 服务器日志工具包。这意味着你可以使用 Python 通过简单的代码来回溯（或实时）解析日志，并对数据做任何你想做的事：将它存储在数据库中、另存为 CSV 文件，或者立即使用 Python 进行更多分析。Lars 是 Dave Jones 写的另一个隐藏的宝石。我最初是在本地 Python 用户组中看到 Dave 演示 lars。几年后，我们开始在 piwheels 项目中使用它来读取 Apache 日志并将行插入到我们的 Postgres 数据库中。当树莓派用户从 piwheels.org下载 Python 包时，我们会记录文件名、时间戳、系统架构（Arm 版本）、发行版名称/版本，Python 版本等。由于它是一个关系数据库，因此我们可以将这些结果加入其他表中以获得有关文件的更多上下文信息。你可以使用以下方法安装lars：$ pip install lars 在某些系统上，正确的方式是 sudo pip3 install lars。首先，找到一个 Web 访问日志并制作一个副本。你需要将日志文件下载到计算机上进行操作。我在示例中使用的是 Apache 日志，但是经过一些小（且直观）的更改，你可以使用 Nginx 或 IIS。在典型的 Web 服务器上，你会在 /var/log/apache2/ 中找到 Apache 日志，通常是 access.log、ssl_access.log（对于 HTTPS）或 gzip 压缩后的轮转日志文件，如 access-20200101.gz 或者 ssl_access-20200101.gz 。首先，日志是什么样的？81.174.152.222 - - [30/Jun/2020:23:38:03 +0000] "GET / HTTP/1.1" 200 6763 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" 这是一个显示了请求源 IP 地址、时间戳、请求文件路径（在本例中是主页 /）、HTTP 状态代码，用户代理（Ubuntu 上的 Firefox）等的请求。你的日志文件将充满这样的条目，不仅是每个打开的页面，还包括返回的每个文件和资源：每个 CSS 样式表、JavaScript 文件和图像，每个 404 请求、每个重定向、每个爬虫。要从日志中获取有意义的数据，你需要对条目进行解析、过滤和排序。这就是 Lars 的用处。本示例将打开一个日志文件并打印每一行的内容：with open('ssl_access.log') as f: with ApacheSource(f) as source: for row in source: print(row) 它会为每条日志显示如下结果：Row(remote_host=IPv4Address('81.174.152.222'), ident=None, remote_user=None, time=DateTime(2020, 6, 30, 23, 38, 3), request=Request(method='GET', url=Url(scheme='', netloc='', path_str='/', params='', query_str='', fragment=''), protocol='HTTP/1.1'), status=200, size=6763) 它解析了日志条目，并将数据放入结构化格式中。该条目已成为具有与条目数据相关属性的 命名元组 namedtuple ，因此，例如，你可以使用 row.status 访问状态代码，并使用 row.request.url.path_str 访问路径：with open('ssl_access.log') as f: with ApacheSource(f) as source: for row in source: print(f'hit {row.request.url.path_str} with status code {row.status}') 如果你只想显示 404 请求，可以执行以下操作：with open('ssl_access.log') as f: with ApacheSource(f) as source…

在 Linux 系统中手动滚动日志
type: item
date: 2020-03-26T06:40:13+08:00
description: 日志滚动 log rotation 在 Linux 系统上是再常见不过的一个功能了，它为系统监控和故障排查保留必要的日志内容，同时又防止过多的日志造成单个日志文件太大。日志滚动的过程是这样的：在一组日志文件之中，编号最大的（最旧的）一个日志文件会被删除，其余的日志文件编号则依次增大并取代较旧的日志文件，而较新的文件则取代它作为当前的日志文件。这一个过程很容易就可以实现自动化，在细节上还能按需作出微调。使用 logrotate 命令可以手动执行日志滚动的操作。本文将要介绍的就是手动进行日志滚动的方法，以及预期产生的结果。文中出现的示例适用于 Ubuntu 等 Linux 系统，对于其它类型的系统，日志文件和配置文件可能会有所不同，但日志滚动的过程是大同小异的。为什么需要滚动日志一般情况下，无需手动旋转日志文件。Linux 系统会每隔一天（或间隔更长的时间）或根据日志文件的大小自动进行一次日志滚动。如果你需要滚动日志以释放存储空间，又或者将某一部分日志从当前的活动中分割出来，这很容易做到，具体要取决于文件滚动规则。一点背景介绍在 Linux 系统安装完成后就已经有很多日志文件被纳入到日志滚动的范围内了。另外，一些应用程序在安装时也会为自己产生的日志文件设置滚动规则。一般来说，日志滚动的配置文件会放置在 /etc/logrotate.d。如果你想了解日志滚动的详细实现，可以参考这篇以前的文章。在日志滚动的过程中，活动日志会以一个新名称命名，例如 log.1，之前被命名为 log.1 的文件则会被重命名为 log.2，依此类推。在这一组文件中，最旧的日志文件（假如名为 log.7）会从系统中删除。日志滚动时文件的命名方式、保留日志文件的数量等参数是由 /etc/logrotate.d 目录中的配置文件决定的，因此你可能会看到有些日志文件只保留少数几次滚动，而有些日志文件的滚动次数会到 7 次或更多。例如 syslog 在经过日志滚动之后可能会如下所示（注意，行尾的注释部分只是说明滚动过程是如何对文件名产生影响的）：$ ls -l /var/log/syslog* -rw-r----- 1 syslog adm 128674 Mar 10 08:00 /var/log/syslog <== 新文件 -rw-r----- 1 syslog adm 2405968 Mar 9 16:09 /var/log/syslog.1 <== 之前的 syslog -rw-r----- 1 syslog adm 206451 Mar 9 00:00 /var/log/syslog.2.gz <== 之前的 syslog.1 -rw-r----- 1 syslog adm 216852 Mar 8 00:00 /var/log/syslog.3.gz <== 之前的 syslog.2.gz -rw-r----- 1 syslog adm 212889 Mar 7 00:00 /var/log/syslog.4.gz <== 之前的 syslog.3.gz -rw-r----- 1 syslog adm 219106 Mar 6 00:00 /var/log/syslog.5.gz <== 之前的 syslog.4.gz -rw-r----- 1 syslog adm 218596 Mar 5 00:00 /var/log/syslog.6.gz <== 之前的 syslog.5.gz -rw-r----- 1 syslog adm 211074 Mar 4 00:00 /var/log/syslog.7.gz <== 之前的 syslog.6.gz你可能会发现，除了当前活动的日志和最新一次滚动的日志文件之外，其余的文件都已经被压缩以节省存储空间。这样设计的原因是大部分系统管理员都只需要查阅最新的日志文件，其余的日志文件压缩起来，需要的时候可以解压查阅，这是一个很好的折中方案。手动日志滚动你可以这样执行 logrotate 命令进行手动日志滚动：$ sudo logrotate -f /etc/logrotate.d/rsyslog值得一提的是，logrotate 命令使用 /etc/logrotate.d/rsyslog 这个配置文件，并通过了 -f 参数实行“强制滚动”。因此，整个过程将会是：删除 syslog.7.gz，将原来的 syslog.6.gz 命名为 syslog.7.gz，将原来的 syslog.5.gz 命名为 syslog.6.gz，将原来的 syslog.4.gz 命名为 syslog.5.gz，将原来的 syslog.3.gz 命名为 syslog.4.gz，将原来的 syslog.2.gz 命名为 syslog.3.gz，将原来…