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 配置文件来控制日志文件的清理过程，该文件存在于 /etc/systemd/journald.conf。systemd 为你提供了许多参数来有效管理日志文件。通过组合这些参数，你可以有效地限制日志文件所占用的磁盘空间。让我们来看看。journald.conf 参数描述实例SystemMaxUse指定日志在持久性存储中可使用的最大磁盘空间SystemMaxUse=500MSystemKeepFree指定在将日志条目添加到持久性存储时，日志应留出的空间量。SystemKeepFree=100MSystemMaxFileSize控制单个日志文件在被轮换之前在持久性存储中可以增长到多大。SystemMaxFileSize=100MRuntimeMaxUse指定在易失性存储中可以使用的最大磁盘空间（在 /run 文件系统内）。RuntimeMaxUse=100MRuntimeKeepFree指定将数据写入易失性存储（在 /run 文件系统内）时为其他用途预留的空间数量。RuntimeMaxUse=100MRuntimeMaxFileSize指定单个日志文件在被轮换之前在易失性存储（在 /run 文件系统内）所能占用的空间量。RuntimeMaxFileSize=200M如果你在运行中的系统的 /etc/systemd/journald.conf 文件中添加这些值，那么在更新文件后，你必须重新启动 journald。要重新启动，请使用以下命令。sudo systemctl restart systemd-journald 核实日志文件在你清理完文件后，检查日志文件的完整性是比较明智的。要做到这一点，请运行下面的命令。该命令显示了日志文件是否通过（PASS）、失败（FAIL）。journalctl --verify 总结希望本指南能帮助你了解 systemd 日志管理流程的基本情况。通过这些，你可以通过限制空间、清除旧的日志文件来管理系统或服务器中的日志文件所使用的磁盘空间。这些只是指导性的命令，你可以通过多种方式组合这些命令来实现你的系统需求。journalctl 手册journald.conf 手册via: https://www.debugpoint.com/systemd-journald-clean/作者：Arindam 选题：lkxed 译者：Chao-zhi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
如何在 Linux 中实时监控日志文件（桌面和服务器）
本教程介绍了如何实时监控 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 中不同容器日志记录模式的工作原理。服务器和应用程序日志记录是开发人员、运维人员和安全团队了解应用程序在其生产环境中运行状态的重要工具。日志记录使运维人员能够确定应用程序和所需组件是否运行平稳，并检测是否发生了异常情况，以便他们能够对这种情况做出反应。对于开发人员，日志记录提供了在开发期间和之后对代码进行故障排除的可见性。在生产环境中，开发人员通常依赖于没有调试工具的日志记录工具。在加上系统的日志记录，开发人员可以与运维人员携手合作，有效地解决问题。日志记录工具最重要的受益者是安全团队，尤其是在云原生的环境中。能够从应用程序和系统日志中收集信息使得安全团队能够分析来自身份验证、应用程序访问恶意软件活动的数据，并在需要时进行响应。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: "true" spec: serviceAccount: fluentd containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch.logging.svc.cluster.local" - name: FLUENT_ELASTICSEARCH_PORT value: "9200" - name: FLUENT_ELASTICSEARCH_SCHEME value: "http" - name: FLUENT_ELASTICSEARCH_USER value: "elastic" - name: FLUENT_ELASTICSEARCH_PASSWORD valueFrom: secretKeyRef: name: efk-pw-elastic key: password - name: FLUENT_ELASTICSEARCH_SED_DISABLE value: "true" resources: limits: memory: 512Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true - name: fluentconfig mountPath: /fluentd/etc/fluent.conf subPath: fluent.conf terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers - name: fluentconfig configMap: name: fluentdconf 你可以在此 仓库 中查看完整示例。现在，我们来看看如何将 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: "true" spec: serviceAccount: fluentd containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch.logging.svc.cluster.local" - name: FLUENT_ELASTICSEARCH_PORT value: "9200" - name: FLUENT_ELASTICSEARCH_SCHEME value: "http" - name: FLUENT_ELASTICSEARCH_USER value: "elastic" - name: FLUENT_ELASTICSEARCH_PASSWORD valueFrom: secretKeyRef: name: efk-pw-elastic key: password - name: FLUENT_ELASTICSEARCH_SED_DISABLE value: "true" resources: limits: memory: 512Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true - name: fluentconfig mountPath: /fluentd/etc/fluent.conf subPath: fluent.conf terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers - name: fluentconfig configMap: name: fluentdconf 将这些放在一起执行：kubectl apply -f fluentd-SA.yaml \ -f fluentd-configmap.yaml \ -f fluentd-daemonset.yaml 用于日志记录的挎斗容器应用程序另一种方法是使用带有日志代理的专用挎斗容器。容器最常见的实现是使用 Fluentd 作为日志收集器。在企业部署中（你无需担心一点计算资源开销），使用 fluentd（或类似）实现的挎斗容器提供了集群级日志记录的灵活性。这是因为你可以根据需要捕获的日志类型、频率和其它可能的调整来调整和配置收集器代理。下图展示了作为日志代理的挎斗容器。例如，一个吊舱运行单个容器，容器使用两种不同的格式写入两个不同的日志文件。吊舱的配置文件如下：#log-sidecar.yaml apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} 把它们放在一起，你可以运行这个吊舱：$ kubectl apply -f log-sidecar.yaml 要验证挎斗容器是否用作日志代理，你可以执行以下操作：$ kubectl logs counter count-log 预期的输出如下所示：$ kubectl logs counter count-log-1 Thu 04 Nov 2021 09:23:21 NZDT Thu 04 Nov 2021 09:23:22 NZDT Thu 04 Nov 2021 09:23:23 NZDT Thu 04 Nov 2021 09:23:24 NZDT 将应用程序日志直接暴露给日志后端第三种方法（在我看来）是 Kubernetes 容器和应用程序日志最灵活的日志记录解决方案，是将日志直接推送到日志记录后端解决方案。尽管此模式不依赖于原生 Kubernetes 功能，但它提供了大多数企业需要的灵活性，例如：扩展对网络协议和输出格式的更广泛支持。提供负载均衡能力并提高性能。可配置为通过上游聚合接受复杂的日志记录要求。因为这第三种方法通过直接从每个应用程序推送日志来依赖非 Kubernetes 功能，所以它超出了 Kubernetes 的范围。结论Kubernetes 日志记录工具是企业部署 Kubernetes 集群的一个非常重要的组件。我讨论了三种可能的可用模式。你需要找到适合你需求的模式。如上所述，使用 daemonset 的节点级日志记录是最容易使用的部署模式，但它也有一些限制，可能不适合你的组织的需要。另一方面，挎斗 模式提供了灵活性和自定义，允许你自定义要捕获的日志类型，但是会提高计算机的资源开销。最后，将应用程序日志直接暴露给后端日志工具是另一种允许进一步定制的诱人方法。选择在你，你只需要找到适合你组织要求的方法。via: https://opensource.com/article/21/11/cluster-logging-kubernetes作者：Mike Calizo 选题：lujun9972 译者：perfiffer 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
使用此 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 extension .log postrotate service nginx reload endscript } 上面的脚本可以使用如下命令运行：logrotate -vs state-file /tmp/logrotate 第一次运行该命令会给出以下输出：reading config file /tmp/logrotate extension is now .log Handling 1 logs rotating pattern: /var/log/nginx/access.log /var/log/nginx/error.log 1 bytes (30 rotations) empty log files are not rotated, old logs are removed considering log /var/log/nginx/access.log log needs rotating considering log /var/log/nginx/error.log log does not need rotating rotating log /var/log/nginx/access.log, log->rotateCount is 30 Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s' dateext suffix '-2021-08-27-1485508250' glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' glob finding logs to compress failed glob finding old rotated logs failed renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508250.log creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4 running postrotate script * Reloading nginx configuration nginx 第二次运行它：reading config file /tmp/logrotate extension is now .log Handling 1 logs rotating pattern: /var/log/nginx/access.log /var/log/nginx/error.log 1 bytes (30 rotations) empty log files are not rotated, old logs are removed considering log /var/log/nginx/access.log log needs rotating considering log /var/log/nginx/error.log log does not need rotating rotating log /var/log/nginx/access.log, log->rotateCount is 30 Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s' dateext suffix '-2021-08-27-1485508280' glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' compressing log with: /bin/gzip renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508280.log creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4 running postrotate script * Reloading nginx configuration nginx 第三次运行它：reading config file /tmp/logrotate extension is now .log Handling 1 logs rotating pattern: /var/log/nginx/access.log /var/log/nginx/error.log 1 bytes (30 rotations) empty log files are not rotated, old logs are removed considering log /var/log/nginx/access.log log needs rotating considering log /var/log/nginx/error.log log does not need rotating rotating log /var/log/nginx/access.log, log->rotateCount is 30 Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s' dateext suffix '-2021-08-27-1485508316' glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' compressing log with: /bin/gzip renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508316.log creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4 running postrotate script * Reloading nginx configuration nginx 状态文件的内容如下所示：logrotate state -- version 2 "/var/log/nginx/error.log" 2021-08-27-9:0:0 "/var/log/nginx/access.log" 2021-08-27-9:11:56 下载 Linux logrotate 备忘单本文首发于作者个人博客，经授权改编。via: https://opensource.com/article/21/10/linux-logrotate作者：Ayush Sharma 选题：lujun9972 译者：perfiffer 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
本教程解释了如何实时监控 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 的默认日志难以阅读，但日志本不必如此。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 日志会展示如下： =========================================== MY STAGE DOING SOMETHING 1 DOING SOMETHING 2 =========================================== 这个横幅很容易从日志中分辨出来。当正确使用它们时，它们还有助于界定管道流，并且可以很好的将日志分解开来进行阅读。我已经在某些地方专业地使用这些代码一些时间了。在帮助管道日志更易读和流程更易理解方面，反馈是非常积极的。上述的 errorBanner 方法以相同的方式工作，但是它会立即使脚本失效。这有助于突显失败的位置与原因。最佳实践在你的 Groovy 代码中大量使用 echo Jenkins 步骤来通知用户你在做什么。这些也可以帮助记录你的代码。使用空的日志语句（Groovy 中空的 echo 步骤、echo '' 或 Shell 中的 echo）来分割输出，提高可读性。你可能在你的代码中为同样的目的使用空行。避免在脚本中使用 set +x 的陷阱，因为它隐藏了日志记录已执行的 Shell 语句。它并没有清理你的日志，而是使你的管道成为一个黑盒子，隐藏了管道正在做的行为以及出现的任何错误。确保管道功能尽可能透明。如果你的管道创建了 中间工件 Intermediate Artifacts ，开发人员和 DevOps 人员可以使用这些工件来帮助调试问题，那么也要记录它的内容。是的，它会加长日志，但这只是文本。在某些时候，这会是有用的信息，而（利用得当的）日志不就是关于发生了什么和为什么发生的大量信息吗？Kubernetes 机密信息：无法完全透明的地方有些事情你不希望出现在日志里暴露出来。如果你在使用 Kubernetes 并引用保存在 Kubernetes 机密信息 Secrets 中的数据，那么你绝对不希望在日志中公开该数据，因为这些数据只是被混淆了，而没有被加密。假如你想获取一些保存在机密信息中的数据，然后将其注入模板化 JSON 文件中。（机密信息和 JSON 模板的完整内容与此例无关。）按照最佳实践，你希望保持透明并记录你的操作，但你不想公开机密信息数据。将脚本模式从调试（set -x）更改为命令记录（set -v）。在脚本敏感部分的结尾，将 Shell 重置为调试模式：sh """ # change script mode from debugging to command logging set +x -v # capture data from secret in shell variable MY_SECRET=\$(kubectl get secret my-secret --no-headers -o 'custom-column=:.data.my-secret-data') # replace template placeholder inline sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json # do something with modified template-file.json... # reset the shell to debugging mode set -x +v """ 这将输出此行到日志：sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json 与 Shell 调试模式中不同，这不会具现化 Shell 变量 MY_SECRET_DATA。显然，如果管道中在这一点出现问题，而你试图找出问题出在哪里，那么这不如调试模式有用。但这是在保持管道执行对开发人员和 DevOps 透明的同时，也保持你的秘密的最佳平衡。via: https://opensource.com/article/21/5/jenkins-logs作者：Evan "Hippy" Slatis 选题：lujun9972 译者：DCOLIVERSUN 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
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，确保你已经启用了键绑定（即，确保当你输入 CTRL+R 时，fzf 会弹出）。如果有必要的话，你可以重新运行 fzf 安装过程来启用键绑定。第二步：安装 loki-shell和 fzf 一样，loki-shell 也有一个 Git 版本库和安装脚本：git clone --depth 1 https://github.com/slim-bean/loki-shell.git ~/.loki-shell ~/.loki-shell/install 首先，该脚本创建了 ~/.loki-shell 目录，所有的文件都将保存在该目录下（包括 Loki 数据），接下来，它将下载 Promtail、LogCLI 和 Loki 的二进制文件。然后它会问：Do you want to install Loki? ([y]/n) 如果你已经为 Loki-shell 运行了一个集中化的 Loki，你可以回答 n；然而，对于本教程，回答 y 或按回车键。在本地运行 Loki 有两种方式：作为一个 Docker 镜像或作为一个单一的二进制文件（支持添加为 systemd 服务）。如果可以，我建议使用 Docker，因为我认为它稍微简化了操作，但这两者都可以工作。使用 Docker 运行将 Loki 作为 Docker 镜像运行：[y] to run Loki in Docker, [n] to run Loki as a binary ([y]/n) y Error: No such object: loki-shell Error response from daemon: No such container: loki-shell Error: No such container: loki-shell 54843ff3392f198f5cac51a6a5071036f67842bbc23452de8c3efa392c0c2e1e 如果这是你第一次运行这个安装程序，你可以忽略错误信息。这个脚本将停止和替换运行的 Loki 容器，如果版本不匹配，你可以重新运行此脚本升级 Loki。就是这样！Loki 现在作为一个 Docker 容器运行了。Loki 的数据将存储在 ~/.loki-shell/data 中。由于带着 -restart=unless-stopped 标志运行该镜像，所以它会在系统重启时重启该服务，但如果你运行 docker stop loki-shell 则会保持停止。（如果你使用的是 Docker，你可以跳到 “Shell 集成”一节。）以二进制文件运行在 Linux 系统上运行二进制文件的方法有很多。这个脚本可以安装一个 systemd 服务。如果你没有 systemd，你也可以使用二进制安装：[y] to run Loki in Docker, [n] to run Loki as a binary ([y]/n) n Run Loki with systemd? ([y]/n) n This is as far as this script can take you You will need to setup an auto-start for Loki It can be run with this command: /home/username/.loki-shell/bin/loki -config.file=/home/username/.loki-shell/config/loki-binary-config.yaml 脚本会输出你需要用来运行 Loki 的命令，你可以自己设置一个 init 脚本或其他方法来自动启动它。如果你想的话，你可以直接运行该命令，从你当前的 shell 运行 Loki。如果你有 systemd，你可以选择让脚本安装 systemd 服务或显示出你自己运行它的命令：Run Loki with systemd? ([y]/n) y Installing the systemd service requires root permissions. [y] to run these commands with sudo [n] to print out the commands and you can run them yourself. ([y]/n) n sudo cp /home/ed/.loki-shell/config/loki-shell.service /etc/systemd/system/loki-shell.service sudo systemctl daemon-reload sudo systemctl enable loki-shell sudo systemctl start loki-shell Copy these commands and run them when the script finishes. (press enter to continue) Shell 集成无论你如何安装 Loki，你现在应该看到一个提示：Enter the URL for your Loki server or press enter for default (http://localhost:4100) 如果你已经设置了一个中心化的 Loki，你应在这里输入其 URL。然而，这个演示只是使用了默认的 URL，所以你可以按回车键。它会输出很多文本来解释添加到你的 ~.bashrc 或 ~.zshrc（或两者）的所有条目。好了！Finished. Restart your shell or reload config file. source ~/.bashrc # bash source ~/.zshrc # zsh 第三步：试试吧!开始使用你的 shell，并使用 CTRL+R 查看你的命令。打开多个终端窗口，在一个窗口中输入命令，在另一个窗口中输入 CTRL+R，你会看到你的命令立即可用。另外，请注意，当你在终端之间切换并输入命令时，使用 CTRL+R 可以立即使用它们，但向上箭头的操作在终端之间不受影响。（如果你安装了 Oh My Zsh，情况可能就不一样了，因为它会自动将所有命令追加到历史记录中。）多次按下 CTRL+R 可以在按时间排序和按相关性排序之间切换。请注意，此配置将只显示当前主机的查询历史记录，即使你正在从多个主机向 Loki 发送 shell 数据。我认为默认情况下这是最合理的。如果你想改变这种行为，有很多地方可以调整；请参见 loki-shell 版本库了解更多。它还安装了一个名为 hist 的别名。alias hist="$HOME/.loki-shell/bin/logcli --addr=$LOKI_URL" LogCLI 可以用来直接在 Loki 上查询和搜索你的历史，也允许你搜索其他主机。查看 LogCLI 的入门指南，了解更多关于查询的信息。Loki 的日志查询语言（LogQL）提供了度量查询，可以让你做一些有趣的事情，例如，我可以看到在过去 30 天里我发出了多少次 kc 命令（我对 kubectl 的别名）。额外增强安装 Grafana，摆弄一下你的 shell 历史记录。docker run -d -p 3000:3000 --name=grafana grafana/grafana 打开 Web 浏览器，访问 http://localhost:3000，使用默认的 admin/admin 用户名和密码登录。在左边，导航到“ 配置 Configuration -> 数据源 Datasources ”，点击“ 添加数据源 Add Datasource ”按钮，然后选择 “Loki”。对于 URL，你应该可以使用 http://localhost:4100（然而，在我的 WSL2 机器上，我必须使用计算机的实际 IP 地址）。单击“ 保存并测试 Save and Test ”。你应该看到连接了数据源并找到了标签。点击左边的“ 管理器 Explore ”图标，确保选择 Loki 数据源，并尝试这个查询：{job="shell"} 如果发送 shell 命令的主机较多，可以使用“ 主机 Host ”标签将结果限制在某个主机上：{job="shell", hostname="myhost"}. 你也可以用过滤表达式寻找特定的命令：{job="shell"} |= "docker" 或者你可以从日志中探索度量的世界，看看你使用 shell 的频率：rate({job="shell"}[1m]) 想从一个事件中重建一个时间线？你可以通过特定的命令进行过滤，查看它的运行时间：要想知道你还能做什么，并了解更多关于 Loki 查询语言的信息，请查看 LogQL 指南。总结更多的想法、故障排除和更新，请关注该 GitHub 版本库。这仍然是一项正在进行中的工作，所以请在那里报告发现的任何问题。要了解更多关于 Loki 的信息，请查看文档、博客文章和该 GitHub 版本库，或者在 Grafana Cloud 中试用。特别感谢我的同事 Jack Baldry 为这个想法播下的种子。我有 Loki 的知识来实现这个想法，但如果不是他的建议，我想我永远也不会做到这一点。via: https://opensource.com/article/20/10/shell-history-loki-fzf作者：Ed Welch 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
通过集中日志记录来减少安全风险
集中日志并结构化待处理的日志数据可缓解与缺少日志相关的风险日志记录和日志分析对于保护基础设施安全来说至关重要，尤其是当我们考虑到通用漏洞的时候。这篇文章基于我在 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 服务器日志文件
这个 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: for row in source: if row.status == 404: print(row.request.url.path_str) 你可能要对这些数据去重，并打印独立的 404 页面数量：s = set() with open('ssl_access.log') as f: with ApacheSource(f) as source: for row in source: if row.status == 404: s.add(row.request.url.path_str) print(len(s)) 我和 Dave 一直在努力扩展 piwheel 的日志记录器，使其包含网页点击量、软件包搜索等内容，归功于 lars，这些并不难。它不会告诉我们有关用户的任何答案。我们仍然需要进行数据分析，但它去掉了复杂不便的文件格式，并以我们可以利用的方式将它放入我们的数据库。查阅 lars 的文档，以了解如何读取 Apache、Nginx 和 IIS 日志，并了解你还可以使用它做什么。再次感谢 Dave 提供的出色工具！最初发布在 Ben Nuttall 的 Tooling Blog 中，并获许重新发布。via: https://opensource.com/article/20/7/python-lars作者：Ben Nuttall 选题：lujun9972 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
日志滚动 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，将原来的 syslog.1.gz 命名为 syslog.2.gz，但新的 syslog 文件不一定必须创建。你可以按照下面的几条命令执行操作，以确保文件的属主和权限正确：$ sudo touch /var/log/syslog $ sudo chown syslog:adm /var/log/syslog $ sudo chmod 640 /var/log/syslog你也可以把以下这一行内容添加到 /etc/logrotate.d/rsyslog 当中，由 logrotate 来帮你完成上面三条命令的操作：create 0640 syslog adm整个配置文件的内容是这样的：/var/log/syslog { rotate 7 daily missingok notifempty create 0640 syslog adm <== delaycompress compress postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }下面是手动滚动记录用户登录信息的 wtmp 日志的示例。由于 /etc/logrotate.d/wtmp 中有 rotate 2 的配置，因此系统中只保留了两份 wtmp 日志文件。滚动前：$ ls -l wtmp* -rw-r----- 1 root utmp 1152 Mar 12 11:49 wtmp -rw-r----- 1 root utmp 768 Mar 11 17:04 wtmp.1执行滚动命令：$ sudo logrotate -f /etc/logrotate.d/wtmp滚动后：$ ls -l /var/log/wtmp* -rw-r----- 1 root utmp 0 Mar 12 11:52 /var/log/wtmp -rw-r----- 1 root utmp 1152 Mar 12 11:49 /var/log/wtmp.1 -rw-r----- 1 root adm 99726 Feb 21 07:46 /var/log/wtmp.report需要知道的是，无论发生的日志滚动是自动滚动还是手动滚动，最近一次的滚动时间都会记录在 logrorate 的状态文件中。$ grep wtmp /var/lib/logrotate/status "/var/log/wtmp" 2020-3-12-11:52:57via: https://www.networkworld.com/article/3531969/manually-rotating-log-files-on-linux.html作者：Sandra Henry-Stocker 选题：lujun9972 译者：HankChow 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出