本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

設定 Application Signals

本節包含有關設定 CloudWatch Application Signals 的資訊。

追蹤取樣率

根據預設，當您啟用 Application Signals 時，會使用 reservoir=1/s 和 fixed_rate=5% 預設取樣率設定來啟用 X-Ray 集中取樣。 AWS Distro for OpenTelemetry (ADOT) SDK 代理程式的環境變數設定如下。

如需有關變更取樣組態的資訊，請參閱下列各項：

如果想要停用 X-Ray 集中式取樣並改用本機取樣，請為 ADOT SDK Java 代理程式設定如下所示的值。下列範例將取樣率設定為 5%。

如需有關更多進階取樣設定的資訊，請參閱 OTEL_TRACES_SAMPLER。

啟用追蹤至日誌關聯

您可以在 Application Signals 中啟用追蹤來記錄關聯性。這會自動將追蹤 IDs 和跨度 IDs 注入相關的應用程式日誌。然後，當您在 Application Signals 主控台中開啟追蹤詳細資訊頁面時，與目前追蹤相關聯的相關日誌項目 （如果有的話） 會自動顯示在頁面底部。

例如，假設您注意到延遲圖表中的峰值。您可以選擇圖形上的點，以載入該時間點的診斷資訊。然後，您可以選擇相關的追蹤以取得詳細資訊。當您檢視追蹤資訊時，您可以向下捲動以查看與追蹤相關聯的日誌。這些日誌可能會顯示與導致延遲尖峰的問題相關聯的模式或錯誤代碼。

為了實現追蹤日誌關聯，Application Signals 依賴下列項目：

所有這些干擾都由 OpenTelemetry 社群提供。Application Signals 使用它們將追蹤內容，例如追蹤 ID 和跨度 ID 注入應用程式日誌。若要啟用此功能，您必須手動變更記錄組態以啟用自動檢測。

視應用程式執行的架構而定，您可能還必須設定環境變數來啟用追蹤日誌關聯，以及遵循本節中的步驟。

在您啟用追蹤日誌關聯之後，

追蹤日誌關聯設定範例

本節包含在數個環境中設定追蹤日誌關聯的範例。

Java 的 Spring Boot

假設您在名為 的資料夾中有 Spring Boot 應用程式custom-app。應用程式組態通常是名為 的 YAML 檔案custom-app/src/main/resources/application.yml，看起來可能如下所示：

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...   

若要啟用追蹤日誌關聯，請新增下列記錄組態。

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...    

logging:
  pattern:
    level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

Java 的日誌傳回

在記錄組態 （例如 logback.xml) 中，將追蹤內容插入編碼器trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5ppattern的 。例如，下列組態會在日誌訊息之前加上追蹤內容。

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>app.log</file>
  <append>true</append>
  <encoder> 
    <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> 
  </encoder>
</appender>

如需 Logback 中編碼器的詳細資訊，請參閱 Logback 文件中的編碼器。

適用於 Java 的 Log4j2

在記錄組態 （例如 log4j2.xml) 中，將追蹤內容插入 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p PatternLayout。例如，下列組態會在日誌訊息之前加上追蹤內容。

<Appenders>
  <File name="FILE" fileName="app.log">
    <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>
  </File>
</Appenders>

如需 Log4j2 中模式配置的詳細資訊，請參閱 Log4j2 文件中的模式配置。

適用於 Java 的 Log4j

在記錄組態 （例如 log4j.xml) 中，將追蹤內容插入 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p PatternLayout。例如，下列組態會在日誌訊息之前加上追蹤內容。

<appender name="FILE" class="org.apache.log4j.FileAppender">;
  <param name="File" value="app.log"/>;
  <param name="Append" value="true"/>;
  <layout class="org.apache.log4j.PatternLayout">;
    <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>;
  </layout>;
</appender>;

如需 Log4j 中模式配置的詳細資訊，請參閱 Log4j 文件中的類別模式配置。

Python

執行應用程式true時，將環境變數設定為 OTEL_PYTHON_LOG_CORRELATION 。如需詳細資訊，請參閱 Python OpenTelemetry 文件中的啟用追蹤內容注入。

Node.js

如需在支援其之日誌程式庫的 Node.js 中啟用追蹤內容注入的詳細資訊，請參閱 Pino、Winston 或 Bunyan auto-intrumentations for Node.js 的 NPM 使用文件。

啟用指標以記錄關聯性

如果您將應用程式日誌發佈至 CloudWatch Logs 中的日誌群組，您可以在 Application Signals 中啟用指標與應用程式日誌的關聯。透過指標日誌關聯，Application Signals 主控台會自動顯示與指標相關聯的相關日誌群組。

例如，假設您注意到延遲圖表中的峰值。您可以在圖形上選擇一個點，以載入該時間點的診斷資訊。診斷資訊會顯示與目前服務和指標相關聯的相關應用程式日誌群組。然後，您可以選擇按鈕，在這些日誌群組上執行 CloudWatch Logs Insights 查詢。根據應用程式日誌中包含的資訊，這可能有助於您調查延遲尖峰的原因。

視應用程式執行的架構而定，您可能也必須設定環境變數，以啟用指標與應用程式日誌的關聯性。

管理高基數操作

Application Signals 包含 CloudWatch 代理程式中的設定，可用來管理操作的基數，以及管理指標匯出以最佳化成本。根據預設，當服務隨時間的不同操作數量超過預設閾值 500 時，指標限制函數會變成作用中。您可以調整組態設定來調整行為。

決定是否啟用指標限制

您可以使用下列方法來尋找是否發生預設指標限制。如果是，您應該考慮遵循下一節中的步驟來最佳化基數控制。

最佳化基數控制

若要最佳化基數控制，您可以執行下列動作：

建立自訂規則以彙總操作

高基數操作有時可能是因為從內容中擷取的不適當唯一值所造成。例如，在路徑中傳送包含使用者 IDs或工作階段 IDs HTTP/S 請求可能會導致數百個不同的操作。若要解決此類問題，建議您使用自訂規則來設定 CloudWatch 代理程式，以重寫這些操作。

如果透過個別RemoteOperation呼叫產生許多不同的指標，例如 PUT /api/customer/owners/123、 PUT /api/customer/owners/456和類似請求，我們建議您將這些操作合併到單一 RemoteOperation。其中一種方法是將所有以 開頭的RemoteOperation呼叫標準化PUT /api/customer/owners/為統一格式，特別是 PUT /api/customer/owners/{ownerId}。下列的範例示範了這一點。如需其他自訂規則的資訊，請參閱 啟用 CloudWatch Application Signals。

{
   "logs":{
      "metrics_collected":{
         "application_signals":{
            "rules":[
               {
                  "selectors":[
                     {
                        "dimension":"RemoteOperation",
                        "match":"PUT /api/customer/owners/*"
                     }
                  ],
                  "replacements":[
                     {
                        "target_dimension":"RemoteOperation",
                        "value":"PUT /api/customer/owners/{ownerId}"
                     }
                  ],
                  "action":"replace"
               }
            ]
         }
      }
   }
}

在其他情況下，高基數指標可能已彙總至 AllOtherRemoteOperations，而且可能不清楚包含哪些特定指標。CloudWatch 代理程式能夠記錄捨棄的操作。若要識別捨棄的操作，請使用下列範例中的 組態來啟用記錄，直到問題重新浮水印。然後檢查 CloudWatch 代理程式日誌 （可由容器stdout或 EC2 日誌檔案存取），並搜尋關鍵字 drop metric data。

{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}

建立指標限制政策

如果預設指標限制組態無法解決服務的基數，您可以自訂指標限制器組態。若要這樣做，請在 CloudWatch Agent 組態檔案中的 logs/metrics_collected/application_signals 區段limiter下新增區段。

下列範例會將指標限制的閾值從 500 個不同的指標降至 100 個。

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}