本頁面由 Cloud Translation API 翻譯而成。

排解作業套件代理程式資料擷取問題

這份文件提供的資訊可協助您診斷及解決執行中 Ops Agent 的記錄和指標資料擷取問題。如果作業套件代理程式未執行，請參閱排解安裝和啟動問題。

事前準備

著手修正問題前，請先檢查代理程式的健康狀態檢查狀態。

Google Cloud 主控台顯示作業套件代理程式安裝作業停滯在「待處理」狀態

即使成功安裝作業套件代理程式，控制台可能仍會顯示「待處理」狀態。 Google Cloud 使用 gcpdiag 確認作業套件代理程式是否已安裝，並驗證代理程式是否正在從 VM 執行個體傳輸記錄和指標。

安裝失敗的常見原因

作業套件代理程式可能因下列原因而無法安裝：

這個 VM 沒有附加的服務帳戶。將服務帳戶附加至 VM，然後重新安裝 Ops Agent。
VM 已安裝舊版代理程式，因此無法安裝作業套件代理程式。解除安裝舊版代理程式，然後重新安裝作業套件代理程式。

遙測傳輸失敗的常見原因

已安裝並執行的作業套件代理程式可能無法從 VM 傳送記錄、指標或兩者，原因如下：

附加至 VM 的服務帳戶缺少 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

如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。
在標示為「產生器程式碼」的切換按鈕中，選取「程式碼」，然後將語言設為「PromQL」。

輸入下列查詢，然後點選「執行」：

rate({"agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])

代理程式是否將記錄檔傳送至 Cloud Logging？

如果代理程式正在執行，但未傳送記錄，請檢查代理程式執行階段健康狀態檢查的狀態。

管道錯誤

如果看到執行階段錯誤 LogPipelineErr (「Ops Agent logging pipeline failed」)，表示 Logging 子代理程式在寫入記錄時發生問題。請檢查下列條件：

確認可存取 Logging 子代理程式的儲存空間檔案。這些檔案位於下列位置：
- Linux：/var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows：C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
確認 VM 的磁碟空間未滿。
確認記錄設定正確無誤。

您必須透過 SSH 連線至 VM，才能執行這些步驟。

如果變更記錄設定，或緩衝區檔案可存取且 VM 的磁碟未滿，請重新啟動 Ops Agent：

Linux

如要重新啟動代理程式，請在執行個體上執行下列指令：
```
sudo systemctl restart google-cloud-ops-agent
```
如要確定代理程式已重新啟動，請執行下列指令，並驗證「指標代理程式」和「Logging 代理程式」元件是否已啟動：
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

使用遠端桌面協定或類似工具連線至執行個體，並登入 Windows。
以滑鼠右鍵按一下 PowerShell 圖示，然後選取「以系統管理員身分執行」，以管理員權限開啟 PowerShell 終端機。
如要重新啟動代理程式，請執行下列 PowerShell 指令：
```
Restart-Service google-cloud-ops-agent -Force
```
如要確定代理程式已重新啟動，請執行下列指令，並驗證「指標代理程式」和「Logging 代理程式」元件是否已啟動：
```
Get-Service google-cloud-ops-agent*
```

記錄剖析錯誤

如果看到執行階段錯誤 LogParseErr (「Ops Agent failed to parse logs」)，最可能的問題是記錄處理器的設定。如要解決這個問題，請按照下列步驟操作：

確認所有parse_json處理器的設定正確無誤。
確認所有parse_regex處理器的設定正確無誤。
如果沒有 parse_json 或 parse_regex 處理器，請檢查任何其他記錄處理器的設定。

您必須透過 SSH 連線至 VM，才能執行這些步驟。

如果變更記錄設定，請重新啟動作業套件代理程式：

Linux

如要重新啟動代理程式，請在執行個體上執行下列指令：
```
sudo systemctl restart google-cloud-ops-agent
```
如要確定代理程式已重新啟動，請執行下列指令，並驗證「指標代理程式」和「Logging 代理程式」元件是否已啟動：
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

使用遠端桌面協定或類似工具連線至執行個體，並登入 Windows。
以滑鼠右鍵按一下 PowerShell 圖示，然後選取「以系統管理員身分執行」，以管理員權限開啟 PowerShell 終端機。
如要重新啟動代理程式，請執行下列 PowerShell 指令：
```
Restart-Service google-cloud-ops-agent -Force
```
如要確定代理程式已重新啟動，請執行下列指令，並驗證「指標代理程式」和「Logging 代理程式」元件是否已啟動：
```
Get-Service google-cloud-ops-agent*
```

查看當地指標

您必須透過 SSH 連線至 VM，才能執行這些步驟。

記錄模組是否正在執行？請使用下列指令進行檢查：

Linux

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

Windows

以管理員身分開啟 Windows PowerShell，然後執行：

Get-Service google-cloud-ops-agent

您也可以在「服務」應用程式中查看服務狀態，並在「工作管理員」應用程式中檢查執行中的程序。

檢查記錄模組記錄

這個步驟需要透過 SSH 存取 VM。

您可以在 Linux 的 /var/log/google-cloud-ops-agent/subagents/*.log 和 Windows 的 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 中找到記錄模組記錄。如果沒有記錄，表示代理程式服務未正常運作。請先前往「代理程式已安裝完成但並未執行」部分修正該情況。

寫入 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，並設定「記錄檔寫入者」角色。

您可能會看到 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
```
這些錯誤可能表示您部署代理程式時未指定服務帳戶或憑證。如要瞭解如何解決這個問題，請參閱「授權作業套件代理程式」。

代理程式是否將指標傳送至 Cloud Monitoring？

查看指標模組記錄

這個步驟需要透過 SSH 存取 VM。

您可以在系統記錄中找到指標模組記錄。如果沒有記錄，表示代理程式服務運作異常。請先前往「代理程式已安裝完成但並未執行」部分，修正該情況。

寫入 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 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
```
這些錯誤可能表示您部署代理程式時未指定服務帳戶或憑證。如要瞭解如何解決這個問題，請參閱「授權作業套件代理程式」。

網路連線問題

如果代理程式正在執行，但未傳送記錄或指標，可能是網路發生問題。您可能會遇到的網路連線問題類型，取決於應用程式的拓撲。如要查看 Compute Engine 網路總覽，請參閱虛擬機網路總覽。

連線問題的常見原因包括：

干擾傳入流量的防火牆規則。如要瞭解防火牆規則，請參閱「使用虛擬私有雲防火牆規則」。
HTTP Proxy 設定有問題。
DNS 設定。

Ops Agent 會執行健康狀態檢查，偵測網路連線錯誤。如需連線錯誤的建議解決方法，請參閱健康狀態檢查說明文件。

瞭解「failed to flush chunk」錯誤訊息

從 Ops Agent 2.28.0 版開始，Ops Agent 會限制可用於儲存緩衝區區塊的磁碟空間量。如果無法將記錄資料傳送至 Cloud Logging API，Ops Agent 會建立緩衝區區塊。如未設定限制，這些區塊可能會耗用所有可用空間，導致 VM 上的其他服務中斷。如果網路中斷導致緩衝區區塊寫入磁碟，Ops Agent 會使用平台專屬的磁碟空間量儲存區塊。如果 VM 無法將緩衝區區塊傳送至 Cloud Logging API，Linux VM 的 /var/log/google-cloud-ops-agent/subagents/logging-module.log 或 Windows VM 的 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 也會顯示類似下列範例的訊息：

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

HTTP Proxy 問題

HTTP Proxy 設定有問題可能會產生錯誤。舉例來說，如果 flb_upstream 發生錯誤，且錯誤訊息中包含 context 這個字詞，表示 Proxy 設定有問題：

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

如要修正這個問題，請確認 HTTP Proxy 設定正確無誤。如需設定 HTTP Proxy 的操作說明，請參閱「設定 HTTP Proxy」。

如需 HTTP Proxy 格式規格，請參閱 Fluent Bit 官方手冊。

我只想收集指標或記錄，不想同時收集兩者

根據預設，作業套件代理程式會同時收集指標和記錄檔。如要停用指標或記錄的收集作業，請使用 Ops Agent config.yaml 檔案覆寫預設的 logging 或 metrics 服務，讓預設管道沒有接收器。詳情請參閱下列文章：

停用作業套件代理程式的子代理程式服務「記錄代理程式」或「監控代理程式」，會導致設定無效，因此不支援這項操作。

正在收集指標，但似乎發生錯誤

代理程式正在記錄「Exporting failed. 之後會再次嘗試」訊息

如果累積指標的第一個資料點遭到捨棄，您會看到「匯出失敗」的記錄項目。下列記錄檔無害，可以放心忽略：

  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"}

代理程式記錄「TimeSeries could not be written: Points must be written in order.」訊息

如果您已從舊版 Monitoring 代理程式升級至作業套件代理程式，且在寫入累計指標時看到下列錯誤訊息，請重新啟動 VM。作業套件代理程式和 Monitoring 代理程式計算累計指標的開始時間時，會採用不同的方式，因此可能會導致點數順序錯亂。重新啟動 VM 會重設啟動時間，並修正這個問題。

  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}

代理程式記錄「Token must be a short-lived token (60 minutes) and in a reasonable timeframe」(權杖必須是短期權杖 (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.

如要瞭解如何同步處理系統時鐘，請參閱「在 VM 上設定 NTP」。

代理程式會記錄「metrics receiver with type "nvml" is not supported」(不支援類型為「nvml」的指標接收器)

如果您使用 nvml 接收器收集 NVIDIA 管理程式庫 (NVML) GPU 指標 (agent.googleapis.com/gpu)，表示您使用的 Ops Agent 版本支援 NVML 指標的預先發布功能。Ops Agent 2.38.0 版已正式發布，支援這些指標。在正式版中，nvml 接收器執行的指標收集作業已併入 hostmetrics 接收器，且 nvml 接收器已移除。

如果您使用預先發布版 nvml 接收器，並在使用者指定的設定檔中覆寫預設的收集間隔，安裝 2.38.0 以上版本的 Ops Agent 後，就會看到「metrics receiver with type "nvml" is not supported」(不支援類型為「nvml」的指標接收器) 錯誤訊息。發生錯誤的原因是 nvml 接收器已不存在，但使用者指定的設定檔仍參照該接收器。

如要修正這個問題，請更新使用者指定的設定檔，改為在 hostmetrics 接收器上覆寫收集間隔。

缺少 GPU 指標

如果 Ops Agent 正在收集部分指標，但缺少部分或所有 NVIDIA 管理程式庫 (NVML) GPU (agent.googleapis.com/gpu) 指標，則可能是設定有問題，或是沒有任何程序使用 GPU。

如果沒有收集任何 GPU 指標，請檢查 GPU 驅動程式。如要收集 GPU 指標，Ops Agent 必須在 VM 上安裝及設定 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 指標。

部分指標缺漏或不一致

作業套件代理程式 2.0.0 以上版本處理少數指標的方式，與作業套件代理程式「預覽」版本 (2.0.0 以下版本) 或 Monitoring 代理程式不同。

下表說明 Ops Agent 和 Monitoring Agent 擷取資料的差異。

指標類型，省略 `agent.googleapis.com`	作業套件代理程式 (正式發行)^†	作業套件代理程式 (預先發布版)^†	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欄是指作業代理程式 2.0.0 以上版本。「預先發布」欄是指 2.0.0 以下的 Ops 代理程式版本。

Windows 專屬問題

下列各節僅適用於在 Windows 上執行的 Ops 代理程式。

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/ 包含下列類型的檔案：

緩衝區檔案：這些檔案是作業套件代理程式已追蹤及處理，但尚未擷取至 Cloud Logging 的緩衝記錄檔項目。如果出現損毀的區塊，Ops Agent 應在 2.15.0 以上版本中略過這些區塊。不過，在某些情況下，您可能需要手動清除。這些檔案會儲存在巢狀資料夾中，例如： /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"

重設但儲存緩衝區檔案

如果 VM 沒有緩衝區區塊損毀 (也就是 Ops Agent 的自我記錄檔中沒有 format check failed 訊息)，則重設代理程式狀態時，可以略過移除本機緩衝區的先前指令。

如果 VM 確實有緩衝區區塊損毀，您就必須移除這些區塊。以下選項說明處理緩衝區的不同方式。「完全重設代理程式狀態」一節中說明的其他步驟仍適用。

方法 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 版本中的已知問題。

作業代理程式 2.56.0 版無法傳送 Prometheus 指標

如果您搭配使用 Ops Agent 2.56.0 版和 Prometheus 接收器，且擷取目標發出的指標含有計數器的額外 *_created 指標 (支援新的實驗性建立時間戳記功能)，則代理程式可能無法寫入指標，並回報開始時間必須為正數的錯誤。記錄訊息類似於下列內容：

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

這是上游 OpenTelemetry 的問題。如要解決這個錯誤，請使用不受影響的 2.55.0 版，直到新版 Ops Agent 修正這個問題為止。如果您使用代理程式政策，也可以將版本固定為 2.55.0，避免升級。詳情請參閱「安裝特定版本的代理程式」。

作業套件代理程式 2.47.0、2.48.0 或 2.49.0 版發生當機迴圈

2.47.0、2.48.0 和 2.49.0 版納入了有問題的 FluentBit 元件，這個元件會在特定記錄行上失敗，導致 Ops Agent 進入當機迴圈。

作業套件代理程式 2.50.0 版已解決這個問題。

從 Ops Agent 2.46.0 版開始，Prometheus 指標命名空間除了執行個體 ID 外，還會包含執行個體名稱

從 2.46.0 版開始，作業套件代理程式會在以 Prometheus 擷取格式擷取指標時，將 VM 名稱納入 namespace 標籤。在舊版中，Prometheus 指標只會使用 VM 的執行個體 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 代理程式 2.39.0 版開始，Prometheus 無類型指標會變更指標類型

從 2.39.0 版開始，Ops Agent 支援擷取不明類型的 Prometheus 指標。在舊版中，Ops Agent 會將這些指標視為計量表，但從 2.39.0 版開始，無型別指標會同時視為計量表和計數器。因此，使用者現在可以對這些指標執行累計運算。

如果您使用 PromQL，將 Ops Agent 升級至 2.39.0 以上版本後，即可對未輸入的 Prometheus 指標套用累計作業。

Windows VM 的記憶體用量偏高 (2.27.0 至 2.29.0 版)

在 Windows 上，如果作業套件代理程式版本為 2.27.0 至 2.29.0，有時會發生導致代理程式洩漏通訊端的錯誤，進而增加記憶體用量，並導致 fluent-bit.exe 程序保留大量控制代碼。

如要解決這個問題，請將 Ops Agent 升級至 2.30.0 以上版本，然後重新啟動代理程式。

Windows 上的事件記錄時區有誤 (2.15.0 至 2.26.0 版)

如果您將 VM 的時區從世界標準時間改為其他時區，Cloud Logging 中 Windows 事件記錄的時間戳記可能不正確。作業套件代理程式 2.27.0 版已修正這個問題，但由於已知的 Windows 高記憶體問題，如果遇到這個問題，建議您至少升級至作業套件代理程式 2.30.0 版。如果無法升級，請嘗試下列其中一種解決方法。

使用世界標準時間時區

在 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 上將無法正確剖析。作業套件代理程式 2.27.0 版已修正這個問題，但由於已知的 Windows 高記憶體問題，如果遇到這個問題，建議您至少升級至作業套件代理程式 2.30.0 版。

舊版作業套件代理程式的已知問題

下列各節說明舊版 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 版和舊版)

如果 Ops Agent 版本低於 2.17.0，可能會因為緩衝區區塊損毀，導致 Linux VM 上的 /var/log/google-cloud-ops-agent/subagents/logging-module.log 檔案或 Windows VM 上的 C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log 檔案耗用大量 CPU、記憶體和磁碟空間。發生這種情況時，您會在 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 以上版本，並徹底重設代理程式狀態。

如果系統仍產生大量代理程式自我記錄，請考慮使用記錄檔輪替。詳情請參閱「設定記錄檔輪替」。

排解作業套件代理程式資料擷取問題 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

事前準備

Google Cloud 主控台顯示作業套件代理程式安裝作業停滯在「待處理」狀態

安裝失敗的常見原因

遙測傳輸失敗的常見原因

代理程式正在執行，但未擷取資料

代理程式是否將記錄檔傳送至 Cloud Logging？

管道錯誤

Linux

Windows

記錄剖析錯誤

Linux

Windows

查看當地指標

檢查記錄模組記錄

代理程式是否將指標傳送至 Cloud Monitoring？

查看指標模組記錄

網路連線問題

瞭解「failed to flush chunk」錯誤訊息

HTTP Proxy 問題

我只想收集指標或記錄，不想同時收集兩者

正在收集指標，但似乎發生錯誤

代理程式正在記錄「Exporting failed. 之後會再次嘗試」訊息

代理程式記錄「TimeSeries could not be written: Points must be written in order.」訊息

代理程式記錄「Token must be a short-lived token (60 minutes) and in a reasonable timeframe」(權杖必須是短期權杖 (60 分鐘)，且在合理時間範圍內) 訊息

代理程式會記錄「metrics receiver with type "nvml" is not supported」(不支援類型為「nvml」的指標接收器)

缺少 GPU 指標

部分指標缺漏或不一致

Windows 專屬問題

Windows 上的效能計數器損毀

徹底重設代理程式狀態

重設但儲存緩衝區檔案

近期發布的作業套件代理程式已知問題

作業代理程式 2.56.0 版無法傳送 Prometheus 指標

作業套件代理程式 2.47.0、2.48.0 或 2.49.0 版發生當機迴圈

從 Ops Agent 2.46.0 版開始，Prometheus 指標命名空間除了執行個體 ID 外，還會包含執行個體名稱

從 Ops 代理程式 2.39.0 版開始，Prometheus 無類型指標會變更指標類型

Windows VM 的記憶體用量偏高 (2.27.0 至 2.29.0 版)

Windows 上的事件記錄時區有誤 (2.15.0 至 2.26.0 版)

Windows 上剖析的時間戳記時區不正確 (2.27.0 之前的任何版本)

舊版作業套件代理程式的已知問題

無害記錄 (2.9.1 以下版本)

代理程式自我記錄檔耗用過多 CPU、記憶體和磁碟空間 (2.16.0 版和舊版)

排解作業套件代理程式資料擷取問題