控制 alloydbctl 和 Ansible 的编排器级诊断日志，以调整详细程度进行问题排查，或将自动脚本的输出静音。这些日志对于诊断集群引导、管理或一般操作期间的问题至关重要。
收集和转储调试信息
您可以使用 Ansible 角色或调试转储工具来收集和转储调试信息。
使用 Ansible 收集调试信息
google.alloydbomni_orchestrator.dump_debug Ansible 角色会自动在部署规范中定义的所有 AlloyDB Omni 节点上执行收集过程。它会收集并整合以下信息：
- Systemd 状态：所有 AlloyDB Omni 服务的当前状态。
- Journal 日志：系统日志，支持基于时间的过滤。
生成调试信息转储
在控制节点上创建 Ansible playbook（例如
dump_debug.yml）。将以下内容添加到 playbook 中：- name: Collect AlloyDB Omni Debug Dump hosts: all become: true gather_facts: true vars: ansible_user: ANSIBLE_USER ansible_ssh_private_key_file: PATH_TO_PRIVATE_SSH_KEY # Optional: Customize dump behavior dump_debug_binary_path: "BINARY_PATH" dump_debug_collection_type: "COLLECTION_TYPE" dump_debug_local_dest: ""ANSIBLE_DESTINATION"" dump_debug_tag: ""TAG_NAME"" dump_debug_journal_spec: "JOURNAL_SPEC" roles: - role: google.alloydbomni_orchestrator.dump_debug替换以下内容：
ANSIBLE_USER：Ansible 登录时使用的用户。PATH_TO_PRIVATE_SSH_KEY：SSH 私钥文件的路径。BINARY_PATH：可选。远程节点上二进制文件的路径。 默认值为/usr/local/bin。COLLECTION_TYPE：可选。集合类型（status、logs、config或all）。默认值为all。ANSIBLE_DESTINATION：可选。Ansible 控制节点上的目标位置。默认值为/tmp/debug_dump。TAG_NAME：可选。自定义标识符。如果标记已存在，则会添加后缀（例如_1）。默认为系统时间戳。JOURNAL_SPEC：可选。支持journalctl标志（例如"--since '1 hour ago'"）。默认值为-n 1000。
使用
ansible-playbook命令运行 playbook，并将deployment_spec.yaml指定为清单。# standard execution ansible-playbook dump_debug.yml -i PATH_TO_DEPLOYMENT_SPEC或者，使用您选择的自定义标记和日志规范运行 playbook。
ansible-playbook dump_debug.yml -i PATH_TO_DEPLOYMENT_SPEC \ -e 'dump_debug_tag=TAG_NAME' \ -e 'dump_debug_journal_spec: "JOURNAL_SPEC"'替换以下内容：
PATH_TO_DEPLOYMENT_SPEC：部署规范 YAML 文件的路径。TAG_NAME：可选。自定义标识符。如果标记已存在，则会添加后缀（例如_1）。默认为系统时间戳。JOURNAL_SPEC：可选。支持journalctl标志（例如"--since '1 hour ago'"）。默认值为-n 1000。
使用调试转储工具收集调试信息
您可以使用 alloydbomni_dump 工具生成转储文件。此工具包含在 AlloyDB Omni 编排器软件包中。
生成转储文件
在要调试的 AlloyDB Omni 集群节点上运行以下脚本。
sudo /usr/local/bin/alloydbomni_dump \
-k SSH_KEY \
-u USER \
-d PATH_TO_DEPLOYMENT_SPEC \
-o OUTPUT_DIRECTORY \
[options]替换以下内容：
SSH_KEY：用户的 SSH 私钥的路径。USER：用于通过 SSH 访问集群节点的用户名。PATH_TO_DEPLOYMENT_SPEC：部署规范 YAML 文件的路径。OUTPUT_DIRECTORY：用于保存生成的转储文件的本地目录。
支持的指令
-k：SSH 私钥的必需路径。-u：所需的服务账号用户名。-d：部署规范 YAML 文件的路径（必需）。-o：最终 tar 文件的必需输出目录。-t：可选的自定义代码标识符。-c：可选集合类型（status、logs、config、all）。-s：可选日志大小和时间规范（例如-s "--since \"30 minutes ago\""）。
执行示例
alloydbomni_dump -k /home/user/ssh-key \
-u sa_12345 -d /tmp/deployment_spec.yaml \
-o /tmp/debug_dump -s "--since \"2 hours ago\""获取编排器诊断日志
您可以获取由 alloydbctl 和 Ansible 编排器生成的诊断日志。这样，您就可以提高详细程度以进行问题排查，或将输出静音以运行自动化脚本。日志记录对于诊断集群引导、管理或常规操作期间的问题至关重要。
获取 alloydbctl 调试日志
alloydbctl 工具支持通过命令行参数来控制日志级别和输出目标位置。日志级别决定了要记录的消息的严重级别，而日志目标位置则指定了这些日志的写入位置。
alloydbctl [command] ... [{-l|--log_level} <LEVEL>] [{-f|--log_file} <FILE>]日志级别（-l / --log_level）
您可以使用以下日志级别。日志级别不区分大小写（例如，DEBUG 和 debug 的处理方式相同）。
- NOTSET（默认）：不记录日志。
- DEBUG：记录详细信息，通常仅在诊断问题时有用。记录 RPC 请求和响应。
- INFO：确认一切正常。
- WARNING：表示发生了意外情况（例如“磁盘可用空间不足”），但软件仍在运行。
- 错误：由于存在更严重的问题，软件无法执行某些功能。
- CRITICAL：严重错误，表示程序本身可能无法继续运行。
日志目标位置（-f / --log_file）
您可以选择以下日志目标位置：
- 文件路径：如果提供（例如
-f /tmp/alloydbctl.log），日志将写入指定的文件。 - 标准输出：如果未提供，日志会输出到控制台 (stdout)。
示例
以下示例使用 alloydbctl 应用部署和资源规范，同时启用 DEBUG 级别日志记录。日志（包括详细信息和 RPC 请求/响应）会写入文件 /tmp/alloydbctl_debug.log，而不是标准输出。
alloydbctl apply -d deployment_spec.yaml -r resource_spec.yaml -l DEBUG -f /tmp/alloydbctl_debug.log获取 Ansible 调试日志
Ansible Orchestrator 会根据 Ansible 任务和 Ansible 模块生成日志。您可以传递标准 Ansible 命令行参数，以更改任务和模块的日志记录行为。如需了解详情，请参阅 ansible-playbook 文档。
Ansible 模块的日志级别
默认情况下，日志会发送到运行 playbook 的控制台。
如需设置 log_level 配置设置，请运行以下命令：
ansible-playbook -i inventory.yaml bootstrap.yaml \
-e resource_spec=resource_spec.yaml \
-e log_level=DEBUG
您还可以使用以下标准 Ansible 详细程度标志来控制输出详细程度：
-v：基本详细程度（INFO 级日志）。-vv或更高级别：提高详细程度（DEBUG 级别日志）。
例如：
ansible-playbook -i inventory.yaml bootstrap.yaml \
-e resource_spec=resource_spec.yaml \
-vv
Ansible 模块的日志路径
默认情况下，系统不会捕获日志，必须配置日志级别才能在日志文件中捕获日志。
如需将 Ansible 输出保存到日志文件，请运行以下命令来设置 log_path 配置：
ansible-playbook -i inventory.yaml bootstrap.yaml \
-e resource_spec=resource_spec.yaml \
-e log_file=/tmp/ansible-module.log
重置失败的 systemd 实例
如果调试转储显示过时、失败的服务实例，请在受影响的集群节点上运行以下命令来清除这些实例：
sudo systemctl reset-failed如需重置特定的 systemd 服务，请指定服务实例名称：
sudo systemctl reset-failed INSTANCE_NAME将 INSTANCE_NAME 替换为 systemd 服务实例的名称，例如 alloydbomni18@abc.service。