本文档提供的信息可帮助您诊断和解决正在运行的 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 控制台中,转到 leaderboard 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\
- Linux:
- 验证虚拟机的磁盘是否未满。
- 验证日志记录配置是否正确。
以下步骤要求您通过 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 指标,Ops Agent 需要安装 GPU 驱动程序, 虚拟机上配置的资源如需检查驱动程序,请执行以下操作:
如需验证驱动程序是否已正确安装并正常运行,请按照验证 GPU 驱动程序安装的步骤操作。
如果未安装该驱动程序,请执行以下操作:
- 安装 GPU 驱动程序。
-
安装或升级 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 等虚拟设备注入该指标。 |
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/*/
重新安装并重启代理:
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 或更高版本,并完全重置代理状态。
如果您的系统仍然生成大量代理自身日志,请考虑使用日志轮换。如需了解详情,请参阅设置日志轮换。