疑難排解 Application Signals 安裝

本節包含 CloudWatch Application Signals 的疑難排解秘訣。

啟用 Application Signals 後，應用程式無法啟動。

如果在叢集上啟用 Application Signals 後，Amazon EKS 叢集上的應用程式並未啟動，請檢查下列事項：

• 檢查應用程式是否已由另一個監控解決方案進行檢測。Application Signals 可能不支援與其他檢測解決方案共存。

• 確認您的應用程式符合使用 Application Signals 的相容性要求。如需詳細資訊，請參閱Application Signals 支援的系統 。

• 如果您的應用程式無法提取 Application Signals 成品，例如 AWS Distro for OpenTelemetery Java 或 Python 代理程式和 CloudWatch 代理程式映像，這可能是網路問題。

若要緩解問題，請從instrumentation.opentelemetry.io/inject-python: "true"應用程式部署資訊清單中移除 instrumentation.opentelemetry.io/inject-java: "true"或 註釋，然後重新部署您的應用程式。然後檢查應用程式是否正常運作。

已知問題

Java SDK 1.32.5 版中的執行期指標集合已知無法使用 JBoss Wildfly 的應用程式。此問題延伸到 Amazon CloudWatch 可觀測性 EKS 附加元件，2.3.0-eksbuild.1透過 影響版本2.5.0-eksbuild.1。

如果您受到影響，請將環境變數新增至您的OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false應用程式，以降級版本或停用執行時間指標集合。

啟用 Application Signals 後，Python 應用程式不會啟動

缺少PYTHONPATH環境變數有時會導致應用程式無法啟動 ，這是 OpenTelemetry 自動儀器的已知問題。若要解決此問題，請確定您將PYTHONPATH環境變數設定為應用程式工作目錄的位置。如需此問題的詳細資訊，請參閱 PYTHONPATH 的 Python 自動檢測設定不符合 Python 的模組解析行為，進而破壞 Django 應用程式。

對於 Django 應用程式，還有其他必要的組態，如 OpenTelemetry Python 文件所述。

• 使用 --noreload旗標來防止自動重新載入。

• 將DJANGO_SETTINGS_MODULE環境變數設定為 Django 應用程式settings.py檔案的位置。這可確保 OpenTelemetry 可以正確存取 Django 設定並將其與您的 Django 設定整合。

使用 WSGI 伺服器的 Python 應用程式沒有 Application Signals 資料

如果您使用的是 Gunicorn 或 uWSGI 等 WSGI 伺服器，則必須進行其他變更，才能讓 ADOT Python 自動儀器運作。

注意

請確定您使用的是最新版本的 ADOT Python 和 Amazon CloudWatch 可觀測性 EKS 附加元件，然後再繼續。

使用 WSGI 伺服器啟用 Application Signals 的其他步驟

1. 在叉式工作者程序中匯入自動儀器。

   對於 Gunicorn，請使用post_fork勾點：

   # gunicorn.conf.py
   def post_fork(server, worker):
       from opentelemetry.instrumentation.auto_instrumentation import sitecustomize

   對於 uWSGI，請使用 import指令。

   #  uwsgi.ini
   [uwsgi]
   ; required for the instrumentation of worker processes
   enable-threads = true
   lazy-apps = true
   import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize

2. 啟用 ADOT Python 自動儀器的組態，以略過主要程序，並將OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED環境變數設定為 以延遲工作者true。

我的 Node.js 應用程式未進行檢測，或未產生 Application Signals 遙測

若要啟用 Node.js 的 Application Signals，您必須確保您的 Node.js 應用程式使用 CommonJS (CJS) 模組格式。目前， AWS Ditro for OpenTelemetry Node.js 不支援 ESM 模組格式，因為 OpenTelemetry JavaScript 對 ESM 的支援是實驗性的，並且是進行中的工作。

若要判斷您的應用程式是否使用 CJS 而非 ESM，請確定您的應用程式未滿足啟用 ESM 的條件。

Application Signals 儀表板中沒有應用程式資料

如果 Application Signals 儀表板中遺失指標或追蹤，則可能是如下原因。只有在上次更新後等待 Application Signals 收集並顯示資料 15 分鐘後，才會調查這些原因。

• 請確定您使用的程式庫和架構受到 ADOT Java 代理程式的支援。如需詳細資訊，請參閱程式庫/框架。

• 確認 CloudWatch 代理程式正在執行中。首先檢查 CloudWatch 代理程式 Pod 的狀態，並確定它們都處於 Running 狀態。

  kubectl -n amazon-cloudwatch get pods.

  將下列內容新增至 CloudWatch 代理程式組態檔案以啟用偵錯日誌，然後重新啟動代理程式。

  "agent": {
  
    "region": "${REGION}",
    "debug": true
  },

  然後檢查 CloudWatch 代理程式 Pod 中是否有錯誤。

• 檢查 CloudWatch 代理程式的組態問題。確認下列內容仍在 CloudWatch 代理程式組態檔案中，且新增代理程式後已重新啟動。

  "agent": {
    "region": "${REGION}",
    "debug": true
  },

  然後檢查 OpenTelemetry 偵錯日誌中的錯誤訊息，例如 ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ...。這些訊息可能表示有問題。

  如果不能解決問題，請透過使用 kubectl describe pod 命令描述 pod，轉儲並檢查名稱以 OTEL_ 開頭的環境變數。

• 若要啟用 OpenTelemetry Python 偵錯記錄，請將環境變數設定為 OTEL_PYTHON_LOG_LEVEL debug 並重新部署應用程式。

• 檢查從 CloudWatch 代理程式匯出資料的許可是否錯誤或不足。如果在 CloudWatch 代理程式日誌中看到 Access Denied 訊息，這可能是問題所在。這可能是因為安裝 CloudWatch 代理程式時套用的許可稍後被變更或撤銷。

• 產生遙測資料時，請檢查 AWS Distro for OpenTelemetry (ADOT) 問題。

  請確定檢測註解 instrumentation.opentelemetry.io/inject-java 和 sidecar.opentelemetry.io/inject-java 套用至應用程式部署，且值為 true。如果沒有這些註解，即使 ADOT 附加元件已正確安裝，也不會檢測應用程式 Pod。

  接下來，檢查 init 容器是否已套用於應用程式，並且 Ready 狀態為 True。如果 init 容器尚未就緒，請參閱原因狀態。

  如果問題仍然存在，請將環境變數設定為 OTEL_JAVAAGENT_DEBUG true 並重新部署應用程式，以在 OpenTelemetry Java 開發套件上啟用偵錯記錄。然後尋找以 ERROR io.telemetry 開頭的訊息。

• 指標/範圍匯出程式可能正在捨棄資料。要找出答案，請檢查應用程式日誌中包含 Failed to export... 的訊息

• 將指標或範圍傳送至 Application Signals 時，CloudWatch 代理程式可能會受到限制。檢查 CloudWatch 代理程式日誌中是否有指示限流的訊息。

• 請確定您已啟用服務探索設定。您只需要在區域中執行一次此操作。

  若要確認，請在 CloudWatch 主控台中選擇 Application Signals， Services。如果步驟 1 未標記為完成，請選擇開始探索您的服務。資料應該會在五分鐘內開始流入。

服務指標或相依性指標具有未知值

如果您在 Application Signals 儀表板中看到 UnknownService、 UnknownOperation、 UnknownRemoteService 或 UnknownRemoteOperation 的相依性名稱或操作，請檢查未知遠端服務和未知遠端操作的資料點是否與其部署同時發生。

• UnknownService 表示檢測應用程式的名稱未知。如果OTEL_SERVICE_NAME環境變數未定義service.name，且未在 中指定OTEL_RESOURCE_ATTRIBUTES，則服務名稱會設為 UnknownService。若要修正此問題，請在 OTEL_SERVICE_NAME或 中指定服務名稱OTEL_RESOURCE_ATTRIBUTES。

• UnknownOperation 表示調用操作的名稱未知。當 Application Signals 無法探索叫用遠端呼叫的操作名稱，或擷取的操作名稱包含高基數值時，就會發生這種情況。

• UnknownRemoteService 表示目的地服務的名稱未知。當系統無法擷取遠端呼叫存取的目的地服務名稱時，就會發生這種情況。

  其中一個解決方案是建立傳送請求的函數周圍的自訂跨度，並使用aws.remote.service指定的值新增 屬性。另一個選項是設定 CloudWatch 代理程式來自訂 的指標值RemoteService。如需 CloudWatch 代理程式中自訂的詳細資訊，請參閱 啟用 CloudWatch Application Signals。

• UnknownRemoteOperation 表示目的地操作的名稱未知。當系統無法擷取遠端呼叫存取的目的地操作名稱時，就會發生這種情況。

  其中一個解決方案是建立傳送請求的函數周圍的自訂跨度，並使用aws.remote.operation指定的值新增 屬性。另一個選項是設定 CloudWatch 代理程式來自訂 的指標值RemoteOperation。如需 CloudWatch 代理程式中自訂的詳細資訊，請參閱 啟用 CloudWatch Application Signals。

管理 Amazon CloudWatch Observability EKS 附加元件時處理 ConfigurationConflict

當您安裝或更新 Amazon CloudWatch Observability EKS 附加元件時，如果您注意到 ConfigurationConflict 類型的 Health Issue 導致的失敗，且其說明以 Conflicts found when trying to apply. Will not continue due to resolve conflicts mode 開頭，則很可能是因為您已經在叢集上安裝 CloudWatch 代理程式及其關聯元件，例如 ServiceAccount、ClusterRole 和 ClusterRoleBinding。當附加元件嘗試安裝 CloudWatch 代理程式及其相關元件時，如果偵測到內容有任何變更，則預設情況下，安裝或更新會失敗，以避免覆寫叢集上資源的狀態。

如果您嘗試上載 Amazon CloudWatch Observability EKS 附加元件，但發現此失敗，建議刪除先前安裝在叢集上的現有 CloudWatch 代理程式設定，然後再安裝 EKS 附加元件。請務必備份您對原始 CloudWatch 代理程式設定所做的任何自訂設定 (例如自訂代理程式組態)，並在下次安裝或更新附加元件時將這些自訂設定提供給 Amazon CloudWatch Observability EKS 附加元件。如果之前已安裝 CloudWatch 代理程式以登入 Container Insights，請參閱 刪除 CloudWatch 代理程式和 Fluent Bit for Container Insights 以取得詳細資訊。

或者，附加元件也支援衝突解決組態選項，該選項可指定 OVERWRITE。您可以使用此選項覆寫叢集上的衝突來繼續安裝或更新附加元件。如果您使用 Amazon EKS 主控台，則在建立或更新附加元件時選擇可選組態設定，可找到衝突解決方法。如果您使用的是 AWS CLI，您可以將 --resolve-conflicts OVERWRITE 提供給命令，以建立或更新附加元件。

我想要篩選掉不必要的指標和追蹤

如果 Application Signals 正在收集您不希望的追蹤和指標，請參閱 以取得有關使用自訂規則設定 CloudWatch 代理程式以降低基數管理高基數操作的資訊。

如需有關自訂追蹤取樣規則的資訊，請參閱 X-Ray 文件中的設定取樣規則。

什麼InternalOperation意思？

InternalOperation 是由應用程式內部觸發的操作，而不是由外部調用觸發的操作。InternalOperation 預期會看到正常運作的行為。

您會看到的一些典型範例InternalOperation包括以下內容：

• 啟動時預先載入 – 您的應用程式會執行名為 的操作loadDatafromDB，在暖機階段期間從資料庫讀取中繼資料。您會看到它歸類為 ，而不是觀察loadDatafromDB服務操作InternalOperation。

• 在背景中非同步執行 – 您的應用程式訂閱事件佇列，並在有更新時相應地處理串流資料。每個觸發的操作都會以服務操作InternalOperation的形式在 下。

• 從服務登錄檔擷取主機資訊 – 您的應用程式會與服務登錄檔進行通訊以探索服務。與探索系統的所有互動都會分類為 InternalOperation。

如何啟用 .NET 應用程式的日誌記錄？

若要啟用 .NET 應用程式的記錄，請設定下列環境變數。如需如何設定這些環境變數的詳細資訊，請參閱 OpenTelemetry 文件中的疑難排解 .NET 自動檢測問題。

• OTEL_LOG_LEVEL

• OTEL_DOTNET_AUTO_LOG_DIRECTORY

• COREHOST_TRACE

• COREHOST_TRACEFILE

如何解決 .NET 應用程式中的組件版本衝突？

如果您收到下列錯誤，請參閱 OpenTelemetry 文件中的組件版本衝突，以取得解決步驟。

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
   at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
   at Program.<Main>$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26

我可以停用 FluentBit 嗎？

您可以設定 Amazon CloudWatch 可觀測性 EKS 附加元件來停用 FluentBit。如需詳細資訊，請參閱(選用) 額外組態。

在匯出至 CloudWatch Logs 之前，我可以篩選容器日誌嗎？

否，尚未支援篩選容器日誌。