排查 Ops Agent 数据注入问题

本文档提供的信息可帮助您诊断和解决正在运行的 Ops Agent 中日志和指标的数据注入问题。如果 Ops Agent 未在运行，请参阅排查安装和启动问题。

准备工作

在尝试解决问题之前，请检查代理的健康检查状态。

Google Cloud 控制台显示 Ops Agent 安装卡在“待处理”状态

即使在成功安装 Ops Agent 后，Google Cloud 控制台仍可能会显示“待处理”状态。可使用 gcpdiag 确认 Ops Agent 安装，并验证代理是否在从虚拟机实例传输日志和指标。

安装失败的常见原因

以下原因可能会导致 Ops Agent 安装失败：

虚拟机没有关联的服务账号。可将服务账号关联到虚拟机，然后重新安装 Ops Agent。
虚拟机已安装某个旧版代理，这会阻止安装 Ops Agent。可卸载旧版代理，然后重新安装 Ops Agent。

遥测数据传输失败的常见原因

已安装且正在运行的 Ops Agent 可能会因以下原因而无法从虚拟机发送日志和/或指标：

关联到虚拟机的服务账号缺少 roles/logging.logWriter 或 roles/monitoring.metricWriter 角色。
未启用日志记录或监控访问权限范围。如需了解如何检查和更新访问权限范围，请参阅验证您的访问权限范围。
未启用 Logging API 或 Monitoring API。

使用代理健康检查可确定根本原因和相应的解决方案。

代理在运行，但无法注入数据

使用 Metrics Explorer 查询代理 uptime 指标，并验证代理组件 google-cloud-ops-agent-metrics 或 google-cloud-ops-agent-logging 是否正在写入指标。

在 Google Cloud 控制台中，转到 Metrics Explorer 页面：
进入 Metrics Explorer

如果您使用搜索栏查找此页面，请选择子标题为监控的结果。
在标有构建器代码的切换开关中，选择代码，然后将语言设置为 MQL。

输入以下查询，然后点击运行：

fetch gce_instance
| metric 'agent.googleapis.com/agent/uptime'
| align rate(1m)
| every 1m

代理正在向 Cloud Logging 发送日志吗？

如果代理正在运行但未发送日志，请检查代理运行时的健康检查状态。

流水线错误

如果您看到运行时错误 LogPipelineErr（“Ops Agent 日志记录流水线失败”），则表示 Logging 分代理在写入日志时遇到问题。检查是否存在以下状况：

验证是否可以访问 Logging 分代理的存储空间文件。这些文件位于以下位置：
- Linux：/var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows：C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
验证虚拟机的磁盘是否未满。
验证日志记录配置是否正确。

以下步骤要求您通过 SSH 连接到虚拟机。

如果您更改了日志记录配置，或者缓冲区文件可访问且虚拟机的磁盘未满，请重启 Ops Agent：

Linux

要重启代理，请在您的实例上运行以下命令：
```
sudo systemctl restart google-cloud-ops-agent
```
如需确认代理已重启，请运行以下命令并验证“Metrics Agent”和“Logging Agent”组件是否已启动：
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

使用 RDP 或类似工具连接到您的实例，然后登录到 Windows。
右键点击 PowerShell 图标并选择 Run as Administrator，以管理员权限打开 PowerShell 终端
如需重启代理，请运行以下 PowerShell 命令：
```
Restart-Service google-cloud-ops-agent -Force
```
如需确认代理已重启，请运行以下命令并验证“Metrics Agent”和“Logging Agent”组件是否已启动：
```
Get-Service google-cloud-ops-agent*
```

日志解析错误

如果您看到运行时错误 LogParseErr（“Ops Agent 无法解析日志”），则最可能的问题在于日志记录处理器的配置。如需解决此问题，请执行以下操作：

验证任何 parse_json 处理器的配置是否正确。
验证任何 parse_regex 处理器的配置是否正确。
如果您没有 parse_json 或 parse_regex 处理器，请检查任何其他日志记录处理器的配置。

以下步骤要求您通过 SSH 连接到虚拟机。

如果您更改日志记录配置，请重启 Ops Agent：

Linux

要重启代理，请在您的实例上运行以下命令：
```
sudo systemctl restart google-cloud-ops-agent
```
如需确认代理已重启，请运行以下命令并验证“Metrics Agent”和“Logging Agent”组件是否已启动：
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

使用 RDP 或类似工具连接到您的实例，然后登录到 Windows。
右键点击 PowerShell 图标并选择 Run as Administrator，以管理员权限打开 PowerShell 终端
如需重启代理，请运行以下 PowerShell 命令：
```
Restart-Service google-cloud-ops-agent -Force
```
如需确认代理已重启，请运行以下命令并验证“Metrics Agent”和“Logging Agent”组件是否已启动：
```
Get-Service google-cloud-ops-agent*
```

检查本地指标

以下步骤要求您通过 SSH 连接到虚拟机。

日志记录模块正在运行吗？使用以下命令进行检查：

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

以管理员身份打开 Windows PowerShell 并运行以下命令：

Get-Service google-cloud-ops-agent

您还可以在“服务”应用中检查服务状态，在“任务管理器”应用中检查正在运行的进程。

检查日志记录模块日志

此步骤要求您通过 SSH 连接到虚拟机。

您可以在 /var/log/google-cloud-ops-agent/subagents/*.log（对于 Linux）和 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log（对于 Windows）中找到日志记录模块日志。如果没有任何日志，则表明代理服务未正常运行。请先转到“代理已安装，但无法运行”部分，以消除该状况。

写入 Logging API 时，您可能会看到 403 权限错误。例如：

[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
{
"error": {
  "code": 403,
  "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
  "status": "PERMISSION_DENIED",
  "details": [
    {
      "@type": "type.googleapis.com/google.rpc.Help",
      "links": [
        {
          "description": "Google developers console API activation",
          "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
        }
      ]
    }
  ]
}
}

如需消除此错误，请启用 Logging API 并设置 Logs Writer 角色。

您可能会看到 Logging API 的配额问题。例如：

error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"

如需消除此错误，请增加配额或减少日志吞吐量。

您可能会在模块日志中看到以下错误：
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
或
```
can't fetch token from the metadata server
```
这些错误可能表示您在部署代理时没有服务账号或指定的凭据。如需了解如何解决此问题，请参阅授权 Ops Agent。

代理正在向 Cloud Monitoring 发送指标吗？

检查指标模块日志

此步骤要求您通过 SSH 连接到虚拟机。

您可以在 syslog 中找到指标模块日志。如果没有日志，则说明代理服务未正常运行。请先转到“代理已安装，但无法运行”部分，以消除该状况。

写入 Monitoring API 时，您可能会看到 PermissionDenied 错误。如果 Ops Agent 的权限未正确配置，则会出现此错误。例如：

Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}

如需消除此错误，请启用 Monitoring API 并设置 Monitoring Metric Writer 角色。

写入 Monitoring API 时，您可能会看到 ResourceExhausted 错误。如果项目达到任何 Monitoring API 配额上限，则会出现此错误。例如：

Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}

如需消除此错误，请增加配额或减少指标吞吐量。

您可能会在模块日志中看到以下错误：
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
或
```
can't fetch token from the metadata server
```
这些错误可能表示您在部署代理时没有服务账号或指定的凭据。如需了解如何解决此问题，请参阅授权 Ops Agent。

网络连接问题

如果代理正在运行，但未发送日志和指标，则可能存在网络问题。可能发生的网络连接问题的类型因应用拓扑而异。如需大致了解 Compute Engine 网络，请参阅虚拟机网络概览。

导致连接问题的常见原因包括：

存在干扰传入流量的防火墙规则。如需了解防火墙规则，请参阅使用 VPC 防火墙规则。
HTTP 代理配置存在问题。
DNS 配置。

Ops Agent 会运行健康检查，以检测网络连接错误。如需了解针对连接错误的建议操作，请参阅健康检查文档。

从 Ops Agent 2.28.0 版开始，Ops Agent 会限制可以用于存储缓冲区区块的磁盘可用空间量。当日志记录数据无法发送到 Cloud Logging API 时，Ops Agent 会创建缓冲区区块。如果不设置上限，这些区块可能会占用所有可用空间，从而中断虚拟机上的其他服务。当网络中断导致缓冲区区块写入磁盘时，Ops Agent 会使用平台专用的磁盘可用空间量来存储这些区块。如果虚拟机无法向 Cloud Logging API 发送缓冲区区块，则 Linux 虚拟机上的 /var/log/google-cloud-ops-agent/subagents/logging-module.log 或 Windows 虚拟机上的 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 中也会显示类似以下示例的消息：

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

我想仅收集指标或日志，而不想同时收集两者

默认情况下，Ops Agent 会同时收集指标和日志。如需停用指标或日志收集，请使用 Ops Agent config.yaml 文件替换默认的 logging 或 metrics 服务，以使相应的默认流水线没有接收器。如需了解详情，请参阅以下内容：

通过停用 Ops Agent 分代理服务“Logging 代理”或“Monitoring 代理”来停止数据注入会导致配置无效，因此不支持使用该方法。

系统正在收集指标，但似乎出现了问题

代理记录“导出失败。将重试”消息

丢弃累积指标的第一个数据点时，您会看到“导出失败”日志条目。以下日志无害，可以放心地忽略：

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}

代理正在记录“无法写入时序：点必须按顺序写入。”消息

如果您已从旧版 Monitoring 代理升级到 Ops Agent，并在写入累积指标时看到以下错误消息，则解决方案是重新启动虚拟机。Ops Agent 和 Monitoring 代理以不同的方式计算累计指标的开始时间，这可能会导致各个点的顺序混乱。重新启动虚拟机会重置开始时间并解决此问题。

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}

代理正在记录“令牌必须是短期有效的令牌（60 分钟）且在合理的时间范围内”消息

如果您在代理写入指标时看到以下错误消息，则表示系统时钟未正确同步：

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.

如需了解如何同步系统时钟，请参阅在虚拟机上配置 NTP。

代理在记录“不支持类型为‘nvml’的指标接收器”

如果您使用 nvml 接收器收集 NVIDIA 管理库 (NVML) GPU 指标 (agent.googleapis.com/gpu)，则表示您一直在使用为 NVML 指标提供预览版支持的 Ops Agent 版本。Ops Agent 2.38.0 版本中已正式提供对这些指标的支持。在正式版中，nvml 接收器完成的指标收集已合并到 hostmetrics 接收器，并且 nvml 接收器已移除。

使用预览版 nvml 接收器并替换用户指定的配置文件中的默认收集时间间隔时，您会在安装 Ops Agent 2.38.0 版或更高版本后看到错误消息“不支持类型为“nvml”的指标接收器”。发生此错误是因为 nvml 接收器不再存在，但用户指定的配置文件仍引用它。

如需解决此问题，请更新用户指定的配置文件以改为替换 hostmetrics 接收器上的收集时间间隔。

缺少 GPU 指标

如果 Ops Agent 正在收集某些指标，但缺少部分或全部 NVIDIA 管理库 (NVML) GPU (agent.googleapis.com/gpu) 指标，则您可能有配置问题或没有进程使用 GPU。

如果您没有收集任何 GPU 指标，请检查 GPU 驱动程序。为了收集 GPU 指标，Ops Agent 要求在虚拟机上安装和配置 GPU 驱动程序。如需检查驱动程序，请执行以下操作：

如需验证驱动程序是否已安装并正常运行，请按照验证 GPU 驱动程序安装的步骤操作。

如果未安装驱动程序，请执行以下操作：

安装 GPU 驱动程序。
重启 Ops Agent。

安装或升级 GPU 驱动程序后，您必须重启 Ops Agent。

检查 Ops Agent 日志以验证通信是否已成功启动。日志消息类似于以下内容：

Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.

如果已安装 GPU 驱动程序，并且 Ops Agent 日志指示 Ops Agent 正在与驱动程序通信，但您没有看到任何 GPU 指标，则问题可能是您使用的图表出现问题。如需了解如何排查图表问题，请参阅图表未显示任何数据。

如果您要收集某些 GPU 指标，但缺少 processes 指标（processes/max_bytes_used 和 processes/utilization），则表示您没有进程在 GPU 上运行。如果没有进程在 GPU 上运行，则系统不会收集 GPU processes 指标。

部分指标缺失或不一致

有少量指标在 Ops Agent 2.0.0 及更高版本上的处理方式与 Ops Agent“预览版”（低于 2.0.0 版）或 Monitoring 代理不同。

下表介绍了 Ops Agent 和 Monitoring 代理注入的数据之间的差异。

指标类型，省略了 `agent.googleapis.com`	Ops Agent（正式版）^†	Ops Agent（预览版）^†	Monitoring 代理
`cpu_state`	Windows 的可能值包括 `idle`、`interrupt,`、 `system` 和 `user`。	Windows 的可能值包括 `idle`、`interrupt,`、 `system` 和 `user`。	Windows 的可能值包括 `idle` 和 `used`。
`disk/bytes_used` 和 `disk/percent_used`	注入时 `device` 标签中包含完整路径；例如 `/dev/sda15`。未针对 `tmpfs` 和 `udev` 等虚拟设备注入该指标。	注入时 `device` 标签的路径中不含 `/dev`；例如 `sda15`。针对 `tmpfs` 和 `udev` 等虚拟设备注入该指标。	注入时 `device` 标签的路径中不含 `/dev`；例如 `sda15`。针对 `tmpfs` 和 `udev` 等虚拟设备注入该指标。

^† GA列指 Ops Agent 2.0.0 版及更高版本。预览版列是指低于 2.0.0 的 Ops Agent 版本。

Windows 特有的问题

以下部分仅适用于在 Windows 上运行的 Ops Agent。

Windows 上的损坏性能计数器

如果指标分代理无法启动，您可能会在 Cloud Logging 中看到以下错误之一：

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

如果系统的性能计数器损坏，则可能会出现这些错误。您可以通过重新构建性能计数器来消除错误。在 PowerShell 中，以管理员身份运行以下命令：

cd C:\Windows\system32
lodctr /R

上述命令可能会偶尔失败；在这种情况下，请重新加载 PowerShell 并重试该命令，直到成功为止。

命令成功执行后，重启 Ops Agent：

Restart-Service -Name google-cloud-ops-agent -Force

完全重置代理状态

如果代理进入不可恢复的状态，请按照以下步骤将代理恢复到全新状态。

Linux

停止代理服务：

sudo service google-cloud-ops-agent stop

移除代理软件包：

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

移除代理在磁盘上的自身日志：

sudo rm -rf /var/log/google-cloud-ops-agent

移除代理在磁盘上的本地缓冲区：

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

注意：/var/lib/google-cloud-ops-agent/fluent-bit/buffers/ 目录包含以下类型的文件：

缓冲区文件：这些文件是已由 Ops Agent 跟踪和处理，但尚未注入 Cloud Logging 的缓冲日志条目。如果存在损坏的区块，2.15.0 及以上版本的 Ops Agent 应该会跳过这些区块。但在某些情况下，您需要进行手动清理。这些文件存储在嵌套文件夹中，如：/var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
日志文件跟踪位置文件：这些文件记录日志文件中 Ops Agent 已跟踪的位置。如果这些文件被移除，Ops Agent 将从配置为要跟踪的文件顶部开始跟踪。如果之前成功注入了这些文件，则删除这些文件可能会导致日志重复。这些文件直接存储在目录中，例如：/var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*。

上一个命令中的语法 .../buffers/*/ 可确保仅删除缓冲区文件。位置文件不会被删除。

重新安装并重启代理：

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

停止代理服务：

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

移除代理软件包：

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

移除代理在磁盘上的自身日志：

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

移除代理在磁盘上的本地缓冲区：

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

重新安装并重启代理：

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

重置但保存缓冲区文件

如果虚拟机没有损坏的缓冲区区块（即 Ops Agent 的自身日志文件中没有 format check failed 消息），您可以跳过在重置代理状态时移除本地缓冲区的先前命令。

如果虚拟机有损坏的缓冲区区块，则必须移除它们。以下选项介绍了处理缓冲区的不同方法。完全重置代理状态中所述的其他步骤仍然适用。

方法 1：删除整个 buffers 目录。这是最简单的方法，但可能会导致丢失未损坏的缓冲区日志，或位置文件丢失导致的重复日志。

Linux

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers

Windows

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";

方法 2：从 buffers 目录删除缓冲区子目录，但保留位置文件。完全重置代理状态中介绍了此方法。

选项 3：如果您不想删除所有缓冲区文件，则可以从代理的自身日志中提取损坏的缓冲区文件的名称，并仅删除损坏的缓冲区文件。

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};

选项 4：如果有许多损坏的缓冲区并且您想要重新处理所有日志文件，则可以使用选项 3 中的命令并删除位置文件（这些文件存储每个日志文件的 Ops Agent 进度）。删除位置文件可能导致已成功注入的日志出现重复。此选项仅重新处理当前日志文件，不会重新处理已轮替掉的文件或其他来源（如 TCP 端口）的日志。位置文件存储在 buffers 目录中，但存储为文件。本地缓冲区作为子目录存储在 buffers 目录中。

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}

新版 Ops Agent 中的已知问题

以下各部分介绍了新版 Ops Agent 的已知问题。

Ops Agent 2.47.0、2.48.0 或 2.49.0 版崩溃循环

2.47.0、2.48.0 和 2.49.0 版包含有缺陷的 FluentBit 日志记录组件。此组件在特定日志行上会失败，并导致 Ops Agent 崩溃循环。

此问题已在 Ops Agent 2.50.0 版中得到解决。

从 Ops Agent 2.46.0 版开始，Prometheus 指标命名空间除了包含实例 ID 之外，还包含实例名称

从 2.46.0 版开始，在以 Prometheus 注入格式注入指标时，Ops Agent 会将虚拟机名称作为 namespace 标签的一部分。在早期版本中，Prometheus 指标仅使用虚拟机的实例 ID 作为 namespace 标签的一部分，但从 2.46.0 版开始，namespace 设置为 INSTANCE_ID/INSTANCE_NAME。

如果您的图表、信息中心或提醒政策使用 namespace 标签，则在将 Ops Agent 升级到 2.46.0 版或更高版本后，您可能必须更新查询。例如，如果您的 PromQL 查询类似于 http_requests_total{namespace="123456789"}，则必须将其更改为 http_requests_total{namespace=~"123456789.*"}，因为 namespace 标签的格式为 INSTANCE_ID/INSTANCE_NAME。

从 Ops Agent 2.39.0 版开始，Prometheus 无类型指标更改指标类型

从 2.39.0 版开始，Ops Agent 支持注入具有未知类型的 Prometheus 指标。在较早版本中，这些指标由 Ops Agent 视为采样平均值，但从 2.39.0 版开始，无类型指标被视为采样平均值和计数器。因此，用户现在可以对这些指标使用累积操作。

如果您的图表、信息中心或提醒政策使用 MQL 查询无类型 Prometheus 指标，则在将 Ops Agent 升级到 2.39.0 版或更高版本后，必须更新 MQL 查询。请按如下所述更改指标类型，而不是将无类型指标作为 prometheus.googleapis.com/METRIC_NAME/gauge 查询：

对于指标的采样平均值版本，使用 prometheus.googleapis.com/METRIC_NAME/unknown。
对于指标的计数器版本，使用 prometheus.googleapis.com/METRIC_NAME/unknown:counter。

如果图表、信息中心或提醒政策使用 PromQL 查询无类型 Prometheus 指标，您无需进行任何更改，但您可以在将 Ops Agent 升级到 2.39.0 版或更高版本后，对这些指标应用累积操作。

Windows 虚拟机上的内存用量高（2.27.0 版至 2.29.0 版）

在 Windows 上的 Ops Agent 2.27.0 版到 2.29.0 版中，造成代理有时泄露套接字的 bug 导致内存用量增加且 fluent-bit.exe 进程占用大量句柄。

为了缓解此问题，请将 Ops Agent 升级到 2.30.0 版或更高版本，并重启代理。

Windows 上的事件日志时区错误（2.15.0 版至 2.26.0 版）

如果您从世界协调时间 (UTC) 更改虚拟机的时区，则与 Cloud Logging 中的 Windows 事件日志关联的时间戳可能不正确。此问题已在 Ops Agent 2.27.0 中修复，但由于已知的 Windows 高内存问题，我们建议您在遇到此问题时至少升级到 Ops Agent 2.30.0。如果您无法升级，可以尝试以下解决方法之一。

使用世界协调时间 (UTC) 时区

在 PowerShell 中，以管理员身份运行以下命令：

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

仅替换日志记录分代理服务的时区设置

在 PowerShell 中，以管理员身份运行以下命令：

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Windows 上的解析时间戳包含不正确的时区（2.27.0 之前的任何版本）

如果您使用日志处理器来解析时间戳，则无法在 Windows 上正确解析时区值。此问题已在 Ops Agent 2.27.0 中修复，但由于已知的 Windows 高内存问题，我们建议您在遇到此问题时至少升级到 Ops Agent 2.30.0。

旧版 Ops Agent 中的已知问题

以下部分介绍了旧版 Ops Agent 中的已知问题。

非有害日志（2.9.1 版及更早版本）

从伪进程或受限进程中抓取指标时，可能会出现错误。以下日志无害，可以放心地忽略。如需消除这些消息，请将 Ops Agent 升级到 2.10.0 或更高版本。

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186

代理自身日志占用大量 CPU、内存和磁盘可用空间（2.16.0 版及更早版本）

由于缓冲区区块损坏，2.17.0 之前的 Ops Agent 可能会占用大量 CPU、内存和磁盘可用空间。在 Linux 虚拟机上为 /var/log/google-cloud-ops-agent/subagents/logging-module.log 文件，在 Windows 虚拟机上为 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 文件。发生这种情况时，您会在 logging-module.log 文件中看到大量如下消息。

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb

如需解决此问题，请将 Ops Agent 升级到 2.17.0 或更高版本，并完全重置代理状态。

如果您的系统仍然生成大量代理自身日志，请考虑使用日志轮换。如需了解详情，请参阅设置日志轮换。