Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Vorgänge mit hoher Kardinalität verwalten

Application Signals enthält Einstellungen im CloudWatch Agenten, mit denen Sie die Kardinalität Ihrer Abläufe und den Export von Metriken verwalten können, um die Kosten zu optimieren. Standardmäßig wird die Metrikbegrenzungsfunktion aktiv, wenn die Anzahl der unterschiedlichen Vorgänge für einen Service im Laufe der Zeit den Standardschwellenwert von 500 überschreitet. Sie können das Verhalten anpassen, indem Sie die Konfigurationseinstellungen anpassen.

Feststellen, ob die Metrikbegrenzung aktiviert ist

Sie können die folgenden Methoden verwenden, um herauszufinden, ob eine Standard-Metrikbegrenzung aktiv ist. Ist das der Fall, sollten Sie eine Optimierung der Kardinalitätskontrolle in Erwägung ziehen, indem Sie den Schritten im nächsten Abschnitt folgen.

Optimieren der Kardinalitätskontrolle

Um Ihre Kardinalitätskontrolle zu optimieren, können Sie Folgendes tun:

Erstellen Sie benutzerdefinierte Regeln, um Vorgänge zu aggregieren

High-cardinality Operationen können manchmal durch unangemessene Einzelwerte verursacht werden, die aus dem Kontext extrahiert wurden. Beispielsweise kann das Senden von HTTP/S Anfragen, die Benutzer-IDs oder Sitzungs-IDs im Pfad enthalten, zu Hunderten von unterschiedlichen Vorgängen führen. Um solche Probleme zu lösen, empfehlen wir, den CloudWatch Agenten mit Anpassungsregeln zu konfigurieren, um diese Vorgänge neu zu schreiben.

In Fällen, in denen es zu einem Anstieg der Generierung zahlreicher verschiedener Metriken durch einzelne RemoteOperation Anrufe, wie PUT /api/customer/owners/123PUT /api/customer/owners/456, und ähnliche Anfragen, kommt, empfiehlt Application Signals, diese Vorgänge in einer einzigen RemoteOperation zu konsolidieren. Ein Ansatz besteht insbesondere darin, alle RemoteOperation-Aufrufe, die mit PUT /api/customer/owners/ beginnen, auf ein einheitliches Format zu standardisieren, speziell PUT /api/customer/owners/{ownerId}. Das folgende Beispiel illustriert dies. Weitere Informationen zu anderen Anpassungsregeln finden Sie unter CloudWatch Anwendungssignale aktivieren.

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

In anderen Fällen wurden Metriken mit hoher Kardinalität möglicherweise zu AllOtherRemoteOperations aggregiert, und es ist möglicherweise unklar, welche spezifischen Metriken enthalten sind. Der CloudWatch Agent ist in der Lage, die unterbrochenen Operationen zu protokollieren. Um unterbrochene Vorgänge zu identifizieren, verwenden Sie die Konfiguration im folgenden Beispiel, um die Protokollierung zu aktivieren, bis das Problem erneut auftritt. Prüfen Sie dann die CloudWatch Agentenprotokolle (auf die über Container stdout - oder EC2-Protokolldateien zugegriffen werden kann) und suchen Sie nach dem Schlüsselwortdrop metric data.

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

Erstellen Sie Ihre Richtlinie zur Metrikbegrenzung

Wenn die Standardkonfiguration der Metrikbegrenzung die Kardinalität für Ihren Service nicht berücksichtigt, können Sie die Konfiguration des Metrik-Limiters anpassen. Fügen Sie dazu einen limiter Abschnitt unter dem logs/metrics_collected/application_signals Abschnitt in der CloudWatch Agent-Konfigurationsdatei hinzu.

Im folgenden Beispiel wird der Schwellenwert für die Metrikbegrenzung von 500 verschiedenen Metriken auf 100 gesenkt.

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