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：KB
• M：MB
• G：GB

例 3：

sudo journalctl --flush --rotate

sudo journalctl --vacuum-files=2

vacuum-files 选项会清除所有低于指定数量的日志文件。因此，在上面的例子中，只有最后两个日志文件被保留，其他的都被删除。同样，这只对存档的文件有效。

如果你愿意，你可以把两种选项结合起来，但我建议不要这样做。然而，如果同时使用两个选项，请确保先用 --rotate 选项运行。

使用配置文件自动删除

虽然上述方法很好，也很容易使用，但建议你使用 journald 配置文件来控制日志文件的清理过程，该文件存在于 /etc/systemd/journald.conf。

systemd 为你提供了许多参数来有效管理日志文件。通过组合这些参数，你可以有效地限制日志文件所占用的磁盘空间。让我们来看看。

如果你在运行中的系统的 /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 桌面、服务器或任何应用中遇到问题时，你首先会查看单独的日志文件。日志文件通常是文本流和来自应用的带有时间戳的消息。它可以帮助你缩小特定问题的范围，并使你能够找到问题的原因。它还可以帮助从网络获得帮助。

一般来说，所有的日志文件都位于 /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 实现中，你可以看到三种主要的集群级日志记录方法。

1. 节点级日志代理
2. 用于日志记录的 挎斗 Sidecar 容器应用程序
3. 将应用程序日志直接暴露给日志后端

节点级日志代理

我想考虑节点级日志代理。你通常使用 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 功能，但它提供了大多数企业需要的灵活性，例如：

1. 扩展对网络协议和输出格式的更广泛支持。
2. 提供负载均衡能力并提高性能。
3. 可配置为通过上游聚合接受复杂的日志记录要求。

因为这第三种方法通过直接从每个应用程序推送日志来依赖非 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 方法以相同的方式工作，但是它会立即使脚本失效。这有助于突显失败的位置与原因。

最佳实践

1. 在你的 Groovy 代码中大量使用 echo Jenkins 步骤来通知用户你在做什么。这些也可以帮助记录你的代码。
2. 使用空的日志语句（Groovy 中空的 echo 步骤、echo '' 或 Shell 中的 echo）来分割输出，提高可读性。你可能在你的代码中为同样的目的使用空行。
3. 避免在脚本中使用 set +x 的陷阱，因为它隐藏了日志记录已执行的 Shell 语句。它并没有清理你的日志，而是使你的管道成为一个黑盒子，隐藏了管道正在做的行为以及出现的任何错误。确保管道功能尽可能透明。
4. 如果你的管道创建了 中间工件 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中国 荣誉推出