設定 Application Signals - Amazon CloudWatch

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

設定 Application Signals

本節包含設定 CloudWatch 應用程式訊號的相關資訊。

追蹤取樣率

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

環境變數 Value 注意

OTEL_TRACES_SAMPLER

xray

OTEL_TRACES_SAMPLER_ARG

endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000

CloudWatch 代理程式的端點

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

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

環境變數 Value

OTEL_TRACES_SAMPLER

parentbased_traceidratio

OTEL_TRACES_SAMPLER_ARG

0.05

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

啟用追蹤記錄關聯

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

例如,假設您注意到延遲圖形中有尖峰。您可以在圖形上選擇點來載入該時間點的診斷資訊。然後,您可以選擇相關跟踪以獲取更多信息。當您檢視追蹤資訊時,您可以向下捲動以查看與追蹤相關聯的記錄檔。這些記錄檔可能會顯示與造成延遲尖峰的問題相關聯的模式或錯誤碼。

為了實現跟踪日誌關聯,應用程序信號依賴於記錄器 MDC 自動檢測為 Java 和記 OpenTelemetry 錄檢測 Python。兩者都是由 OpenTelemetry 社區提供。應用程式 Signals 會使用此功能將追蹤內容 (例如追蹤 ID 和跨度 ID) 插入應用程式記錄檔。若要啟用此功能,您必須手動變更記錄組態以啟用自動檢測。

視應用程式執行的架構而定,除了遵循本節中的步驟之外,您可能還必須設定環境變數以啟用追蹤記錄關聯性。

啟用追蹤記錄關聯性之後,

追蹤記錄關聯設定範例

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

春季啟動

假設你有一個名為的文件夾中的 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 文件中的編碼器

爪哇的 Log4J2

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

<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.xml) 中,將追蹤內容插入trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5pPatternLayout。例如,下列組態會在記錄訊息之前加上追蹤內容。

<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 文件中的啟用追蹤內容插入

管理高基數作業

應用程式信號包括 CloudWatch 代理程式中的設定,您可以使用這些設定來管理作業的基數,以及管理指標匯出以最佳化成本。根據預設,當服務在一段時間內的不同作業數目超過預設臨界值 500 時,測量結果限制函數會變成作用中。您可以透過調整組態設定來調整行為。

判斷是否已啟動量度限制

您可以使用下列方法來判斷是否發生預設量度限制。如果是這樣,您應該考慮按照下一節中的步驟來優化基數控制。

  • 在 CloudWatch 主控台中,選擇應用程式訊號服務。如果您看到名為AllOtherOperations或具名的作業 AllOtherRemoteOperations,則會發生量度限制。RemoteOperation

  • 如果應用程式信號收集的任何度量具有其Operation維度的值AllOtherOperations,則會發生量度限制。

  • 如果應用程式信號收集的任何度量具有其RemoteOperation維度的值AllOtherRemoteOperations,則會發生量度限制。

優化基數控制

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

  • 建立自訂規則以彙總作業。

  • 設定您的指標限制原則。

建立自訂規則以彙總作業

高基數操作有時可能是由從上下文中提取的不適當唯一值引起的。例如,傳送在路徑中包含使用者 ID 或工作階段 ID 的 HTTP/S 要求可能會導致數百個不同的作業。若要解決此類問題,建議您使用自訂規則設定 CloudWatch 代理程式,以重新撰寫這些作業。

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

{ "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 代理程式組態檔案的logs/metrics_collected/application_signalslimiter段下新增區段。

下列範例會將量度限制的臨界值從 500 個不同的量度降低為 100。

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