CloudWatch Application Signals aktivieren - Amazon CloudWatch

CloudWatch Application Signals aktivieren

Verwenden Sie CloudWatch Application Signals, um Ihre Anwendungen automatisch in AWS zu instrumentieren, sodass Sie die Anwendungsleistung anhand Ihrer Geschäftsziele verfolgen können. Application Signals bietet Ihnen eine einheitliche, anwendungsorientierte Ansicht Ihrer Java-Anwendungen, ihrer Abhängigkeiten und ihrer Edges. Weitere Informationen finden Sie unter Application Signals.

CloudWatch Application Signals nutzt den CloudWatch-Agenten, um Metriken und Traces von Ihren automatisch instrumentierten Anwendungen zu empfangen, optional Regeln anzuwenden, um die hohe Kardinalität zu reduzieren, und die verarbeitete Telemetrie dann in CloudWatch zu veröffentlichen. Mithilfe der Agenten-Konfigurationsdatei können Sie dem CloudWatch-Agenten eine benutzerdefinierte Konfiguration speziell für Application Signals bereitstellen. Zunächst gibt das Vorhandensein eines application_signals-Abschnitts unter dem metrics_collected-Abschnitt innerhalb des logs-Abschnitts der Agenten-Konfigurationsdatei an, dass der CloudWatch-Agent Metriken von Ihren automatisch instrumentierten Anwendungen empfängt. Auf ähnliche Weise gibt das Vorhandensein eines application_signals-Abschnitts unter dem traces_collected-Abschnitt innerhalb des traces-Abschnitts der Agenten-Konfigurationsdatei an, dass der CloudWatch-Agent für den Empfang von Traces von Ihren automatisch instrumentierten Anwendungen aktiviert ist. Darüber hinaus können Sie optional benutzerdefinierte Konfigurationsregeln angeben, um die Veröffentlichung von Telemetriedaten mit hoher Kardinalität zu reduzieren, wie in diesem Abschnitt beschrieben.

  • Wenn Sie das Add-On von Amazon CloudWatch Observability EKS für Amazon-EKS-Cluster installieren, ist der CloudWatch-Agent standardmäßig so aktiviert, dass er sowohl Metriken als auch Traces von Ihren automatisch instrumentierten Anwendungen empfängt. Wenn Sie optional benutzerdefinierte Konfigurationsregeln übergeben möchten, können Sie dies tun, indem Sie eine benutzerdefinierte Agentenkonfiguration an das Amazon-EKS-Add-On übergeben, wenn Sie es erstellen oder aktualisieren, indem Sie zusätzliche Konfigurationen verwenden, wie unter (Optional) Zusätzliche Konfiguration beschrieben.

  • Wenn Sie bei RedHat for OpenShift auf AWS (ROSA) den CloudWatch-Agent-Operator mithilfe von Helm-Charts installieren, ist der CloudWatch-Agent standardmäßig auch so aktiviert, dass er sowohl Metriken als auch Ablaufverfolgungen von Ihren automatisch instrumentierten Anwendungen empfängt. Wenn Sie optional benutzerdefinierte Konfigurationsregeln übergeben möchten, können Sie dazu eine benutzerdefinierte Agentenkonfiguration übergeben, indem Sie das Helm-Chart nutzen, wie unter (Optional) Zusätzliche Konfiguration beschrieben.

  • Für andere unterstützte Plattformen, einschließlich Amazon EC2, müssen Sie den CloudWatch-Agenten mit einer Agentenkonfiguration starten, die Application Signals aktiviert, indem Sie die application_signals-Abschnitte und optional alle benutzerdefinierten Konfigurationsregeln angeben, wie später in diesem Abschnitt beschrieben.

Im Folgenden finden Sie eine Übersicht über die Felder in der CloudWatch-Agent-Konfigurationsdatei, die sich auf CloudWatch Application Signals beziehen.

  • logs

    • metrics_collected – Dieses Feld kann Abschnitte enthalten, in denen angegeben wird, dass der Agent Protokolle erfassen soll, um Anwendungsfällen wie CloudWatch Application Signals und Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS zu versehen.

      Anmerkung

      Bisher wurde dieser Abschnitt auch verwendet, um anzugeben, dass der Agent Protokolle im eingebetteten Metrikformat sammeln soll. Diese Einstellungen werden nicht mehr benötigt.

      • application_signals (Optional) Gibt an, dass Sie CloudWatch Application Signals für den Empfang von Metriken von Ihren automatisch instrumentierten Anwendungen aktivieren möchten, um CloudWatch Application Signals zu unterstützen.

        • rules (Optional) Eine Reihe von Regeln zur bedingten Auswahl von Metriken und Traces und zur Anwendung von Aktionen für Szenarien mit hoher Kardinalität. Jede Regel kann die folgenden Felder enthalten:

          • rule_name (Optional) Der Name der Regel.

          • selectors (Optional) Eine Reihe von Metriken und Traces mit Dimensionsabgleichungen. Jede Auswahl muss folgende Felder angeben:

            • dimension Erforderlich, wenn selectors nicht leer ist. Dies gibt die Dimension der Metriken und Ablaufverfolgungen an, die als Filter verwendet werden sollen.

            • match Erforderlich, wenn selectors nicht leer ist. Ein Platzhaltermuster, das zum Abgleichen von Werten der angegebenen Dimension verwendet wird.

          • action (Optional) Die Aktion, die auf Metriken und Traces angewendet werden soll, die den angegebenen Selektoren entsprechen. Der Wert von action muss eines der folgenden Schlüsselwörter sein:

            • keep Gibt an, dass nur die Metriken und Traces an CloudWatch gesendet werden, wenn sie mit den selectors übereinstimmen.

            • drop Gibt an, dass die Metrik und die Traces, die dem selectors entsprechen, verworfen werden sollen.

            • replace Gibt an, dass die Dimensionen der Metriken und Traces, die dem selectors entsprechen, ersetzt werden sollen. Sie werden entsprechend dem replacements-Abschnitt ersetzt.

          • replacementsErforderlich, wenn action ein replace ist. Eine Reihe von Dimensions- und Wertepaaren, die auf Metriken und Traces angewendet werden, die mit den angegebenen selectors übereinstimmen, wenn die action gleich replace ist. Jeder Ersatz muss folgende Felder angeben:

            • target_dimension Erforderlich, wenn replacements nicht leer ist. Gibt die Dimension an, die ersetzt werden muss.

            • value Erforderlich, wenn replacements nicht leer ist. Der Wert, durch den der ursprüngliche Wert von target_dimension ersetzt werden soll.

        • limiter (Optional) Verwenden Sie diesen Abschnitt, um einzuschränken, wie viele Metriken und Dimensionen Application Signals an CloudWatch sendet, um Ihre Kosten zu optimieren.

          • disabled (Optional) Wenn true, ist das Feature zur Metrikbegrenzung deaktiviert. Der Standardwert ist false

          • drop_threshold (Optional) Die maximale Anzahl unterschiedlicher Metriken pro Service in einem Rotationsintervall, die von einem CloudWatch-Agenten exportiert werden können. Der Standardwert ist 500.

          • rotation_interval (Optional) Das Intervall, in dem der Begrenzer die Metrikdatensätze zur Differenzierung zurücksetzt. Dies wird als Zeichenfolge mit einer Zahlenfolge und einem Einheitensuffix ausgedrückt. Brüche werden unterstützt. Die unterstützten Einheitensuffixe sind s, m, h, ms, us und ns

            Der Standard ist 1h für 1 Stunde.

          • log_dropped_metrics (Optional) Gibt an, ob der Agent Protokolle in die CloudWatch-Agentenprotokolle schreiben soll, wenn Application Signals-Metriken gelöscht werden. Der Standardwert ist false.

            Anmerkung

            Um diese Protokollierung zu aktivieren, muss der Parameter debug im Abschnitt agent ebenfalls auf true gesetzt sein.

  • traces

    • traces_collected

      • application_signals Optional. Geben Sie dies an, damit der CloudWatch-Agent Traces von Ihren automatisch instrumentierten Anwendungen empfangen kann, um CloudWatch Application Signals zu unterstützen.

Anmerkung

Obwohl die benutzerdefinierten application_signals-Regeln in dem metrics_collected-Abschnitt angegeben sind, der im logs-Abschnitt enthalten ist, gelten sie auch implizit für den traces_collected-Abschnitt. Das gleiche Regelwerk gilt sowohl für Metriken als auch für Traces.

Wenn es mehrere Regeln mit unterschiedlichen Aktionen gibt, gelten sie in der folgenden Reihenfolge: keep, dann drop, dann replace.

Es folgt ein Beispiel einer vollständigen CloudWatch-Agenten-Konfigurationsdatei, die benutzerdefinierte Regeln anwendet.

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "rules": [
          {
            "rule_name": "keep01",
            "selectors": [
              {
                "dimension": "Service",
                "match": "pet-clinic-frontend"
              },
              {
                "dimension": "RemoteService",
                "match": "customers-service"
              }
            ],
            "action": "keep"
          },
          {
            "rule_name": "drop01",
            "selectors": [
              {
                "dimension": "Operation",
                "match": "GET /api/customer/owners/*"
              }
            ],
            "action": "drop"
          },
          {
            "rule_name": "replace01",
            "selectors": [
              {
                "dimension": "Operation",
                "match": "PUT /api/customer/owners/*/pets/*"
              },
              {
                "dimension": "RemoteOperation",
                "match": "PUT /owners"
              }
            ],
            "replacements": [
              {
                "target_dimension": "Operation",
                "value": "PUT /api/customer/owners/{ownerId}/pets{petId}"
              }
            ],
            "action": "replace"
          }
        ]
      }
    }
  },
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  }
}

In der vorherigen Beispiel-Konfigurationsdatei werden die rules wie folgt verarbeitet:

  1. Die Regel keep01 stellt sicher, dass alle Metriken und Traces mit der Dimension Service als pet-clinic-frontend und der Dimension RemoteService als customers-service beibehalten werden.

  2. Für die verarbeiteten Metriken und Traces nach der Anwendung von keep01 stellt die drop01-Regel sicher, dass Metriken und Traces mit der Dimension Operation als GET /api/customer/owners/* verworfen werden.

  3. Für die verarbeiteten Metriken und Traces nach der Anwendung von drop01 aktualisiert die replace01-Regel Metriken und Traces, die die Dimension Operation als PUT /api/customer/owners/*/pets/* und die Dimension RemoteOperation als PUT /owners haben, sodass ihre Operation-Dimension jetzt durch PUT /api/customer/owners/{ownerId}/pets{petId} ersetzt wurde.

Im Folgenden finden Sie ein vollständiges Beispiel für eine CloudWatch-Konfigurationsdatei, die die Kardinalität in Application Signals verwaltet, indem sie das Metriklimit auf 100 ändert, die Protokollierung gelöschter Metriken aktiviert und das Rotationsintervall auf zwei Stunden festlegt.

{
    "logs": {
        "metrics_collected": {
            "application_signals": {
                "limiter": {
                    "disabled": false,
                    "drop_threshold": 100,
                    "rotation_interval": "2h",
                    "log_dropped_metrics": true
                }
            }
        },
        "traces": {
            "traces_collected": {
                "application_signals": {}
            }
        }
    }
}