多节点OpenStack Charms 部署指南0.0.1.dev303--19--juju log

本文链接：https://blog.csdn.net/m0_49212388/article/details/115295164

参考文档：
Juju logs

Juju操作员可以使用各种日志记录资源。此页面将解释这些内容并显示如何使用它们。它将涵盖：

模型日志
远程记录
审核记录

模型日志

模型日志可以视为Juju的“常规日志”，可以通过debug-log命令进行检查。此方法按模型提供日志，因此比直接在文件系统上的多台（Juju）计算机上读取单个日志更为方便。尽管如此，后者仍可以在特殊情况下完成，并在此处提供了一些解释。

在HA情况下中查看日志时，请参阅Controller HA and logging记录

juju 代理

Juju代理“ jujud”的作用之一是执行日志记录。每个Juju机器和单元都有一个代理。例如，对于ID为“ 2”的机器，我们会看到此类代理的证据：

juju ssh 2 ls -lh /var/lib/juju/agents

输出如下：

drwxr-xr-x 2 root root 4.0K Apr 28 00:42 machine-2
drwxr-xr-x 4 root root 4.0K Apr 28 00:42 unit-nfs2-0

因此，这台计算机上正在运行两个代理。一种用于机器本身，另一种用于服务单元

这些目录之一的内容：

juju ssh 2 ls -lh /var/lib/juju/agents/machine-2

显示代理的配置文件：

-rw------- 1 root root 2.1K Apr 28 00:42 agent.conf

考虑保留这些文件的备份，尤其是在升级代理之前。请参阅升级模型。

debug-log命令

debug-log命令显示模型中运行的所有Juju代理（机器和单元）的合并日志。 switch命令用于更改模型。另外，也可以使用“ -m”选项来选择模型。默认模型是当前模型。

“控制器”模型捕获与内部管理（控制器活动）相关的日志，例如向数据库添加机器和服务。托管模型将提供有关预配置后发生的活动的日志。

由于上述原因，在部署服务时，通常不会在工作负载模型中进行日志记录，因为日志记录首先是在“控制器”模型中进行的。

输出是固定数量的现有日志行（由可能的选项指定的数量；默认值为10）和新附加的消息流。现有行和附加行都可以通过指定选项进行过滤。

流式传输的例外是在限制输出时（选项“ –limit”；请参见下文），并且达到了该限制。在所有其他情况下，都需要使用Ctrl-C中断该命令，以便重新获得Shell提示符。

有关完整的语法，请参见“命令参考”页面。

例子：

从最后十条日志消息开始：

juju debug-log

从最后三十条日志消息开始：

juju debug-log -n 30

首先查看所有日志消息：

juju debug-log --replay

首先从“ lxd-pilot”模型的最后二十条日志消息开始：

juju debug-log -m lxd-pilot -n 20

从最后的500行开始。 grep实用程序用作文本过滤器：

juju debug-log -n 500 | grep amd64

logging级别

您可以像这样验证当前的日志记录级别：

juju model-config logging-config

输出类似下面：

<root>=WARNING;unit=DEBUG

以上是默认配置。它将机器代理程序日志级别设置为“警告”，并将单元代理程序日志级别设置为“调试”。

从最详细到最不详细的日志记录级别如下：

TRACE
DEBUG
INFO
WARNING
ERROR

更改日志记录级别

诊断问题（并可能提交错误）时，第一步是使日志记录更加详细。例如，要将单位代理的日志记录级别提高到“ TRACE”，您可以输入以下命令：

juju model-config logging-config="<root>=WARNING;unit=TRACE"

为了避免不必要地填充数据库，当不再需要详细的日志记录时，请不要忘记将日志记录恢复为正常级别。

日志记录级别也可以按单位更改。请参阅下面的代理日志记录覆盖部分。

进阶筛选

Juju日志行以以下格式编写：

<entity> <timestamp> <log-level> <module>:<line-no> <message>

--include和--exclude选项分别选择和取消选择记录消息的实体。实体是Juju机器或单位代理。实体名称类似于juju status显示的名称。

同样，--include-module和--exclude-module选项可用于影响基于（点）模块名称显示的消息的类型。模块名称可以截断。

机器和单元过滤的组合使用逻辑或，而模块和机器/单元过滤的组合使用逻辑“AND”

--level选项对日志记录的详细程度设置了限制（例如，--level INFO将允许显示级别为“ INFO”，“ WARNING”和“ ERROR”的消息）。

例子：

首先从最后1000行开始，并排除来自机器3的消息：

juju debug-log -n 1000 --exclude machine-3

要在整个日志中选择从特定单元和特定机器发出的所有消息：

juju debug-log --replay --include unit-mysql-0 --include machine-1

该单元也可以写为“ mysql / 0”（如juju status所示）。

要查看整个日志中的所有警告和错误消息：

juju debug-log --replay --level WARNING

要逐步从整个日志中排除更多内容，请执行以下操作：

juju debug-log --replay --exclude-module juju.state.apiserver
juju debug-log --replay --exclude-module juju.state
juju debug-log --replay --exclude-module juju

从最后的2000行开始，并包括与juju.cmd和juju.worker模块有关的消息：

juju debug-log --lines 2000 \
    --include-module juju.cmd \
    --include-module juju.worker

代理日志记录覆盖

如我们所见，机器代理和单元代理的日志记录级别被指定为单个模型配置设置。但是，在某些情况下（例如，针对性的详细调试），可能需要基于每个代理增加日志记录级别。降低模型范围的日志级别后，也可以执行此操作（如上文更改日志级别中的说明）:
例如，让我们为MySQL单元启用“ TRACE”日志记录级别。我们首先登录到本机的机器（在此示例中为“ 0”）

juju ssh mysql/0

然后，将LOGGING_OVERRIDE行：juju = trace添加到“值”部分，以编辑文件/var/lib/juju/agents/unit-mysql-0/agent.conf。

为了清楚起见，文件的底部现在看起来像：

loggingconfig: <root>=WARNING;unit=DEBUG
values:
  CONTAINER_TYPE: ""
  NAMESPACE: ""
  LOGGING_OVERRIDE: juju=trace
mongoversion: "0.0"

受影响的代理将需要重新启动以使此更改生效：

sudo systemctl restart jujud-unit-mysql-0.service

日志文件

日志文件位于Juju创建的每台计算机上，包括控制器。它们位于/ var / log / juju下，并且与计算机和任何单位相对应。
使用上一节中的示例：

juju ssh 2 ls -lh /var/log/juju

输出:

-rw------- 1 syslog syslog  22K Apr 28 00:42 machine-2.log
-rw------- 1 syslog syslog 345K Apr 28 16:58 unit-nfs2-0.log

每个控制器上都有一个额外的日志文件：logsink.log：

juju ssh -m controller 0 ls -lh /var/log/juju

输出:

-rw------- 1 syslog syslog 2.3M Apr 28 17:05 logsink.log
-rw------- 1 syslog syslog  85K Apr 28 17:03 machine-0.log

文件logsink.log包含控制器管理的所有模型的日志。它的内容被发送到数据库，由debug-log命令使用。

在高可用性方案中，由于代理可以选择几个控制器来发送日志，因此不能保证logsink.log包含所有消息。 debug-log命令应用于在所有控制器之间访问合并数据。

远程日志

在每个模型的基础上，可以选择通过安全的TLS连接将日志消息转发到远程syslog服务器。

请参阅Rsyslog文档以获取有关安全性相关文件（证书，密钥）和远程syslog服务器配置的帮助。

配置

远程日志记录是在控制器创建步骤期间通过提供YAML格式配置文件进行配置的：

juju bootstrap <cloud> --config logconfig.yaml

YAML文件的内容格式为：

syslog-host: <host>:<port>
syslog-ca-cert: |
-----BEGIN CERTIFICATE-----
 <cert-contents>
-----END CERTIFICATE-----
syslog-client-cert: |
-----BEGIN CERTIFICATE-----
 <cert-contents>
-----END CERTIFICATE-----
syslog-client-key: |
-----BEGIN PRIVATE KEY-----
 <cert-contents>
-----END PRIVATE KEY-----

启用：

要为模型实际启用远程日志记录，需要为该模型设置配置密钥：

juju model-config -m <model> logforward-enabled=True

最初的100条（最大）现有日志行将被转发。
请参阅配置模型以获取有关配置模型的更多帮助。
请注意，可以一步一步配置和启用所有控制器型号上的转发：

juju bootstrap <cloud> --config logforward-enabled=True --config logconfig.yaml

审核日志

Juju审核日志记录通过捕获调用的用户命令来按时间顺序列出所有事件。这些日志驻留在控制器中，该控制器涉及影响Juju客户端，Juju计算机和控制器本身的命令的传输。

审核日志文件名为/var/log/juju/audit.log，其中包含以下记录：

会话，是与单个顶级CLI命令相关联的API方法的集合
一个Request，一个API方法
ResponseErrors，由API方法导致的错误
可以将信息从审核日志中过滤掉，以防止其文件无限制地增长并使其难以阅读。请参阅从审核日志中排除信息。
通常通过通过SSH连接到控制器并查看文件来查看日志：

juju ssh -m controller 0
more /var/log/juju/audit.log