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.
# Nehmen Sie Metriken in Ihren Amazon Managed Service for Prometheus-Workspace auf
Metriken müssen in Ihren Amazon Managed Service for Prometheus-Workspace aufgenommen werden, bevor Sie diese Metriken abfragen oder Alerts darauf hinweisen können. In diesem Abschnitt wird erklärt, wie Sie die Erfassung von Metriken in Ihren Workspace einrichten können.
**Anmerkung**
In einen Workspace aufgenommene Metriken werden standardmäßig 150 Tage lang gespeichert und dann automatisch gelöscht. Du kannst die Aufbewahrungsdauer anpassen, indem du deinen Workspace auf maximal 1095 Tage (drei Jahre) konfigurierst. Weitere Informationen findest du unter [Konfiguriere deinen Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-workspace-configuration.html).
Es gibt zwei Methoden, um Metriken in Ihren Workspace in Amazon Managed Service für Prometheus zu erfassen.
+ **Verwendung eines AWS verwalteten Collectors** *— Amazon Managed Service for Prometheus bietet einen vollständig verwalteten, agentenlosen Scraper zum automatischen Scrapen von Metriken aus Ihren Amazon Elastic Kubernetes Service (Amazon EKS) -Clustern.* Scraping ruft die Metriken automatisch von Prometheus-kompatiblen Endpunkten ab.
+ **Verwendung eines vom Kunden verwalteten Kollektors** – Sie haben viele Möglichkeiten, Ihren eigenen Kollektor zu verwalten. Zwei der am häufigsten verwendeten Collectors sind die Installation Ihrer eigenen Instanz von Prometheus, die Ausführung im Agentenmodus oder die Verwendung von AWS Distro for. OpenTelemetry Diese beiden werden in den folgenden Abschnitten ausführlich beschrieben.
Kollektoren senden Metriken an Amazon Managed Service für Prometheus, indem die Remote-Write-Feature von Prometheus verwenden. Sie können Metriken direkt an Amazon Managed Service für Prometheus senden, indem Sie die Prometheus-Remote-Write-Feature in Ihrer eigenen Anwendung verwenden. Weitere Informationen zur direkten Verwendung von Remote-Write und Remote Write-Konfigurationen finden Sie unter [remote\$1write](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write) in der Prometheus-Dokumentation.
**Topics**
+ [Erfassen Sie Metriken mit AWS verwalteten Collectors](AMP-collector.md)
+ [Kundenverwaltete Kollektoren](self-managed-collectors.md)
# Erfassen Sie Metriken mit AWS verwalteten Collectors
Ein häufiger Anwendungsfall für Amazon Managed Service für Prometheus ist die Überwachung von Kubernetes-Clustern, die von Amazon Elastic Kubernetes Service (Amazon EKS) verwaltet werden. Kubernetes-Cluster und viele Anwendungen, die in Amazon EKS ausgeführt werden, exportieren ihre Metriken automatisch, damit Prometheus-kompatible Scraper darauf zugreifen können.
**Anmerkung**
Amazon EKS stellt API-Server-Metriken, `kube-controller-manager` -Metriken und `kube-scheduler` -Metriken in einem Cluster bereit. Viele andere Technologien und Anwendungen, die in Kubernetes-Umgebungen ausgeführt werden, bieten Promethus-kompatible Metriken. Eine vollständige Liste der verfügbaren Exporter finden Sie unter [Exporter und Integrationen](https://prometheus.io/docs/instrumenting/exporters/) in der Prometheus-Dokumentation.
Amazon Managed Service for Prometheus bietet einen vollständig verwalteten Scraper oder *Collector* ohne Agenten, der automatisch Promethus-kompatible Metriken erkennt und abruft. Sie müssen Agenten oder Scraper nicht verwalten, installieren, patchen oder warten. Ein Kollektor von Amazon Managed Service für Prometheus bietet eine zuverlässige, stabile, hochverfügbare und automatisch skalierte Erfassung von Metriken für Ihren Amazon-EKS-Cluster. Die von Amazon Managed Service for Prometheus verwalteten Collectoren arbeiten mit Amazon EKS-Clustern, einschließlich EC2 und Fargate.
Ein Sammler von Amazon Managed Service for Prometheus erstellt eine Elastic-Network-Schnittstelle (ENI) pro Subnetz, die bei der Erstellung des Scrapers angegeben wurde. Der Collector durchsucht diese ENIs Kennzahlen und leitet die Daten mithilfe eines `remote_write` VPC-Endpunkts an Ihren Amazon Managed Service for Prometheus-Workspace weiter. Diese erhobenen Daten werden niemals über das öffentliche Internet übertragen.
Die folgenden Themen enthalten weitere Informationen zur Verwendung eines Kollektors von Amazon Managed Service für Prometheus in Ihrem Amazon-EKS-Cluster und zu den gesammelten Metriken.
**Topics**
+ [Verwaltete Collectors für Amazon EKS einrichten](AMP-collector-how-to.md)
+ [Verwaltete Prometheus-Collectors für Amazon MSK einrichten](prom-msk-integration.md)
+ [Was sind Prometheus-kompatible Metriken?](prom-compatible-metrics.md)
+ [Überwachen Sie Sammler mit verkauften Baumstämmen](AMP-collector-vended-logs.md)
# Verwaltete Collectors für Amazon EKS einrichten
Um einen Amazon Managed Service for Prometheus-Collector zu verwenden, erstellen Sie einen Scraper, der Metriken in Ihrem Amazon EKS-Cluster erkennt und abruft. Sie können auch einen Scraper erstellen, der in Amazon Managed Streaming for Apache Kafka integriert ist. Weitere Informationen finden Sie unter [Amazon MSK integrieren](https://docs.aws.amazon.com/prometheus/latest/userguide/prom-msk-integration.html).
+ Sie können einen Scraper als Teil Ihrer Amazon-EKS-Cluster-Erstellung erstellen. Weitere Informationen zur Erstellung eines Amazon-EKS-Clusters, einschließlich der Erstellung eines Scrapers, finden Sie unter [Erstellen eines Amazon-EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im *Amazon-EKS-Benutzerhandbuch*.
+ Sie können Ihren eigenen Scraper programmgesteuert mit der AWS API oder mithilfe der erstellen. AWS CLI
Ein Kollektor von Amazon Managed Service für Prometheus erfasst Metriken, die mit Prometheus kompatibel sind. Weitere Informationen zu Prometheus-kompatiblen Metriken finden Sie unter [Was sind Prometheus-kompatible Metriken?](prom-compatible-metrics.md). Amazon EKS-Cluster stellen Metriken für den API-Server bereit. Amazon EKS-Cluster mit Kubernetes-Version `1.28` oder höher stellen auch Metriken für und bereit. `kube-scheduler` `kube-controller-manager` Weitere Informationen finden Sie unter [Rohmetriken der Kontrollebene im Prometheus-Format abrufen](https://docs.aws.amazon.com/eks/latest/userguide/view-raw-metrics.html#scheduler-controller-metrics) im *Amazon EKS-Benutzerhandbuch*.
**Anmerkung**
Beim Extrahieren von Metriken aus einem Cluster können Gebühren für die Netzwerknutzung anfallen. Eine Möglichkeit, diese Kosten zu optimieren, besteht darin, Ihren `/metrics` Endpunkt so zu konfigurieren, dass die bereitgestellten Metriken komprimiert werden (z. B. mit gzip), sodass weniger Daten über das Netzwerk übertragen werden müssen. Wie das geht, hängt von der Anwendung oder Bibliothek ab, die die Metriken bereitstellt. Manche Bibliotheken sind standardmäßig gzip.
In den folgenden Themen wird beschrieben, wie Sie Scraper erstellen, verwalten und konfigurieren.
**Topics**
+ [Einen Scraper erstellen](#AMP-collector-create)
+ [Ihren Amazon-EKS-Cluster konfigurieren](#AMP-collector-eks-setup)
+ [Suchen und Löschen von Scrapern](#AMP-collector-list-delete)
+ [Scraper-Konfiguration](#AMP-collector-configuration)
+ [Fehlerbehebung der Scraper-Konfiguration](#AMP-collector-troubleshoot)
+ [Scraper-Einschränkungen](#AMP-collector-limits)
## Einen Scraper erstellen
Ein Kollektor von Amazon Managed Service für Prometheus besteht aus einem Scraper, der Metriken aus einem Amazon-EKS-Cluster erkennt und sammelt. Amazon Managed Service für Prometheus verwaltet den Scraper für Sie und bietet Ihnen so die Skalierbarkeit, Sicherheit und Zuverlässigkeit, die Sie benötigen, ohne Instances, Agenten oder Scraper selbst verwalten zu müssen.
Es gibt drei Möglichkeiten, einen Scraper zu erstellen:
+ Ein Scraper wird automatisch für Sie erstellt, wenn Sie [über die Amazon EKS-Konsole einen Amazon EKS-Cluster erstellen](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) und sich dafür entscheiden, Prometheus-Metriken zu aktivieren.
+ Sie können von der Amazon EKS-Konsole aus einen Scraper für einen vorhandenen Cluster erstellen. Öffnen Sie den Cluster in der [Amazon EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters) und wählen Sie dann auf der Registerkarte **Observability** die Option **Scraper hinzufügen** aus.
Weitere Informationen zu den verfügbaren Einstellungen finden Sie [unter Prometheus-Metriken aktivieren](https://docs.aws.amazon.com/eks/latest/userguide/prometheus.html#turn-on-prometheus-metrics) im *Amazon EKS-Benutzerhandbuch*.
+ Sie können einen Scraper entweder mit der AWS API oder der erstellen. AWS CLI
Diese Optionen werden im folgenden Verfahren beschrieben.
Es gibt einige Voraussetzungen, um Ihren eigenen Scraper zu erstellen:
+ Sie haben einen Amazon-EKS-Cluster erstellt.
+ In Ihrem Amazon-EKS-Cluster muss die [Cluster-Endpunkt-Zugriffskontrolle](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) so eingestellt sein, dass sie privaten Zugriff beinhaltet. Er kann private und öffentliche Daten beinhalten, muss aber mindestens private Daten beinhalten.
+ In der Amazon VPC, in der sich der Amazon EKS-Cluster befindet, muss [DNS](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html) aktiviert sein.
**Anmerkung**
Der Cluster wird dem Scraper über seinen Amazon-Ressourcennamen (ARN) zugeordnet. Wenn Sie einen Cluster löschen und dann einen neuen mit demselben Namen erstellen, wird der ARN für den neuen Cluster wiederverwendet. Aus diesem Grund versucht der Scraper, Metriken für den neuen Cluster zu sammeln. Sie [löschen Scraper](#AMP-collector-list-delete) getrennt vom Löschen des Clusters.
------
#### [ AWS API ]
**So erstellen Sie einen Scraper unter Verwendung der AWS -API**
Verwenden Sie den `CreateScraper` API-Vorgang, um einen Scraper mit der AWS API zu erstellen. Im folgenden Beispiel wird ein Scraper in der `us-west-2` Region erstellt. Sie müssen die Workspace- AWS-Konto, Security- und Amazon EKS-Cluster-Informationen durch Ihre eigenen ersetzen und die Konfiguration angeben IDs, die für Ihren Scraper verwendet werden soll.
**Anmerkung**
Die Sicherheitsgruppe und die Subnetze sollten auf die Sicherheitsgruppe und die Subnetze für den Cluster eingestellt werden, zu dem Sie eine Verbindung herstellen.
Sie müssen mindestens zwei Subnetze in mindestens zwei Availability Zones einfügen.
Das `scrapeConfiguration` ist eine Prometheus-Konfigurations-YAML-Datei, die Base64-codiert ist. Sie können eine allgemeine Zweckkonfiguration mit der `GetDefaultScraperConfiguration`API-Operation herunterladen. Weitere Hinweise zum Format von finden Sie unter`scrapeConfiguration`. [Scraper-Konfiguration](#AMP-collector-configuration)
```
POST /scrapers HTTP/1.1
Content-Length: 415
Authorization: AUTHPARAMS
X-Amz-Date: 20201201T193725Z
User-Agent: aws-cli/1.18.147 Python/2.7.18 Linux/5.4.58-37.125.amzn2int.x86_64 botocore/1.18.6
{
"alias": "myScraper",
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:us-west-2:account-id:workspace/ws-workspace-id"
}
},
"source": {
"eksConfiguration": {
"clusterArn": "arn:aws:eks:us-west-2:account-id:cluster/cluster-name",
"securityGroupIds": ["sg-security-group-id"],
"subnetIds": ["subnet-subnet-id-1", "subnet-subnet-id-2"]
}
},
"scrapeConfiguration": {
"configurationBlob":
}
}
```
------
#### [ AWS CLI ]
**So erstellen Sie einen Scraper unter Verwendung der AWS CLI**
Verwenden Sie den `create-scraper` Befehl, um einen Scraper mit dem AWS CLI zu erstellen. Im folgenden Beispiel wird ein Scraper in der `us-west-2` Region erstellt. Sie müssen die Workspace- AWS-Konto, Security- und Amazon EKS-Cluster-Informationen durch Ihre eigenen ersetzen und die Konfiguration angeben IDs, die für Ihren Scraper verwendet werden soll.
**Anmerkung**
Die Sicherheitsgruppe und die Subnetze sollten auf die Sicherheitsgruppe und die Subnetze für den Cluster eingestellt werden, zu dem Sie eine Verbindung herstellen.
Sie müssen mindestens zwei Subnetze in mindestens zwei Availability Zones einfügen.
Das `scrape-configuration` ist eine Prometheus-Konfigurations-YAML-Datei, die Base64-codiert ist. Mit dem Befehl können Sie eine Allzweckkonfiguration herunterladen. `get-default-scraper-configuration` Weitere Informationen zum Format von finden Sie `scrape-configuration` unter[Scraper-Konfiguration](#AMP-collector-configuration).
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn='arn:aws:eks:us-west-2:account-id:cluster/cluster-name', securityGroupIds=['sg-security-group-id'],subnetIds=['subnet-subnet-id-1', 'subnet-subnet-id-2']}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration="{workspaceArn='arn:aws:aps:us-west-2:account-id:workspace/ws-workspace-id'}"
```
------
Im Folgenden finden Sie eine vollständige Liste der Scraper-Operationen, die Sie mit der AWS API verwenden können:
+ Erstellen Sie einen Scraper mit der [CreateScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_CreateScraper.html) API-Operation.
+ Listen Sie Ihre vorhandenen Scraper mit der [ListScrapers](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_ListScrapers.html) API-Operation auf.
+ Aktualisieren Sie den Alias, die Konfiguration oder das Ziel eines Scrapers mit der [UpdateScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html)API-Operation.
+ Löschen Sie einen Scraper mit der [DeleteScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html) API-Operation.
+ Erfahren Sie mehr über einen Scraper mit der [DescribeScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html) API-Operation.
+ Holen Sie sich eine allgemeine Zweckkonfiguration mit der [GetDefaultScraperConfiguration](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_GetDefaultScraperConfiguration.html)API-Operation.
**Anmerkung**
Der Amazon-EKS-Cluster, den Sie scrapen, muss so konfiguriert sein, dass Amazon Managed Service für Prometheus auf die Metriken zugreifen kann. Im nächsten Thema wird beschrieben, wie Sie Ihren Cluster konfigurieren.
### Kontoübergreifende Einrichtung
Gehen Sie wie folgt vor, um einen kontenübergreifenden Scraper zu erstellen, wenn sich Ihr Amazon EKS-Cluster und Amazon Managed Service for Prometheus Workspace in unterschiedlichen Konten befinden. Sie haben beispielsweise ein Quellkonto, das den Amazon EKS-Cluster `account_id_source` enthält, und ein Zielkonto, das den Amazon Managed Service for Prometheus Workspace `account_id_target` enthält.
**Um einen Scraper in einer kontoübergreifenden Konfiguration zu erstellen**
1. Erstellen Sie im Quellkonto eine Rolle `arn:aws:iam::account_id_source:role/Source` und fügen Sie die folgende Vertrauensrichtlinie hinzu.
```
{
"Effect": "Allow",
"Principal": {
"Service": [
"scraper.aps.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "scraper_ARN"
},
"StringEquals": {
"AWS:SourceAccount": "account_id"
}
}
}
```
1. Für jede Kombination aus Quelle (Amazon EKS-Cluster) und Ziel (Amazon Managed Service for Prometheus Workspace) müssen Sie eine Rolle erstellen `arn:aws:iam::account_id_target:role/Target` und die folgende Vertrauensrichtlinie mit Berechtigungen für hinzufügen. [AmazonPrometheusRemoteWriteAccess](https://docs.aws.amazon.com/prometheus/latest/userguide/security-iam-awsmanpol.html)
```
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account_id_source:role/Source"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "scraper_ARN"
}
}
}
```
1. Erstellen Sie einen Scraper mit der Option. `--role-configuration`
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn='arn:aws:eks:us-west-2:account-id_source:cluster/xarw,subnetIds=[subnet-subnet-id]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration="{workspaceArn='arn:aws:aps:us-west-2:account-id_target:workspace/ws-workspace-id'}"\
--role-configuration '{"sourceRoleArn":"arn:aws:iam::account-id_source:role/Source", "targetRoleArn":"arn:aws:iam::account-id_target:role/Target"}'
```
1. Bestätigen Sie die Erstellung des Scrapers.
```
aws amp list-scrapers
{
"scrapers": [
{
"scraperId": "scraper-id",
"arn": "arn:aws:aps:us-west-2:account_id_source:scraper/scraper-id",
"roleArn": "arn:aws:iam::account_id_source:role/aws-service-role/scraper.aps.amazonaws.com/AWSServiceRoleForAmazonPrometheusScraperInternal_cc319052-41a3-4",
"status": {
"statusCode": "ACTIVE"
},
"createdAt": "2024-10-29T16:37:58.789000+00:00",
"lastModifiedAt": "2024-10-29T16:55:17.085000+00:00",
"tags": {},
"source": {
"eksConfiguration": {
"clusterArn": "arn:aws:eks:us-west-2:account_id_source:cluster/xarw",
"securityGroupIds": [
"sg-security-group-id",
"sg-security-group-id"
],
"subnetIds": [
"subnet-subnet_id"
]
}
},
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:us-west-2:account_id_target:workspace/ws-workspace-id"
}
}
}
]
}
```
### Wechsel zwischen einer RoleConfiguration serviceverknüpften Rolle
Wenn Sie zurück zu einer serviceverknüpften Rolle wechseln möchten, anstatt in einen Amazon Managed Service for Prometheus Workspace `RoleConfiguration` zu schreiben, müssen Sie den aktualisieren `UpdateScraper` und einen Workspace im selben Konto wie der Scraper ohne die bereitstellen. `RoleConfiguration` Der `RoleConfiguration` wird aus dem Scraper entfernt und die Rolle, die mit dem Service verknüpft ist, wird verwendet.
Wenn Sie die Arbeitsbereiche in demselben Konto wie der Scraper ändern und den weiterhin verwenden möchten`RoleConfiguration`, müssen Sie erneut die Option On angeben. `RoleConfiguration` `UpdateScraper`
### Scraper für Workspaces erstellen, die mit vom Kunden verwalteten Schlüsseln aktiviert sind
Um einen Scraper für die Aufnahme von Metriken in einen Amazon Managed Service for Prometheus-Workspace mit vom [Kunden verwalteten Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) zu erstellen, verwenden Sie den, `--role-configuration` wobei sowohl die Quelle als auch das Ziel auf dasselbe Konto eingestellt sind.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn='arn:aws:eks:us-west-2:account-id:cluster/xarw,subnetIds=[subnet-subnet_id]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration="{workspaceArn='arn:aws:aps:us-west-2:account-id:workspace/ws-workspace-id'}"\
--role-configuration '{"sourceRoleArn":"arn:aws:iam::account_id:role/Source", "targetRoleArn":"arn:aws:iam::account_id:role/Target"}'
```
### Häufige Fehler beim Erstellen von Scrapern
Im Folgenden sind die häufigsten Probleme beim Versuch, einen neuen Scraper zu erstellen, aufgeführt.
+ Erforderliche AWS Ressourcen sind nicht vorhanden. Die angegebene *Sicherheitsgruppe*, die *Subnetze* und der *Amazon EKS-Cluster* müssen vorhanden sein.
+ Ungenügender IP-Adressraum. In jedem Subnetz, das Sie an die `CreateScraper` API übergeben, muss mindestens eine IP-Adresse verfügbar sein.
## Ihren Amazon-EKS-Cluster konfigurieren
Ihr Amazon-EKS-Cluster muss so konfiguriert sein, dass der Scraper auf Metriken zugreifen kann. Für diese Konfiguration gibt es zwei Optionen:
+ Verwenden Sie Amazon *EKS-Zugriffseinträge*, um Sammlern von Amazon Managed Service for Prometheus automatisch Zugriff auf Ihren Cluster zu gewähren.
+ Konfigurieren Sie Ihren Amazon EKS-Cluster manuell für verwaltetes Metrik-Scraping.
In den folgenden Themen werden die einzelnen Themen ausführlicher beschrieben.
### Amazon EKS für den Scraper-Zugriff mit Zugriffseinträgen konfigurieren
Die Verwendung von Zugriffseinträgen für Amazon EKS ist der einfachste Weg, Amazon Managed Service for Prometheus Zugriff auf Scrape-Metriken aus Ihrem Cluster zu gewähren.
Der Amazon EKS-Cluster, den Sie scrapen, muss so konfiguriert sein, dass er die API-Authentifizierung zulässt. Der Cluster-Authentifizierungsmodus muss entweder `API` auf oder eingestellt sein. `API_AND_CONFIG_MAP` Dies ist in der Amazon EKS-Konsole auf der Registerkarte **Zugriffskonfiguration** der Cluster-Details sichtbar. Weitere Informationen finden Sie unter [Erlauben des Zugriffs von IAM-Rollen oder Benutzern auf das Kubernetes-Objekt in Ihrem Amazon EKS-Cluster](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) im *Amazon EKS-Benutzerhandbuch*.
Sie können den Scraper bei der Erstellung des Clusters oder nach der Erstellung des Clusters erstellen:
+ **Beim Erstellen eines Clusters** — Sie können diesen Zugriff konfigurieren, wenn Sie [einen Amazon EKS-Cluster über die Amazon EKS-Konsole](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) erstellen (folgen Sie den Anweisungen, um einen Scraper als Teil des Clusters zu erstellen). Daraufhin wird automatisch eine Zugriffsrichtlinie erstellt, die Amazon Managed Service for Prometheus Zugriff auf die Cluster-Metriken gewährt.
+ **Hinzufügen nach der Erstellung eines Clusters** — Wenn Ihr Amazon EKS-Cluster bereits existiert, setzen Sie den Authentifizierungsmodus auf entweder `API` oder`API_AND_CONFIG_MAP`, und für alle Scraper, die Sie [über die Amazon Managed Service for Prometheus API oder CLI](#AMP-collector-create) oder über die Amazon EKS-Konsole erstellen, wird automatisch die richtige Zugriffsrichtlinie für Sie erstellt, und die Scraper haben Zugriff auf Ihren Cluster.
**Zugangsrichtlinie wurde erstellt**
Wenn Sie einen Scraper erstellen und Amazon Managed Service for Prometheus eine Zugriffsrichtlinie für Sie generieren lassen, generiert es die folgende Richtlinie. Weitere Informationen zu Zugriffseinträgen finden Sie unter [Erlauben des Zugriffs von IAM-Rollen oder Benutzern auf Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) im *Amazon EKS-Benutzerhandbuch*.
```
{
"rules": [
{
"effect": "allow",
"apiGroups": [
""
],
"resources": [
"nodes",
"nodes/proxy",
"nodes/metrics",
"services",
"endpoints",
"pods",
"ingresses",
"configmaps"
],
"verbs": [
"get",
"list",
"watch"
]
},
{
"effect": "allow",
"apiGroups": [
"extensions",
"networking.k8s.io"
],
"resources": [
"ingresses/status",
"ingresses"
],
"verbs": [
"get",
"list",
"watch"
]
},
{
"effect": "allow",
"apiGroups": [
"metrics.eks.amazonaws.com"
],
"resources": [
"kcm/metrics",
"ksh/metrics"
],
"verbs": [
"get"
]
},
{
"effect": "allow",
"nonResourceURLs": [
"/metrics"
],
"verbs": [
"get"
]
}
]
}
```
### Manuelles Konfigurieren von Amazon EKS für den Scraper-Zugriff
Wenn Sie es vorziehen, den `aws-auth ConfigMap` Zugriff auf Ihren Kubernetes-Cluster zu kontrollieren, können Sie Amazon Managed Service for Prometheus Scrapern trotzdem Zugriff auf Ihre Metriken gewähren. Mit den folgenden Schritten erhält Amazon Managed Service for Prometheus Zugriff auf Scrape-Metriken aus Ihrem Amazon EKS-Cluster.
**Anmerkung**
Weitere Informationen zu `ConfigMap` und zum Zugriff auf Einträge finden Sie unter [Erlauben des Zugriffs von IAM-Rollen oder Benutzern auf Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) im *Amazon EKS-Benutzerhandbuch*.
Dieses Verfahren verwendet `kubectl` und die AWS CLI. Informationen zum Installieren von `kubectl` finden Sie unter [Installieren von kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) im *Amazon-EKS-Benutzerhandbuch*.
**Um Ihren Amazon EKS-Cluster manuell für verwaltetes Metrik-Scraping zu konfigurieren**
1. Erstellen Sie eine Datei mit dem Namen `clusterrole-binding.yml` und dem folgenden Text:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: aps-collector-role
rules:
- apiGroups: [""]
resources: ["nodes", "nodes/proxy", "nodes/metrics", "services", "endpoints", "pods", "ingresses", "configmaps"]
verbs: ["describe", "get", "list", "watch"]
- apiGroups: ["extensions", "networking.k8s.io"]
resources: ["ingresses/status", "ingresses"]
verbs: ["describe", "get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
- apiGroups: ["metrics.eks.amazonaws.com"]
resources: ["kcm/metrics", "ksh/metrics"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: aps-collector-user-role-binding
subjects:
- kind: User
name: aps-collector-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: aps-collector-role
apiGroup: rbac.authorization.k8s.io
```
1. Führen Sie den folgenden Befehl in Ihrem Cluster aus:
```
kubectl apply -f clusterrole-binding.yml
```
Dadurch werden die Cluster-Rollenbindung und die Regel erstellt. In diesem Beispiel wird `aps-collector-role` als Rollenname und `aps-collector-user` als Benutzername verwendet.
1. Der folgende Befehl gibt Ihnen Informationen über den Scraper mit der ID. *scraper-id* Dies ist der Scraper, den Sie mit dem Befehl im vorherigen Abschnitt erstellt haben.
```
aws amp describe-scraper --scraper-id scraper-id
```
1. Suchen Sie in den Ergebnissen von `describe-scraper` den `roleArn`. Dieser hat das folgende Format:
```
arn:aws:iam::account-id:role/aws-service-role/scraper.aps.amazonaws.com/AWSServiceRoleForAmazonPrometheusScraper_unique-id
```
Amazon EKS benötigt ein anderes Format für diesen ARN. Sie müssen das Format des zurückgegebenen ARN anpassen, damit es im nächsten Schritt verwendet werden kann. Bearbeiten Sie es so, dass es diesem Format entspricht:
```
arn:aws:iam::account-id:role/AWSServiceRoleForAmazonPrometheusScraper_unique-id
```
Zum Beispiel diese ARN:
```
arn:aws:iam::111122223333:role/aws-service-role/scraper.aps.amazonaws.com/AWSServiceRoleForAmazonPrometheusScraper_1234abcd-56ef-7
```
Muss wie folgt umgeschrieben werden:
```
arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonPrometheusScraper_1234abcd-56ef-7
```
1. Führen Sie den folgenden Befehl in Ihrem Cluster aus, indem Sie den überarbeiteten `roleArn` aus dem vorherigen Schritt sowie Ihren Clusternamen und Ihre Region verwenden:
```
eksctl create iamidentitymapping --cluster cluster-name --region region-id --arn roleArn --username aps-collector-user
```
Dadurch kann der Scraper mit der Rolle und dem Benutzer, die Sie in der `clusterrole-binding.yml` Datei erstellt haben, auf den Cluster zugreifen.
## Suchen und Löschen von Scrapern
Sie können die AWS API oder die verwenden AWS CLI , um die Scraper in Ihrem Konto aufzulisten oder zu löschen.
**Anmerkung**
Stellen Sie sicher, dass Sie die neueste Version des AWS CLI oder SDK verwenden. Die neueste Version bietet Ihnen die neuesten Features und Funktionen sowie Sicherheitsupdates. Alternativ können Sie [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html), was immer eine up-to-date Befehlszeilenerfahrung bietet, automatisch verwenden.
Die [ListScrapers](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_ListScrapers.html)-API-Operation listet alle Scraper in Ihrem Konto auf.
Rufen Sie alternativ mit dem AWS CLI folgenden Befehl auf:
```
aws amp list-scrapers --region aws-region
```
`ListScrapers` gibt alle Scraper in Ihrem Konto zurück, zum Beispiel:
```
{
"scrapers": [
{
"scraperId": "s-1234abcd-56ef-7890-abcd-1234ef567890",
"arn": "arn:aws:aps:us-west-2:123456789012:scraper/s-1234abcd-56ef-7890-abcd-1234ef567890",
"roleArn": "arn:aws:iam::123456789012:role/aws-service-role/AWSServiceRoleForAmazonPrometheusScraper_1234abcd-2931",
"status": {
"statusCode": "DELETING"
},
"createdAt": "2023-10-12T15:22:19.014000-07:00",
"lastModifiedAt": "2023-10-12T15:55:43.487000-07:00",
"tags": {},
"source": {
"eksConfiguration": {
"clusterArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster",
"securityGroupIds": [
"sg-1234abcd5678ef90"
],
"subnetIds": [
"subnet-abcd1234ef567890",
"subnet-1234abcd5678ab90"
]
}
},
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:us-west-2:123456789012:workspace/ws-1234abcd-5678-ef90-ab12-cdef3456a78"
}
}
}
]
}
```
Suchen Sie zum Löschen eines Scrapers mithilfe der `ListScrapers`-Operation die `scraperId` für den Scraper, den Sie löschen möchten, und verwenden Sie dann die [DeleteScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html)-Operation, um ihn zu löschen.
Alternativ rufen Sie mit AWS CLI dem auf:
```
aws amp delete-scraper --scraper-id scraperId
```
## Scraper-Konfiguration
Mit einer Promethus-kompatiblen Scraper-Konfiguration können Sie steuern, wie Ihr Scraper Metriken erkennt und sammelt. Sie können beispielsweise das Intervall ändern, in dem Metriken an den Workspace gesendet werden. Sie können Umetikettierung auch verwenden, um die Etiketten einer Metrik dynamisch neu zu schreiben. Die Scraper-Konfiguration ist eine YAML-Datei, die Teil der Definition des Scrapers ist.
Wenn ein neuer Scraper erstellt wird, geben Sie eine Konfiguration an, indem Sie im API-Aufruf eine Base64-codierte YAML-Datei angeben. Sie können eine allgemeine Zweckkonfigurationsdatei mit dem `GetDefaultScraperConfiguration` Vorgang in der API für Amazon Managed Service für Prometheus herunterladen.
Um die Konfiguration eines Scrapers zu ändern, können Sie die `UpdateScraper` Operation verwenden. Wenn Sie die Quelle der Metriken aktualisieren müssen (z. B. auf einen anderen Amazon EKS-Cluster), müssen Sie den Scraper löschen und ihn mit der neuen Quelle neu erstellen.
**Unterstützte Konfiguration**
Informationen zum Scraper-Konfigurationsformat, einschließlich einer detaillierten Aufschlüsselung der möglichen Werte, finden Sie in der Prometheus-Dokumentation unter [Konfiguration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/). Die globalen Konfigurationsoptionen und `` Optionen beschreiben die am häufigsten benötigten Optionen.
Da Amazon EKS der einzige unterstützte Service ist, ist der einzige unterstützte Service Discovery config (`<*_sd_config>`) der``.
Die vollständige Liste der zulässigen Konfigurationsabschnitte:
+ ``
+ ``
+ ``
+ ``
+ ``
+ ``
Die Einschränkungen in diesen Abschnitten sind nach der Beispielkonfigurationsdatei aufgeführt.
**Beispielkonfigurationsdatei**
Im Folgenden finden Sie ein Beispiel für eine YAML-Konfigurationsdatei mit einem Scrape-Intervall von 30 Sekunden. Dieses Beispiel beinhaltet Unterstützung für die Kube-API-Servermetriken kube-controller-manager sowie für Kube-Scheduler-Metriken. Weitere Informationen finden Sie unter [Rohmetriken der Kontrollebene im Prometheus-Format abrufen](https://docs.aws.amazon.com/eks/latest/userguide/view-raw-metrics.html#scheduler-controller-metrics) im *Amazon EKS-Benutzerhandbuch*.
```
global:
scrape_interval: 30s
external_labels:
clusterArn: apiserver-test-2
scrape_configs:
- job_name: pod_exporter
kubernetes_sd_configs:
- role: pod
- job_name: cadvisor
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- replacement: kubernetes.default.svc:443
target_label: __address__
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
# apiserver metrics
- scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
job_name: kubernetes-apiservers
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- action: keep
regex: default;kubernetes;https
source_labels:
- __meta_kubernetes_namespace
- __meta_kubernetes_service_name
- __meta_kubernetes_endpoint_port_name
# kube proxy metrics
- job_name: kube-proxy
honor_labels: true
kubernetes_sd_configs:
- role: pod
relabel_configs:
- action: keep
source_labels:
- __meta_kubernetes_namespace
- __meta_kubernetes_pod_name
separator: '/'
regex: 'kube-system/kube-proxy.+'
- source_labels:
- __address__
action: replace
target_label: __address__
regex: (.+?)(\\:\\d+)?
replacement: $1:10249
# Scheduler metrics
- job_name: 'ksh-metrics'
kubernetes_sd_configs:
- role: endpoints
metrics_path: /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics
scheme: https
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels:
- __meta_kubernetes_namespace
- __meta_kubernetes_service_name
- __meta_kubernetes_endpoint_port_name
action: keep
regex: default;kubernetes;https
# Controller Manager metrics
- job_name: 'kcm-metrics'
kubernetes_sd_configs:
- role: endpoints
metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics
scheme: https
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels:
- __meta_kubernetes_namespace
- __meta_kubernetes_service_name
- __meta_kubernetes_endpoint_port_name
action: keep
regex: default;kubernetes;https
```
Die folgenden Einschränkungen gelten nur für verwaltete Collectoren: AWS
+ **Scrape-Intervall** – In der Scraper-Konfiguration kann kein Scrape-Intervall von weniger als 30 Sekunden angegeben werden.
+ **Ziele** – Ziele in der `static_config` müssen als IP-Adressen angegeben werden.
+ **DNS-Auflösung** — Bezogen auf den Zielnamen ist der einzige Servername, der in dieser Konfiguration erkannt wird, der Kubernetes-API-Server,. `kubernetes.default.svc` Alle anderen Maschinennamen müssen anhand der IP-Adresse angegeben werden.
+ **Autorisierung** — Lassen Sie diese Option aus, wenn keine Autorisierung erforderlich ist. Wenn sie benötigt wird, muss die Autorisierung vorhanden sein `Bearer` und auf die Datei `/var/run/secrets/kubernetes.io/serviceaccount/token` verweisen. Mit anderen Worten, wenn er verwendet wird, muss der Autorisierungsabschnitt wie folgt aussehen:
```
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
```
**Anmerkung**
`type: Bearer`ist die Standardeinstellung und kann daher weggelassen werden.
## Fehlerbehebung der Scraper-Konfiguration
Kollektoren von Amazon Managed Service für Prometheus entdecken und scrapen automatisch Metriken. Aber wie können Sie Fehler beheben, wenn Sie in Ihrem Workspace in Amazon Managed Service für Prometheus eine Metrik nicht sehen, die Sie erwarten würden?
**Wichtig**
Stellen Sie sicher, dass der private Zugriff für Ihren Amazon EKS-Cluster aktiviert ist. Weitere Informationen finden Sie unter [Cluster Private Endpoint](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#cluster-endpoint-private) im *Amazon EKS-Benutzerhandbuch*.
Die `up` Metrik ist ein hilfreiches Tool. Für jeden Endpunkt, den ein Kollektor von Amazon Managed Service für Prometheus erkennt, verkauft er diese Metrik automatisch. Es gibt drei Status dieser Metrik, die Ihnen helfen können, Fehler im Kollektor zu beheben.
+ `up` ist nicht vorhanden – Wenn für einen Endpunkt keine `up`-Metrik vorhanden ist, bedeutet das, dass der Kollektor den Endpunkt nicht finden konnte.
Wenn Sie sicher sind, dass der Endpunkt existiert, gibt es mehrere Gründe, warum der Collector ihn möglicherweise nicht finden kann.
+ Möglicherweise müssen Sie die Scrape-Konfiguration anpassen. Die Erkennung muss `relabel_config` möglicherweise angepasst werden.
+ Möglicherweise liegt ein Problem mit der für die Erkennung `role` verwendeten Datei vor.
+ In der vom Amazon EKS-Cluster verwendeten Amazon VPC ist [DNS möglicherweise nicht aktiviert](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html), sodass der Collector den Endpunkt nicht finden kann.
+ `up` ist vorhanden, aber immer 0 – Wenn `up` vorhanden, aber 0, dann kann der Kollektor den Endpunkt ermitteln, aber keine Prometheus-kompatiblen Metriken finden.
In diesem Fall könnten Sie versuchen, einen `curl` Befehl direkt für den Endpunkt zu verwenden. Sie können überprüfen, ob Sie die richtigen Angaben gemacht haben, z. B. das Protokoll (`http`oder`https`), den Endpunkt oder den Port, den Sie verwenden. Sie können auch überprüfen, ob der Endpunkt mit einer gültigen `200` Antwort antwortet und dem Prometheus-Format folgt. Schließlich darf der Hauptteil der Antwort nicht größer als die maximal zulässige Größe sein. (Informationen zu den Beschränkungen für AWS verwaltete Collectors finden Sie im folgenden Abschnitt.)
+ `up` ist vorhanden und größer als 0 – Wenn `up` vorhanden und größer als 0 ist, werden Metriken an Amazon Managed Service für Prometheus gesendet.
Stellen Sie sicher, dass Sie in Amazon Managed Service für Prometheus (oder Ihrem alternativen Dashboard, z. B. Amazon Managed Grafana) nach den richtigen Metriken suchen. Sie können curl erneut verwenden, um nach erwarteten Daten in Ihrem `/metrics` Endpunkt zu suchen. Vergewissern Sie sich auch, dass Sie andere Grenzwerte nicht überschritten haben, z. B. die Anzahl der Endpunkte pro Scraper. Sie können die Anzahl der Metriken-Endpunkte überprüfen, die gescrapt werden, indem Sie die Anzahl der `up` Metriken mithilfe von. `count(up)`
## Scraper-Einschränkungen
Die vollständig verwalteten Scraper, die von Amazon Managed Service für Prometheus bereitgestellt werden, unterliegen nur wenigen Einschränkungen.
+ **Region** – Ihr EKS-Cluster, Ihr Managed Scraper und Ihr Workspace in Amazon Managed Service für Prometheus müssen sich alle in derselben AWS -Region befinden.
+ **Kollektoren** – Sie können pro Region und Konto maximal 10 Scraper von Amazon Managed Service für Prometheus haben.
**Anmerkung**
Sie können eine Erhöhung dieses Limits anfordern, indem Sie [eine Erhöhung der Quote anfordern](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase).
+ **Antwort auf Metriken** – Der Hauptteil einer Antwort auf eine einzelne `/metrics`-Endpunktanfrage darf nicht mehr als 50 Megabyte (MB) umfassen.
+ **Endpunkte pro Scraper** – Ein Scraper kann maximal 30.000 Endpunkte scrapen.
+ **Scrape-Intervall** – In der Scraper-Konfiguration kann kein Scrape-Intervall von weniger als 30 Sekunden angegeben werden.
# Verwaltete Prometheus-Collectors für Amazon MSK einrichten
Um einen Amazon Managed Service for Prometheus Collector zu verwenden, erstellen Sie einen Scraper, der Metriken in Ihrem Amazon Managed Streaming for Apache Kafka Kafka-Cluster erkennt und abruft. Sie können auch einen Scraper erstellen, der in Amazon Elastic Kubernetes Service integriert ist. Weitere Informationen finden Sie unter [Integrieren von Amazon EKS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html).
## Einen Scraper erstellen
Ein Amazon Managed Service for Prometheus Collector besteht aus einem Scraper, der Metriken aus einem Amazon MSK-Cluster erkennt und sammelt. Amazon Managed Service für Prometheus verwaltet den Scraper für Sie und bietet Ihnen so die Skalierbarkeit, Sicherheit und Zuverlässigkeit, die Sie benötigen, ohne Instances, Agenten oder Scraper selbst verwalten zu müssen.
Sie können einen Scraper entweder mithilfe der AWS API oder AWS CLI wie in den folgenden Verfahren beschrieben erstellen.
Es gibt einige Voraussetzungen, um Ihren eigenen Scraper zu erstellen:
+ Sie müssen einen Amazon MSK-Cluster erstellt haben.
+ Konfigurieren Sie die Sicherheitsgruppe Ihres Amazon MSK-Clusters so, dass eingehender Datenverkehr auf den Ports **11001 (JMX Exporter) und **11002 (Node Exporter)**** innerhalb Ihrer Amazon VPC zugelassen wird, da der Scraper Zugriff auf diese DNS-Einträge benötigt, um Prometheus-Metriken zu sammeln.
+ [In der Amazon VPC, in der sich der Amazon MSK-Cluster befindet, muss DNS aktiviert sein.](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html)
**Anmerkung**
Der Cluster wird dem Scraper über seinen Amazon-Ressourcennamen (ARN) zugeordnet. Wenn Sie einen Cluster löschen und dann einen neuen mit demselben Namen erstellen, wird der ARN für den neuen Cluster wiederverwendet. Aus diesem Grund versucht der Scraper, Metriken für den neuen Cluster zu sammeln. Sie [löschen Scraper](#prom-msk-delete-scraper) getrennt vom Löschen des Clusters.
------
#### [ To create a scraper using the AWS API ]
Verwenden Sie den `CreateScraper` API-Vorgang, um einen Scraper mit der AWS API zu erstellen. Im folgenden Beispiel wird ein Scraper in der Region USA Ost (Nord-Virginia) erstellt. Ersetzen Sie den *example* Inhalt durch Ihre Amazon MSK-Clusterinformationen und geben Sie Ihre Scraper-Konfiguration an.
**Anmerkung**
Konfigurieren Sie die Sicherheitsgruppe und die Subnetze so, dass sie Ihrem Zielcluster entsprechen. Schließen Sie mindestens zwei Subnetze in zwei Availability Zones ein.
```
POST /scrapers HTTP/1.1
Content-Length: 415
Authorization: AUTHPARAMS
X-Amz-Date: 20201201T193725Z
User-Agent: aws-cli/1.18.147 Python/2.7.18 Linux/5.4.58-37.125.amzn2int.x86_64 botocore/1.18.6
{
"alias": "myScraper",
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:us-east-1:123456789012:workspace/ws-workspace-id"
}
},
"source": {
"vpcConfiguration": {
"securityGroupIds": ["sg-security-group-id"],
"subnetIds": ["subnet-subnet-id-1", "subnet-subnet-id-2"]
}
},
"scrapeConfiguration": {
"configurationBlob": base64-encoded-blob
}
}
```
In diesem Beispiel erfordert der `scrapeConfiguration` Parameter eine Base64-kodierte Prometheus-Konfigurations-YAML-Datei, die die DNS-Einträge des MSK-Clusters spezifiziert.
Jeder DNS-Eintrag steht für einen Broker-Endpunkt in einer bestimmten Availability Zone, sodass Clients Verbindungen zu Brokern herstellen können, die auf die von Ihnen ausgewählten Standorte verteilt sind, um eine hohe Verfügbarkeit zu gewährleisten. AZs
Die Anzahl der DNS-Einträge in Ihren MSK-Clustereigenschaften entspricht der Anzahl der Broker-Knoten und Availability Zones in Ihrer Clusterkonfiguration:
+ **Standardkonfiguration** — 3 Broker-Knoten mit 3 AZs = 3 DNS-Einträgen
+ **Benutzerdefinierte Konfiguration** — 2 Broker-Knoten mit 2 AZs = 2 DNS-Einträgen
[Um die DNS-Einträge für Ihren MSK-Cluster abzurufen, öffnen Sie die MSK-Konsole zu Hause? https://console.aws.amazon.com/msk/ region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/). Gehen Sie zu Ihrem MSK-Cluster. Wählen Sie **Properties**, **Brokers** und **Endpoints** aus.
Sie haben zwei Möglichkeiten, Prometheus so zu konfigurieren, dass Metriken aus Ihrem MSK-Cluster abgerufen werden:
1. **DNS-Auflösung auf Clusterebene (empfohlen)** — Verwenden Sie den DNS-Basisnamen des Clusters, um automatisch alle Broker zu ermitteln. Wenn Ihr Broker-Endpunkt dies ist`b-1.clusterName.xxx.xxx.xxx`, verwenden Sie `clusterName.xxx.xxx.xxx` ihn als DNS-Eintrag. Auf diese Weise kann Prometheus alle Broker im Cluster automatisch scrapen.
**Individuelle Broker-Endpunkte** — Geben Sie jeden Broker-Endpunkt einzeln an, um eine detaillierte Steuerung zu gewährleisten. Verwenden Sie die vollständigen Broker-IDs (b-1, b-2) in Ihrer Konfiguration. Beispiel:
```
dns_sd_configs:
- names:
- b-1.clusterName.xxx.xxx.xxx
- b-2.clusterName.xxx.xxx.xxx
- b-3.clusterName.xxx.xxx.xxx
```
**Anmerkung**
`clusterName.xxx.xxx.xxx`Ersetzen Sie in der Konsole durch Ihren tatsächlichen MSK-Cluster-Endpunkt. AWS
Weitere Informationen finden Sie[https://prometheus.io/docs/prometheus/latest/configuration/configuration/#dns_sd_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#dns_sd_config) in der *Prometheus-Dokumentation*.
Im Folgenden finden Sie ein Beispiel für die Scraper-Konfigurationsdatei:
```
global:
scrape_interval: 30s
external_labels:
clusterArn: msk-test-1
scrape_configs:
- job_name: msk-jmx
scheme: http
metrics_path: /metrics
scrape_timeout: 10s
dns_sd_configs:
- names:
- dns-record-1
- dns-record-2
- dns-record-3
type: A
port: 11001
relabel_configs:
- source_labels: [__meta_dns_name]
target_label: broker_dns
- source_labels: [__address__]
target_label: instance
regex: '(.*)'
replacement: '${1}'
- job_name: msk-node
scheme: http
metrics_path: /metrics
scrape_timeout: 10s
dns_sd_configs:
- names:
- dns-record-1
- dns-record-2
- dns-record-3
type: A
port: 11002
relabel_configs:
- source_labels: [__meta_dns_name]
target_label: broker_dns
- source_labels: [__address__]
target_label: instance
regex: '(.*)'
replacement: '${1}'
```
Führen Sie einen der folgenden Befehle aus, um die YAML-Datei in Base64 zu konvertieren. Sie können die Datei auch mit einem beliebigen Online-Base64-Konverter konvertieren.
**Example Linux/macOS**
```
echo -n scraper config updated with dns records | base64
```
**Example Windows PowerShell**
```
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes(scraper config updated with dns records))
```
------
#### [ To create a scraper using the AWS CLI ]
Verwenden Sie den `create-scraper` Befehl, um einen Scraper mit dem AWS Command Line Interface zu erstellen. Im folgenden Beispiel wird ein Scraper in der Region USA Ost (Nord-Virginia) erstellt. Ersetzen Sie den *example* Inhalt durch Ihre Amazon MSK-Clusterinformationen und geben Sie Ihre Scraper-Konfiguration an.
**Anmerkung**
Konfigurieren Sie die Sicherheitsgruppe und die Subnetze so, dass sie Ihrem Zielcluster entsprechen. Schließen Sie mindestens zwei Subnetze in zwei Availability Zones ein.
```
aws amp create-scraper \
--source vpcConfiguration="{securityGroupIds=['sg-security-group-id'],subnetIds=['subnet-subnet-id-1', 'subnet-subnet-id-2']}" \
--scrape-configuration configurationBlob=base64-encoded-blob \
--destination ampConfiguration="{workspaceArn='arn:aws:aps:us-west-2:123456789012:workspace/ws-workspace-id'}"
```
------
+ Im Folgenden finden Sie eine vollständige Liste der Scraper-Operationen, die Sie mit der AWS API verwenden können:
Erstellen Sie einen Scraper mit der [CreateScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_CreateScraper.html) API-Operation.
+ Listen Sie Ihre vorhandenen Scraper mit der [ListScrapers](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_ListScrapers.html) API-Operation auf.
+ Aktualisieren Sie den Alias, die Konfiguration oder das Ziel eines Scrapers mit der [UpdateScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html)API-Operation.
+ Löschen Sie einen Scraper mit der [DeleteScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html) API-Operation.
+ Erfahren Sie mehr über einen Scraper mit der [DescribeScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html) API-Operation.
## Kontoübergreifende Einrichtung
Gehen Sie wie folgt vor, um einen Scraper in einer kontoübergreifenden Konfiguration zu erstellen, wenn sich Ihr Amazon MSK-Cluster, aus dem Sie Metriken sammeln möchten, in einem anderen Konto befindet als der Amazon Managed Service for Prometheus-Collector.
Wenn Sie beispielsweise zwei Konten haben, das erste Quellkonto, auf `account_id_source` dem sich das Amazon MSK befindet, und ein zweites Zielkonto, in `account_id_target` dem sich der Amazon Managed Service for Prometheus Workspace befindet.
**Um einen Scraper in einer kontoübergreifenden Konfiguration zu erstellen**
1. Erstellen Sie im Quellkonto eine Rolle `arn:aws:iam::111122223333:role/Source` und fügen Sie die folgende Vertrauensrichtlinie hinzu.
```
{
"Effect": "Allow",
"Principal": {
"Service": [
"scraper.aps.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:aps:aws-region:111122223333:scraper/scraper-id"
},
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
}
```
1. Für jede Kombination aus Quelle (Amazon MSK-Cluster) und Ziel (Amazon Managed Service for Prometheus Workspace) müssen Sie eine Rolle erstellen `arn:aws:iam::444455556666:role/Target` und die folgende Vertrauensrichtlinie mit Berechtigungen für hinzufügen. [AmazonPrometheusRemoteWriteAccess](https://docs.aws.amazon.com/prometheus/latest/userguide/security-iam-awsmanpol.html)
```
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/Source"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "arn:aws:aps:aws-region:111122223333:scraper/scraper-id"
}
}
}
```
1. Erstellen Sie einen Scraper mit der Option. `--role-configuration`
```
aws amp create-scraper \ --source vpcConfiguration="{subnetIds=[subnet-subnet-id], "securityGroupIds": ["sg-security-group-id"]}" \ --scrape-configuration configurationBlob= \ --destination ampConfiguration="{workspaceArn='arn:aws:aps:aws-region:444455556666:workspace/ws-workspace-id'}"\ --role-configuration '{"sourceRoleArn":"arn:aws:iam::111122223333:role/Source", "targetRoleArn":"arn:aws:iam::444455556666:role/Target"}'
```
1. Bestätigen Sie die Erstellung des Scrapers.
```
aws amp list-scrapers
{
"scrapers": [
{
"scraperId": "s-example123456789abcdef0",
"arn": "arn:aws:aps:aws-region:111122223333:scraper/s-example123456789abcdef0": "arn:aws:iam::111122223333:role/Source",
"status": "ACTIVE",
"creationTime": "2025-10-27T18:45:00.000Z",
"lastModificationTime": "2025-10-27T18:50:00.000Z",
"tags": {},
"statusReason": "Scraper is running successfully",
"source": {
"vpcConfiguration": {
"subnetIds": ["subnet-subnet-id"],
"securityGroupIds": ["sg-security-group-id"]
}
},
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:aws-region:444455556666:workspace/ws-workspace-id'"
}
},
"scrapeConfiguration": {
"configurationBlob": ""
}
}
]
}
```
## Wechsel zwischen einer RoleConfiguration serviceverknüpften Rolle
Wenn Sie zurück zu einer serviceverknüpften Rolle wechseln möchten, anstatt in einen Amazon Managed Service for Prometheus Workspace `RoleConfiguration` zu schreiben, müssen Sie den aktualisieren `UpdateScraper` und einen Workspace im selben Konto wie der Scraper ohne die bereitstellen. `RoleConfiguration` Der `RoleConfiguration` wird aus dem Scraper entfernt und die Rolle, die mit dem Service verknüpft ist, wird verwendet.
Wenn Sie die Arbeitsbereiche in demselben Konto wie der Scraper ändern und den weiterhin verwenden möchten`RoleConfiguration`, müssen Sie erneut die Option On angeben. `RoleConfiguration` `UpdateScraper`
## Suchen und Löschen von Scrapern
Sie können die AWS API oder die verwenden AWS CLI , um die Scraper in Ihrem Konto aufzulisten oder zu löschen.
**Anmerkung**
Stellen Sie sicher, dass Sie die neueste Version des AWS CLI oder SDK verwenden. Die neueste Version bietet Ihnen die neuesten Features und Funktionen sowie Sicherheitsupdates. Alternativ können Sie [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html), was immer eine up-to-date Befehlszeilenerfahrung bietet, automatisch verwenden.
Die [ListScrapers](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_ListScrapers.html)-API-Operation listet alle Scraper in Ihrem Konto auf.
Rufen Sie alternativ mit dem AWS CLI folgenden Befehl auf:
```
aws amp list-scrapers
```
`ListScrapers` gibt alle Scraper in Ihrem Konto zurück, zum Beispiel:
```
{
"scrapers": [
{
"scraperId": "s-1234abcd-56ef-7890-abcd-1234ef567890",
"arn": "arn:aws:aps:aws-region:123456789012:scraper/s-1234abcd-56ef-7890-abcd-1234ef567890",
"roleArn": "arn:aws:iam::123456789012:role/aws-service-role/AWSServiceRoleForAmazonPrometheusScraper_1234abcd-2931",
"status": {
"statusCode": "DELETING"
},
"createdAt": "2023-10-12T15:22:19.014000-07:00",
"lastModifiedAt": "2023-10-12T15:55:43.487000-07:00",
"tags": {},
"source": {
"vpcConfiguration": {
"securityGroupIds": [
"sg-1234abcd5678ef90"
],
"subnetIds": [
"subnet-abcd1234ef567890",
"subnet-1234abcd5678ab90"
]
}
},
"destination": {
"ampConfiguration": {
"workspaceArn": "arn:aws:aps:aws-region:123456789012:workspace/ws-1234abcd-5678-ef90-ab12-cdef3456a78"
}
}
}
]
}
```
Suchen Sie zum Löschen eines Scrapers mithilfe der `ListScrapers`-Operation die `scraperId` für den Scraper, den Sie löschen möchten, und verwenden Sie dann die [DeleteScraper](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html)-Operation, um ihn zu löschen.
Alternativ rufen Sie mit AWS CLI dem auf:
```
aws amp delete-scraper --scraper-id scraperId
```
## Von Amazon MSK gesammelte Metriken
Bei der Integration mit Amazon MSK erfasst der Amazon Managed Service for Prometheus Collector automatisch die folgenden Metriken:
### Metriken: jmx\$1exporter- und pod\$1exporter-Jobs
| Metrik | Beschreibung/Zweck |
| --- | --- |
| jmx\$1config\$1reload\$1failure\$1total | Gesamtzahl der Fehler, mit denen der JMX-Exporter seine Konfigurationsdatei neu laden konnte. |
| jmx\$1scrape\$1duration\$1seconds | Zeitaufwand für das Scraping von JMX-Metriken in Sekunden für den aktuellen Erfassungszyklus. |
| jmx\$1scrape\$1error | Gibt an, ob beim Scraping von JMX-Metriken ein Fehler aufgetreten ist (1 = Fehler, 0 = Erfolg). |
| HeapMemoryUsageJava\$1lang\$1Memory\$1 \$1used | Menge des aktuell von der JVM verwendeten Heap-Speichers (in Byte). |
| java\$1lang\$1Memory\$1 \$1max HeapMemoryUsage | Maximale Menge an Heap-Speicher (in Byte), die für die Speicherverwaltung verwendet werden kann. |
| Java\$1lang\$1Memory\$1 \$1verwendet NonHeapMemoryUsage | Menge des Non-Heap-Speichers (in Byte), der derzeit von der JVM verwendet wird. |
| KAFKA\$1Cluster\$1Partition\$1Value | Aktueller Status oder Wert in Bezug auf Kafka-Cluster-Partitionen, aufgeschlüsselt nach Partitions-ID und Thema. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1assigned\$1partitions | Anzahl der Partitionen, die diesem Verbraucher derzeit zugewiesen sind. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1commit\$1latency\$1avg | Durchschnittliche Zeit in Millisekunden für die Übertragung von Offsets. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1commit\$1rate | Anzahl der Offset-Commits pro Sekunde. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1failed\$1rebalance\$1total | Gesamtzahl der fehlgeschlagenen Neugewichte bei Verbrauchergruppen. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1last\$1heartbeat\$1seconds\$1ago | Anzahl der Sekunden, seit der letzte Heartbeat an den Koordinator gesendet wurde. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1rebalance\$1latency\$1avg | Durchschnittliche Zeit, die für die Neugewichtung von Verbrauchergruppen benötigt wird, in Millisekunden. |
| kafka\$1consumer\$1consumer\$1coordinator\$1metrics\$1rebalance\$1total | Gesamtzahl der Neugewichte bei Verbrauchergruppen. |
| kafka\$1consumer\$1consumer\$1fetch\$1manager\$1metrics\$1bytes\$1consumed\$1rate | Durchschnittliche Anzahl der vom Verbraucher pro Sekunde verbrauchten Byte. |
| kafka\$1consumer\$1consumer\$1fetch\$1manager\$1metrics\$1fetch\$1latency\$1avg | Durchschnittliche Dauer einer Abrufanforderung in Millisekunden. |
| kafka\$1consumer\$1consumer\$1fetch\$1manager\$1metrics\$1fetch\$1rate | Anzahl der Abrufanforderungen pro Sekunde. |
| kafka\$1consumer\$1consumer\$1fetch\$1manager\$1metrics\$1records\$1consumed\$1rate | Durchschnittliche Anzahl verbrauchter Datensätze pro Sekunde. |
| kafka\$1consumer\$1consumer\$1fetch\$1manager\$1metrics\$1records\$1lag\$1max | Maximale Verzögerung in Bezug auf die Anzahl der Datensätze für jede Partition in diesem Consumer. |
| kafka\$1consumer\$1consumer\$1metrics\$1connection\$1count | Aktuelle Anzahl aktiver Verbindungen. |
| kafka\$1consumer\$1metrics\$1incoming\$1byte\$1rate | Durchschnittliche Anzahl der pro Sekunde von allen Servern empfangenen Byte. |
| kafka\$1consumer\$1consumer\$1metrics\$1last\$1poll\$1seconds\$1ago | Anzahl der Sekunden seit dem letzten Aufruf von consumer poll (). |
| kafka\$1consumer\$1consumer\$1metrics\$1request\$1rate | Anzahl der pro Sekunde gesendeten Anfragen. |
| kafka\$1consumer\$1consumer\$1metrics\$1response\$1rate | Anzahl der pro Sekunde eingegangenen Antworten. |
| kafka\$1consumer\$1group\$1 \$1Value ConsumerLagMetrics | Aktueller Wert für eine Verbrauchergruppe, der angibt, wie weit der Verbraucher hinterherhinkt. |
| KafkaControllerkafka\$1controller\$1 \$1Value | Aktueller Status oder Wert des Kafka-Controllers (1 = aktiver Controller, 0 = nicht aktiv). |
| ControllerEventManagerkafka\$1controller\$1 \$1Count | Gesamtzahl der verarbeiteten Controller-Ereignisse. |
| ControllerEventManagerkafka\$1controller\$1 \$1Mean | Durchschnittliche (durchschnittliche) Zeit, die zur Verarbeitung von Controller-Ereignissen benötigt wird. |
| ControllerStatskafka\$1controller\$1 \$1 MeanRate | Durchschnittliche Rate der Controller-Statistikoperationen pro Sekunde. |
| kafka\$1coordinator\$1group\$1 \$1Value GroupMetadataManager | Aktueller Status oder Wert des Gruppenmetadaten-Managers für Nutzergruppen. |
| kafka\$1log\$1 \$1Anzahl LogFlushStats | Gesamtzahl der Log-Flush-Operationen. |
| kafka\$1log\$1 LogFlushStats \$1Mean | Durchschnittliche (durchschnittliche) Zeit, die für Log-Flush-Operationen benötigt wird. |
| kafka\$1log\$1 \$1 LogFlushStats MeanRate | Durchschnittliche Rate der Log-Flush-Operationen pro Sekunde. |
| kafka\$1network\$1 \$1Anzahl RequestMetrics | Gesamtzahl der verarbeiteten Netzwerkanfragen. |
| kafka\$1network\$1 RequestMetrics \$1Mean | Durchschnittliche (durchschnittliche) Zeit für die Bearbeitung von Netzwerkanfragen. |
| kafka\$1network\$1 \$1 RequestMetrics MeanRate | Durchschnittliche Rate von Netzwerkanfragen pro Sekunde. |
| Kafka\$1Network\$1Acceptor\$1 MeanRate | Durchschnittliche Rate der akzeptierten Verbindungen pro Sekunde. |
| KAFKA\$1Server\$1Fetch\$1Queue\$1Size | Aktuelle Größe der Warteschlange für Abrufanforderungen. |
| Kafka\$1Server\$1Produce\$1Queue\$1Size | Aktuelle Größe der Warteschlange für Produktionsanfragen. |
| Kafka\$1Server\$1Request\$1Queue\$1Size | Aktuelle Größe der allgemeinen Anforderungswarteschlange. |
| kafka\$1server\$1 \$1Anzahl BrokerTopicMetrics | Gesamtzahl der Broker-Thema-Operationen (Nachrichten). in/out, bytes in/out |
| kafka\$1server\$1 \$1 BrokerTopicMetrics MeanRate | Durchschnittliche Rate der Broker-Thema-Operationen pro Sekunde. |
| kafka\$1server\$1 \$1 BrokerTopicMetrics OneMinuteRate | Gleitender Durchschnittskurs der Transaktionen im Broker-Thema von einer Minute. |
| kafka\$1server\$1 \$1Wert DelayedOperationPurgatory | Aktuelle Anzahl verzögerter Operationen im Fegefeuer (die darauf warten, abgeschlossen zu werden). |
| kafka\$1server\$1 \$1 DelayedFetchMetrics MeanRate | Durchschnittliche Rate verzögerter Abrufvorgänge pro Sekunde. |
| kafka\$1server\$1 \$1Wert FetcherLagMetrics | Aktueller Verzögerungswert für Replikat-Fetcher-Threads (wie weit hinter dem Leader zurückgeblieben). |
| kafka\$1server\$1 \$1 FetcherStats MeanRate | Durchschnittliche Rate von Abruf-Vorgängen pro Sekunde. |
| kafka\$1server\$1 \$1Wert ReplicaManager | Aktueller Status oder Wert des Replikat-Managers. |
| kafka\$1server\$1 \$1 ReplicaManager MeanRate | Durchschnittliche Rate von Replica Manager-Vorgängen pro Sekunde. |
| kafka\$1server\$1 \$1byte\$1rate LeaderReplication | Rate der pro Sekunde replizierten Byte für Partitionen, bei denen dieser Broker führend ist. |
| kafka\$1server\$1group\$1coordinator\$1metrics\$1group\$1completed\$1rebalance\$1count | Gesamtzahl der abgeschlossenen Neugewichte bei Verbrauchergruppen. |
| kafka\$1server\$1group\$1coordinator\$1metrics\$1offset\$1commit\$1count | Gesamtzahl der Offset-Commit-Operationen. |
| kafka\$1server\$1group\$1coordinator\$1metrics\$1offset\$1commit\$1rate | Rate der Offset-Commit-Operationen pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1connection\$1count | Aktuelle Anzahl aktiver Verbindungen. |
| kafka\$1server\$1socket\$1server\$1metrics\$1connection\$1creation\$1rate | Rate der Erstellung neuer Verbindungen pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1connection\$1close\$1rate | Rate der Verbindungsabbrüche pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1failed\$1authentication\$1total | Gesamtzahl der fehlgeschlagenen Authentifizierungsversuche. |
| kafka\$1server\$1socket\$1server\$1metrics\$1incoming\$1byte\$1rate | Rate der eingehenden Byte pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1outgoing\$1byte\$1rate | Rate der ausgehenden Byte pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1request\$1rate | Rate der Anfragen pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1response\$1rate | Rate der Antworten pro Sekunde. |
| kafka\$1server\$1socket\$1server\$1metrics\$1network\$1io\$1rate | Rate der Netzwerkoperationen pro Sekunde. I/O |
| kafka\$1server\$1socket\$1server\$1metrics\$1io\$1ratio | Bruchteil der für Operationen aufgewendeten Zeit. I/O |
| kafka\$1server\$1controller\$1channel\$1metrics\$1connection\$1count | Aktuelle Anzahl aktiver Verbindungen für Controller-Kanäle. |
| kafka\$1server\$1controller\$1channel\$1metrics\$1incoming\$1byte\$1rate | Rate der eingehenden Byte pro Sekunde für Controllerkanäle. |
| kafka\$1server\$1controller\$1channel\$1metrics\$1outgoing\$1byte\$1rate | Rate der ausgehenden Byte pro Sekunde für Controllerkanäle. |
| kafka\$1server\$1controller\$1channel\$1metrics\$1request\$1rate | Rate der Anfragen pro Sekunde für Controllerkanäle. |
| kafka\$1server\$1replica\$1fetcher\$1metrics\$1connection\$1count | Aktuelle Anzahl aktiver Verbindungen für den Replica Fetcher. |
| kafka\$1server\$1replica\$1fetcher\$1metrics\$1incoming\$1byte\$1rate | Rate der eingehenden Byte pro Sekunde für den Replikat-Fetcher. |
| kafka\$1server\$1replica\$1fetcher\$1metrics\$1request\$1rate | Rate der Anfragen pro Sekunde für den Replica Fetcher. |
| kafka\$1server\$1replica\$1fetcher\$1metrics\$1failed\$1authentication\$1total | Gesamtzahl der fehlgeschlagenen Authentifizierungsversuche für den Replica Fetcher. |
| kafka\$1server\$1 \$1Anzahl ZooKeeperClientMetrics | Gesamtzahl der Client-Operationen. ZooKeeper |
| kafka\$1server\$1 ZooKeeperClientMetrics \$1Mean | Mittlere Latenz der Client-Operationen. ZooKeeper |
| kafka\$1server\$1 \$1Wert KafkaServer | Aktueller Status oder Wert des Kafka-Servers (zeigt normalerweise an, dass der Server läuft). |
| node\$1cpu\$1seconds\$1total | Gesamtzahl der in jedem Modus (Benutzer, System, Leerlauf usw.) CPUs verbrachten Sekunden, aufgeschlüsselt nach CPU und Modus. |
| node\$1disk\$1read\$1bytes\$1total | Gesamtzahl der erfolgreich von Festplatten gelesenen Byte, aufgeschlüsselt nach Geräten. |
| node\$1disk\$1reads\$1completed\$1total | Gesamtzahl der erfolgreich abgeschlossenen Lesevorgänge für Festplatten, aufgeschlüsselt nach Geräten. |
| node\$1disk\$1writes\$1completed\$1total | Gesamtzahl der erfolgreich abgeschlossenen Schreibvorgänge für Festplatten, aufgeschlüsselt nach Geräten. |
| node\$1disk\$1written\$1bytes\$1total | Gesamtzahl der erfolgreich auf Festplatten geschriebenen Byte, aufgeschlüsselt nach Geräten. |
| node\$1filesystem\$1avail\$1bytes | Verfügbarer Dateisystemspeicher in Byte für Benutzer ohne Root-Rechte, aufgeschlüsselt nach Gerät und Einhängepunkt. |
| node\$1filesystem\$1size\$1bytes | Gesamtgröße des Dateisystems in Byte, aufgeschlüsselt nach Gerät und Einhängepunkt. |
| node\$1filesystem\$1free\$1bytes | Freier Speicherplatz im Dateisystem in Byte, aufgeschlüsselt nach Gerät und Einhängepunkt. |
| node\$1filesystem\$1files | Gesamtzahl der Dateiknoten (Inodes) im Dateisystem, aufgeschlüsselt nach Gerät und Einhängepunkt. |
| node\$1filesystem\$1files\$1free | Anzahl der freien Dateiknoten (Inodes) im Dateisystem, aufgeschlüsselt nach Gerät und Einhängepunkt. |
| node\$1filesystem\$1readonly | Gibt an, ob das Dateisystem schreibgeschützt eingehängt ist (1 = schreibgeschützt, 0 = lesend und schreibgeschützt). |
| node\$1filesystem\$1device\$1error | Zeigt an, ob beim Abrufen der Dateisystemstatistiken ein Fehler aufgetreten ist (1 = Fehler, 0 = Erfolg). |
## Einschränkungen
Die aktuelle Amazon MSK-Integration mit Amazon Managed Service for Prometheus hat die folgenden Einschränkungen:
+ Wird nur für von Amazon MSK bereitgestellte Cluster unterstützt (nicht verfügbar für Amazon MSK Serverless)
+ Nicht unterstützt für Amazon MSK-Cluster mit aktiviertem öffentlichen Zugriff in Kombination mit dem KRaft Metadatenmodus
+ Wird für Amazon MSK Express-Broker nicht unterstützt
+ Unterstützt derzeit eine 1:1 -Zuordnung zwischen Amazon MSK-Clustern und Amazon Managed Service für Prometheus Collectors/Workspaces
# Was sind Prometheus-kompatible Metriken?
Um Prometheus-Metriken aus Ihren Anwendungen und Ihrer Infrastruktur für die Verwendung in Amazon Managed Service für Prometheus zu extrahieren, müssen sie *Prometheus-kompatible Metriken* von Prometheus-kompatiblen `/metrics`-Endpunkten instrumentieren und verfügbar machen. Sie können Ihre eigenen Metriken implementieren, müssen es aber nicht. Kubernetes (einschließlich Amazon EKS) und viele andere Bibliotheken und Services implementieren diese Metriken direkt.
Wenn Metriken in Amazon EKS auf einen Prometheus-kompatiblen Endpunkt exportiert werden, können Sie diese Metriken automatisch vom Kollektor von Amazon Managed Service für Prometheus auslesen lassen.
Weitere Informationen finden Sie unter den folgenden Themen:
+ Weitere Informationen zu vorhandenen Bibliotheken und Services, die Metriken als Prometheus-Metriken exportieren, finden Sie unter [Exporter und Integrationen](https://prometheus.io/docs/instrumenting/exporters/) in der Prometheus-Dokumentation.
+ Weitere Informationen zum Exportieren von Prometheus-kompatiblen Metriken aus Ihrem eigenen Code finden Sie unter [Exportieren schreiben](https://prometheus.io/docs/instrumenting/writing_exporters/) in der Prometheus-Dokumentation.
+ Weitere Informationen darüber, wie Sie einen Kollektor für Amazon Managed Service für Prometheus einrichten, der automatisch Metriken aus Ihren Amazon-EKS-Clustern abruft, finden Sie unter [Verwaltete Collectors für Amazon EKS einrichten](AMP-collector-how-to.md).
# Überwachen Sie Sammler mit verkauften Baumstämmen
Die Sammler von Amazon Managed Service for Prometheus stellen veräußerte Protokolle zur Verfügung, mit denen Sie den Prozess der Erfassung von Kennzahlen überwachen und Fehler beheben können. Diese Protokolle werden automatisch an Amazon CloudWatch Logs gesendet und bieten Einblick in die Serviceerkennung, die Erfassung von Metriken und den Datenexport. Der Collector verkauft Protokolle für drei Hauptkomponenten der Pipeline zur Erfassung von Metriken:
**Topics**
+ [Protokolle zur Diensterkennung](#amp-collector-service-discovery-vended-logs)
+ [Collector-Protokolle](#amp-collector-vended-logs)
+ [Exporter-Protokolle](#amp-exporter-vended-logs)
+ [Collector Vended Logs verstehen und verwenden](#amp-collector-log-details)
## Protokolle zur Diensterkennung
Service-Discovery-Protokolle enthalten Informationen über den Zielermittlungsprozess, darunter:
+ Authentifizierungs- oder Berechtigungsprobleme beim Zugriff auf Kubernetes-API-Ressourcen.
+ Konfigurationsfehler in den Service Discovery-Einstellungen.
Die folgenden Beispiele zeigen häufige Authentifizierungs- und Berechtigungsfehler, die bei der Serviceerkennung auftreten können:
**Amazon EKS-Cluster nicht vorhanden**
Wenn der angegebene Amazon EKS-Cluster nicht existiert, erhalten Sie die folgende Fehlermeldung:
```
{
"component": "SERVICE_DISCOVERY",
"timestamp": "2025-04-30T17:25:41.946Z",
"message": {
"log": "Failed to watch Service - Verify your scraper source exists."
},
"scrapeConfigId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
**Ungültige Berechtigungen für Dienste**
Wenn der Collector nicht über die erforderlichen RBAC-Berechtigungen (Role-Based Access Control) verfügt, um Dienste zu überwachen, wird folgende Fehlermeldung angezeigt:
```
{
"component": "SERVICE_DISCOVERY",
"timestamp": "2025-04-30T17:25:41.946Z",
"message": {
"log": "Failed to watch Service - Verify your scraper source permissions are valid."
},
"scrapeConfigId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
**Ungültige Berechtigungen für Endgeräte**
Wenn der Collector nicht über die erforderlichen RBAC-Berechtigungen (Role-Based Access Control) verfügt, um Endpoints zu überwachen, wird folgende Fehlermeldung angezeigt:
```
{
"component": "SERVICE_DISCOVERY",
"timestamp": "2025-04-30T17:25:41.946Z",
"message": {
"log": "Failed to watch Endpoints - Verify your scraper source permissions are valid."
},
"scrapeConfigId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
## Collector-Protokolle
Collector-Protokolle enthalten Informationen über den Prozess des Auslesens von Metriken, darunter:
+ Scrape-Fehler, die darauf zurückzuführen sind, dass Endgeräte nicht verfügbar sind.
+ Verbindungsprobleme beim Versuch, Ziele zu scrapen.
+ Timeouts bei Scrape-Vorgängen.
+ Von Scrape-Zielen zurückgegebene HTTP-Statusfehler.
Die folgenden Beispiele zeigen häufige Collector-Fehler, auf die Sie beim Scraping von Metriken stoßen können:
**Endpunkt fehlender Metriken**
Wenn der `/metrics` Endpunkt auf der Zielinstanz nicht verfügbar ist, erhalten Sie diesen Fehler:
```
{
"component": "COLLECTOR",
"message": {
"log": "Failed to scrape Prometheus endpoint - verify /metrics endpoint is available",
"job": "pod_exporter",
"targetLabels": "{__name__=\"up\", instance=\10.24.34.0\", job=\"pod_exporter\"}"
},
"timestamp": "1752787969551",
"scraperId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
**Verbindung wurde verweigert**
Wenn der Collector keine Verbindung zum Zielendpunkt herstellen kann, erhalten Sie diesen Fehler:
```
{
"scrapeConfigId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"timestamp": "2025-04-30T17:25:41.946Z",
"message": {
"message": "Scrape failed",
"scrape_pool": "pod_exporter",
"target": "http://10.24.34.0:80/metrics",
"error": "Get \"http://10.24.34.0:80/metrics\": dial tcp 10.24.34.0:80: connect: connection refused"
},
"component": "COLLECTOR"
}
```
## Exporter-Protokolle
Exportprotokolle enthalten Informationen über den Prozess des Sendens der gesammelten Messwerte an Ihren Amazon Managed Service for Prometheus-Workspace, einschließlich:
+ Anzahl der verarbeiteten Metriken und Datenpunkte.
+ Exportfehler aufgrund von Workspace-Problemen.
+ Berechtigungsfehler beim Versuch, Metriken zu schreiben.
+ Abhängigkeitsfehler in der Exportpipeline.
Das folgende Beispiel zeigt einen häufigen Exportfehler, der beim Export von Metriken auftreten kann:
**Workspace wurde nicht gefunden**
Wenn der Ziel-Workspace für den Metrikexport nicht gefunden werden kann, wird folgende Fehlermeldung angezeigt:
```
{
"component": "EXPORTER",
"message": {
"log": "Failed to export to the target workspace - Verify your scraper destination.",
"samplesDropped": 5
},
"timestamp": "1752787969664",
"scraperId": "s-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
## Collector Vended Logs verstehen und verwenden
### Struktur der Protokolle
Alle von Collector verkauften Logs folgen einer konsistenten Struktur mit den folgenden Feldern:
**scrapeConfigId**
Die eindeutige Kennung der Scrape-Konfiguration, die das Protokoll generiert hat.
**timestamp**
Der Zeitpunkt, zu dem der Protokolleintrag generiert wurde.
**message**
Der Inhalt der Protokollnachricht, der zusätzliche strukturierte Felder enthalten kann.
**Komponente**
Die Komponente, die das Protokoll generiert hat (SERVICE\$1DISCOVERY, COLLECTOR oder EXPORTER)
### Verwendung von versendeten Protokollen zur Fehlerbehebung
Die Collector Vended Logs helfen Ihnen bei der Behebung häufiger Probleme bei der Erfassung von Metriken:
1. Probleme bei der Serviceerkennung
+ Überprüfen Sie die **SERVICE\$1DISCOVERY-Protokolle** auf Authentifizierungs- oder Berechtigungsfehler.
+ Stellen Sie sicher, dass der Collector über die erforderlichen Berechtigungen für den Zugriff auf Kubernetes-Ressourcen verfügt.
1. Probleme beim Scraping von Metriken
+ Überprüfen Sie die **COLLECTOR-Protokolle** auf Scrape-Fehler.
+ Stellen Sie sicher, dass auf die Zielendpunkte zugegriffen werden kann und ob Metriken zurückgegeben werden.
+ Stellen Sie sicher, dass die Firewallregeln es dem Collector ermöglichen, eine Verbindung zu Zielendpunkten herzustellen.
1. Probleme beim Export von Metriken
+ Überprüfen Sie die **EXPORTER-Protokolle** auf Exportfehler.
+ Stellen Sie sicher, dass der Workspace existiert und korrekt konfiguriert ist.
+ Stellen Sie sicher, dass der Collector über die erforderlichen Berechtigungen verfügt, um in den Workspace zu schreiben.
### Zugreifen auf vom Collector versendete Protokolle
Von Collector verkaufte Logs werden automatisch an Amazon CloudWatch Logs gesendet. So greifen Sie auf diese Protokolle zu:
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Protokollgruppen** aus.
1. Suchen Sie die Protokollgruppe für Ihren Collector und wählen Sie sie aus:`/aws/prometheus/workspace_id/collector/collector_id`.
1. Durchsuchen oder durchsuchen Sie die Protokollereignisse, um relevante Informationen zu finden.
Sie können CloudWatch Logs Insights auch verwenden, um Ihre Collector-Logs abzufragen und zu analysieren. Um beispielsweise alle Fehler bei der Diensterkennung zu finden, gehen Sie wie folgt vor:
```
fields @timestamp, message.message
| filter component = "SERVICE_DISCOVERY" and message.message like /Failed/
| sort @timestamp desc
```
### Bewährte Methoden für die Überwachung von Kollektoren
So überwachen Sie Ihren Amazon Managed Service für Prometheus-Sammler effektiv:
1. Richten Sie CloudWatch Alarme für kritische Collector-Probleme ein, wie z. B. anhaltende Scrape-Ausfälle oder Exportfehler. Weitere Informationen finden Sie unter [Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) im * CloudWatch Amazon-Benutzerhandbuch*.
1. Erstellen Sie CloudWatch Dashboards, um die Leistungskennzahlen von Collector zusammen mit den gesammelten Protokolldaten zu visualisieren. Weitere Informationen finden Sie unter [Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) im * CloudWatch Amazon-Benutzerhandbuch*.
1. Überprüfen Sie regelmäßig die Service-Discovery-Logs, um sicherzustellen, dass die Ziele korrekt erkannt werden.
1. Überwachen Sie die Anzahl der gelöschten Ziele, um potenzielle Konfigurationsprobleme zu identifizieren.
1. Verfolgen Sie Exportfehler, um sicherzustellen, dass die Metriken erfolgreich an Ihren Workspace gesendet werden.
# Kundenverwaltete Kollektoren
Dieser Abschnitt enthält Informationen zum Erfassen von Daten, indem Sie Ihre eigenen Kollektoren einrichten, die mithilfe von Prometheus Remote-Write-Metriken an Amazon Managed Service für Prometheus senden.
Wenn Sie Ihre eigenen Kollektoren verwenden, um Metriken an Amazon Managed Service für Prometheus zu senden, sind Sie dafür verantwortlich, Ihre Metriken zu sichern und sicherzustellen, dass der Erfassungsprozess Ihren Verfügbarkeitsanforderungen entspricht.
Die meisten vom Kunden verwalteten Kollektoren verwenden eines der folgenden Tools:
+ **AWS Distro for OpenTelemetry (ADOT) — ADOT** ist eine vollständig unterstützte, sichere und produktionsbereite Open-Source-Distribution, die Agenten die Erfassung von OpenTelemetry Metriken ermöglicht. Sie können ADOT verwenden, um Metriken zu sammeln und sie an Ihren Workspace in Amazon Managed Service für Prometheus zu senden. [Weitere Informationen zum ADOT Collector finden Sie unter Distro for.AWS OpenTelemetry](https://aws.amazon.com/otel/)
+ **Prometheus-Agent** – Sie können Ihre eigene Instance des Open-Source-Prometheus-Servers einrichten, der als Agent ausgeführt wird, um Metriken zu sammeln und sie an Ihren Workspace in Amazon Managed Service für Prometheus weiterzuleiten.
Die folgenden Themen beschreiben die Verwendung dieser beiden Tools und enthalten allgemeine Informationen zur Einrichtung Ihrer eigenen Kollektoren.
**Topics**
+ [Sichern Sie die Erfassung Ihrer Metriken](AMP-secure-metric-ingestion.md)
+ [AWS Distro for OpenTelemetry als Collector verwenden](AMP-ingest-with-adot.md)
+ [Eine Prometheus-Instance als Kollektor verwenden](AMP-ingest-with-prometheus.md)
+ [Amazon Managed Service für Prometheus für Hochverfügbarkeitsdaten einrichten](AMP-ingest-high-availability.md)
# Sichern Sie die Erfassung Ihrer Metriken
Amazon Managed Service für Prometheus bietet Möglichkeiten, Sie bei der sicheren Erfassung Ihrer Messwerte zu unterstützen.
## Verwendung AWS PrivateLink mit Amazon Managed Service für Prometheus
Der Netzwerkverkehr für die Aufnahme der Metriken in Amazon Managed Service for Prometheus kann über einen öffentlichen Internet-Endpunkt oder über einen VPC-Endpunkt erfolgen. AWS PrivateLink Durch die Verwendung AWS PrivateLink wird sichergestellt, dass der Netzwerkverkehr von Ihnen innerhalb des AWS Netzwerks gesichert VPCs ist, ohne dass er über das öffentliche Internet übertragen wird. Informationen zum Erstellen eines AWS PrivateLink VPC-Endpunkts für Amazon Managed Service for Prometheus finden Sie unter. [Verwendung von Amazon Managed Service für Prometheus mit Schnittstellen-VPC-Endpunkten](AMP-and-interface-VPC.md)
## Authentifizierung und Autorisierung
AWS Identity and Access Management (IAM) ist ein Webservice, mit dem Sie den Zugriff auf AWS Ressourcen sicher kontrollieren können. Sie verwenden IAM, um zu steuern, wer authentifiziert (angemeldet) und autorisiert (Berechtigungen besitzt) ist, Ressourcen zu nutzen. Amazon Managed Service für Prometheus ist in IAM integriert, um Ihnen zu helfen, Ihre Daten zu schützen. Wenn Sie Amazon Managed Service für Prometheus einrichten, müssen Sie einige IAM-Rollen erstellen, die es ermöglichen, Metriken von Prometheus-Servern zu erfassen, und die es Grafana-Servern ermöglichen, die Metriken abzufragen, die in Ihren Workspace in Amazon Managed Service für Prometheus gespeichert sind. Weitere Informationen zu IAM finden Sie unter [Was ist IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html).
Eine weitere AWS Sicherheitsfunktion, die Ihnen bei der Einrichtung von Amazon Managed Service für Prometheus helfen kann, ist der AWS Signature Version 4-Signaturprozess (AWS Sigv4). Signature Version 4 ist der Prozess zum Hinzufügen von Authentifizierungsinformationen zu AWS Anfragen, die über HTTP gesendet werden. Aus Sicherheitsgründen AWS müssen die meisten Anfragen mit einem Zugriffsschlüssel signiert werden, der aus einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel besteht. Diese beiden Schlüssel werden in der Regel als Sicherheitsanmeldeinformationen bezeichnet. Weitere Informationen über SigV4 finden Sie unter [Signatur Version 4-Signierungsprozess](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html).
# AWS Distro for OpenTelemetry als Collector verwenden
In diesem Abschnitt wird beschrieben, wie Sie den AWS Distro for OpenTelemetry (ADOT) Collector so konfigurieren, dass er aus einer mit Prometheus instrumentierten Anwendung scrapt und die Metriken an Amazon Managed Service for Prometheus sendet. [Weitere Informationen zum ADOT Collector finden Sie unter Distro for.AWS OpenTelemetry](https://aws.amazon.com/otel/)
In den folgenden Themen werden drei verschiedene Möglichkeiten beschrieben, ADOT als Collector für Ihre Metriken einzurichten, je nachdem, ob Ihre Metriken von Amazon EKS, Amazon ECS oder einer Amazon EC2 EC2-Instance stammen.
**Topics**
+ [Richten Sie die Erfassung von Metriken mit AWS Distro for OpenTelemetry auf einem Amazon Elastic Kubernetes Service Service-Cluster ein](AMP-onboard-ingest-metrics-OpenTelemetry.md)
+ [Richten Sie mithilfe von AWS Distro for Open Telemetry die Erfassung von Metriken aus Amazon ECS ein](AMP-onboard-ingest-metrics-OpenTelemetry-ECS.md)
+ [Einrichten der Erfassung von Metriken aus einer Amazon-EC2-Instance mithilfe von Remote-Write](AMP-onboard-ingest-metrics-remote-write-EC2.md)
# Richten Sie die Erfassung von Metriken mit AWS Distro for OpenTelemetry auf einem Amazon Elastic Kubernetes Service Service-Cluster ein
Sie können den Collector AWS Distro for OpenTelemetry (ADOT) verwenden, um Metriken aus einer mit Prometheus instrumentierten Anwendung zu extrahieren und die Metriken an Amazon Managed Service for Prometheus zu senden.
**Anmerkung**
[Weitere Informationen zum ADOT-Collector finden Sie unter Distro for.AWS OpenTelemetry](https://aws.amazon.com/otel/)
Weitere Informationen zu mit Prometheus instrumentierten Anwendungen finden Sie unter. [Was sind Prometheus-kompatible Metriken?](prom-compatible-metrics.md)
Das Sammeln von Prometheus-Metriken mit ADOT umfasst drei OpenTelemetry Komponenten: den Prometheus Receiver, den Prometheus Remote Write Exporter und die Sigv4 Authentication Extension.
Sie können den Prometheus-Empfänger mithilfe Ihrer vorhandenen Prometheus-Konfiguration konfigurieren, um die Serviceerkennung und das Metrik-Scraping durchzuführen. Der Prometheus Receiver erfasst Metriken im Prometheus-Expositionsformat. Alle Anwendungen oder Endpunkte, die Sie scrapen möchten, sollten mit der Prometheus-Client-Bibliothek konfiguriert werden. Der Prometheus Receiver unterstützt alle Prometheus-Konfigurationen zum Scraping und Umetikettieren, die in der Prometheus-Dokumentation unter [Konfiguration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) beschrieben sind. Sie können diese Konfigurationen direkt in Ihre ADOT Kollektor-Konfigurationen einfügen.
Der Prometheus Remote Write Exporter verwendet den `remote_write`-Endpunkt, um die gesammelten Metriken an Ihren Management-Portal-Workspace zu senden. Die HTTP-Anfragen zum Export von Daten werden mit Sigv4, dem AWS Protokoll für sichere Authentifizierung, mit der AWS Sigv4 Authentication Extension signiert. Weitere Informationen finden Sie unter [Signatur Version 4-Signierungsprozess](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html).
Der Kollektor erkennt automatisch Prometheus-Metriken-Endpunkte auf Amazon EKS und verwendet die Konfiguration unter [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config).
Die folgende Demo ist ein Beispiel für diese Konfiguration auf einem Cluster, auf dem Amazon Elastic Kubernetes Service oder selbstverwaltetes Kubernetes ausgeführt wird. Um diese Schritte ausführen zu können, benötigen Sie AWS Anmeldeinformationen aus einer der möglichen Optionen in der Kette der AWS Standardanmeldedaten. Weitere Informationen finden Sie unter [Konfiguration des AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). In dieser Demo wird eine Beispiel-App genutzt, die für Integrationstests des Prozesses verwendet wird. Die Beispiel-App stellt Metriken am `/metrics`-Endpunkt bereit, wie die Prometheus-Client-Bibliothek.
## Voraussetzungen
Bevor Sie mit den folgenden Schritten zur Einrichtung der Datenerfassung beginnen, müssen Sie Ihre IAM-Rolle für das Servicekonto und die Vertrauensrichtlinie einrichten.
**So richten Sie die IAM-Rolle für das Servicekonto und die Vertrauensrichtlinie ein**
1. Erstellen Sie die IAM-Rolle für das Servicekonto, indem Sie die Schritte unter [Einrichten von Servicerollen für die Erfassung von Metriken aus Amazon-EKS-Clustern](set-up-irsa.md#set-up-irsa-ingest) befolgen.
Der ADOT Kollektor verwendet diese Rolle, wenn er Metriken erfasst und exportiert.
1. Bearbeiten Sie als Nächstes die Vertrauensrichtlinie. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/home) die IAM-Konsole.
1. Wählen Sie im linken Navigationsbereich **Rollen** aus und suchen Sie nach den Rollen **amp-iamproxy-ingest-role**, die Sie in Schritt 1 erstellt haben.
1. Wählen Sie die Registerkarte **Vertrauensbeziehungen** und dann **Vertrauensbeziehung bearbeiten** aus.
1. Ersetzen Sie in der JSON-Vertrauenbeziehungsrichtlinie `aws-amp` durch `adot-col` und wählen Sie dann **Vertrauensrichtlinie aktualisieren** aus. Das Ergebnis Ihrer Vertrauensbeziehungsrichtlinie sollte wie folgt aussehen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:adot-col:amp-iamproxy-ingest-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
------
1. Wählen Sie die Registerkarte **Berechtigungen** und stellen Sie sicher, dass die folgende Berechtigungsrichtlinie an die Rolle angehängt ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aps:RemoteWrite",
"aps:GetSeries",
"aps:GetLabels",
"aps:GetMetricMetadata"
],
"Resource": "*"
}
]
}
```
------
## Erfassung der Prometheus-Metriken aktivieren
**Anmerkung**
Wenn Sie einen Namespace in Amazon EKS erstellen, sind `alertmanager` und Node Exporter standardmäßig deaktiviert.
**So aktivieren Sie die Prometheus-Erfassung auf einem Amazon-EKS- oder Kubernetes-Cluster**
1. Forken und klonen Sie die Beispiel-App aus dem Repository unter [aws-otel-community](https://github.com/aws-observability/aws-otel-community).
Führen Sie anschließend folgende Befehle aus.
```
cd ./sample-apps/prometheus-sample-app
docker build . -t prometheus-sample-app:latest
```
1. Push dieses Image in eine Registry wie Amazon ECR oder DockerHub.
1. Stellen Sie die Beispiel-App im Cluster bereit, indem Sie diese Kubernetes-Konfiguration kopieren und anwenden. Ändern Sie das Bild in das Bild, das Sie gerade übertragen haben, indem Sie `{{PUBLIC_SAMPLE_APP_IMAGE}}` in der `prometheus-sample-app.yaml` Datei ersetzen.
```
curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/examples/eks/aws-prometheus/prometheus-sample-app.yaml -o prometheus-sample-app.yaml
kubectl apply -f prometheus-sample-app.yaml
```
1. Geben Sie den folgenden Befehl ein, um zu überprüfen, ob die Beispiel-App gestartet wurde. In der Ausgabe des Befehls sehen Sie `prometheus-sample-app` in der `NAME` Spalte.
```
kubectl get all -n aoc-prometheus-pipeline-demo
```
1. Starten Sie eine Standard-Instance des ADOT Kollektors. Geben Sie dazu zunächst den folgenden Befehl ein, um die Kubernetes-Konfiguration für ADOT Kollektor abzurufen.
```
curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/examples/eks/aws-prometheus/prometheus-daemonset.yaml -o prometheus-daemonset.yaml
```
Bearbeiten Sie dann die Vorlagendatei und ersetzen Sie den **remote\$1write**-Endpunkt für Ihren Workspace in Amazon Managed Service für Prometheus durch `YOUR_ENDPOINT` und Ihre Region durch `YOUR_REGION`. Verwenden Sie den **remote\$1write**-Endpunkt, der in der Konsole von Amazon Managed Service für Prometheus angezeigt wird, wenn Sie sich Ihre Workspace-Details ansehen.
Sie müssen außerdem `YOUR_ACCOUNT_ID` im Bereich Dienstkonto der Kubernetes-Konfiguration Ihre AWS Konto-ID ändern.
In diesem Beispiel verwendet die ADOT Kollektor-Konfiguration eine Anmerkung (`scrape=true`), um anzugeben, welche Zielendpunkte gescrapt werden sollen. Auf diese Weise kann der ADOT Kollektor den Endpunkt der Beispiel-App von den Endpunkten des Kube-Systems in Ihrem Cluster unterscheiden. Sie können dies aus den Konfigurationen der Umetikettierung entfernen, wenn Sie eine andere Beispiel-App entfernen möchten.
1. Geben Sie den folgenden Befehl ein, um den ADOT Kollektor bereitzustellen.
```
kubectl apply -f prometheus-daemonset.yaml
```
1. Geben Sie den folgenden Befehl ein, um zu überprüfen, ob der ADOT Kollektor gestartet wurde. Suchen Sie nach `adot-col` in der `NAMESPACE` Spalte.
```
kubectl get pods -n adot-col
```
1. Stellen Sie mithilfe des Protokoll-Exporters sicher, dass die Pipeline funktioniert. Unsere Beispielvorlage ist bereits in den Protokoll-Exporter integriert. Geben Sie die folgenden Befehle ein.
```
kubectl get pods -A
kubectl logs -n adot-col name_of_your_adot_collector_pod
```
Einige der aus der Beispiel-App gewonnenen Metriken sehen wie im folgenden Beispiel aus.
```
Resource labels:
-> service.name: STRING(kubernetes-service-endpoints)
-> host.name: STRING(192.168.16.238)
-> port: STRING(8080)
-> scheme: STRING(http)
InstrumentationLibraryMetrics #0
Metric #0
Descriptor:
-> Name: test_gauge0
-> Description: This is my gauge
-> Unit:
-> DataType: DoubleGauge
DoubleDataPoints #0
StartTime: 0
Timestamp: 1606511460471000000
Value: 0.000000
```
1. Um zu testen, ob Amazon Managed Service für Prometheus die Messwerte erhalten hat, verwenden Sie `awscurl`. [Mit diesem Tool können Sie HTTP-Anfragen über die Befehlszeile mit AWS Sigv4-Authentifizierung senden. Sie müssen also lokal über AWS Anmeldeinformationen mit den richtigen Berechtigungen für Abfragen von Amazon Managed Service for Prometheus verfügen. Anweisungen zur Installation finden Sie unter awscurl`awscurl`.](https://github.com/okigan/awscurl)
Ersetzen Sie `AMP_REGION` im folgenden Befehl und `AMP_ENDPOINT` durch die Informationen für Ihren .
```
awscurl --service="aps" --region="AMP_REGION" "https://AMP_ENDPOINT/api/v1/query?query=adot_test_gauge0"
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"adot_test_gauge0"},"value":[1606512592.493,"16.87214000011479"]}]}}
```
Wenn Sie als Antwort eine Metrik erhalten, bedeutet das, dass Ihre Pipeline-Einrichtung erfolgreich war und die Metrik erfolgreich von der Beispiel-App an Amazon Managed Service für Prometheus weitergegeben wurde.
**Bereinigen**
Geben Sie die folgenden Befehle ein, um diese Demo zu bereinigen.
```
kubectl delete namespace aoc-prometheus-pipeline-demo
kubectl delete namespace adot-col
```
## Erweiterte Konfiguration
Der Prometheus Receiver unterstützt alle Prometheus-Konfigurationen zum Scraping und Umetikettieren, die in der Prometheus-Dokumentation unter [Konfiguration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) beschrieben sind. Sie können diese Konfigurationen direkt in Ihre ADOT Kollektor-Konfigurationen einfügen.
Die Konfiguration für den Prometheus Receiver umfasst Ihre Serviceerkennung, Scraping-Konfigurationen und Umetikettierungs-Konfigurationen. Die Konfiguration des Empfängers sieht wie folgt aus.
```
receivers:
prometheus:
config:
[[Your Prometheus configuration]]
```
Folgendes ist ein Konfigurationsbeispiel:
```
receivers:
prometheus:
config:
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: kubernetes-service-endpoints
sample_limit: 10000
kubernetes_sd_configs:
- role: endpoints
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
```
Wenn Sie über eine bestehende Prometheus-Konfiguration verfügen, müssen Sie die `$` Zeichen durch `$$` ersetzen, um zu vermeiden, dass die Werte durch Umgebungsvariablen ersetzt werden. \$1 Dies ist besonders wichtig für den Ersatzwert der relabel\$1configurations. Wenn Sie beispielsweise mit der folgenden relabel\$1configuration beginnen:
```
relabel_configs:
- source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
regex: (.+);(.+);(.+)
replacement: ${1}://${2}${3}
target_label: __param_target
```
Es würde wie folgt werden:
```
relabel_configs:
- source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
regex: (.+);(.+);(.+)
replacement: $${1}://${2}${3}
target_label: __param_target
```
**Prometheus Remote Write Exporter und SigV4-Authentifizierungserweiterung**
Die Konfiguration für den Prometheus Remote Write Exporter und die SigV4-Authentifizierungserweiterung ist einfacher als für den Prometheus-Empfänger. In dieser Phase der Pipeline wurden die Metriken bereits erfasst und wir sind bereit, diese Daten in Amazon Managed Service für Prometheus zu exportieren. Die Mindestanforderung für eine erfolgreiche Konfiguration für die Kommunikation mit Amazon Managed Service für Prometheus ist im folgenden Beispiel dargestellt.
```
extensions:
sigv4auth:
service: "aps"
region: "user-region"
exporters:
prometheusremotewrite:
endpoint: "https://aws-managed-prometheus-endpoint/api/v1/remote_write"
auth:
authenticator: "sigv4auth"
```
Diese Konfiguration sendet eine HTTPS-Anfrage, die von AWS Sigv4 mithilfe von AWS Anmeldeinformationen aus der standardmäßigen Anmeldeinformationskette signiert wurde. AWS Weitere Informationen finden Sie unter [Konfigurieren der AWS SDK für Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). Sie müssen den Service als `aps` angeben.
Unabhängig von der Bereitstellungsmethode muss der ADOT-Collector Zugriff auf eine der aufgelisteten Optionen in der Kette der AWS Standardanmeldedaten haben. Die Sigv4-Authentifizierungserweiterung hängt von der ab AWS SDK für Go und verwendet sie, um Anmeldeinformationen abzurufen und sich zu authentifizieren. Sie müssen sicherstellen, dass diese Anmeldeinformationen über Remote-Write-Berechtigungen für Amazon Managed Service für Prometheus verfügen.
# Richten Sie mithilfe von AWS Distro for Open Telemetry die Erfassung von Metriken aus Amazon ECS ein
In diesem Abschnitt wird erklärt, wie Sie Metriken von Amazon Elastic Container Service (Amazon ECS) sammeln und sie mithilfe von AWS Distro for Open Telemetry (ADOT) in Amazon Managed Service for Prometheus aufnehmen. Außerdem wird beschrieben, wie Sie Ihre Metriken in Amazon Managed Grafana anzeigen können.
## Voraussetzungen
**Wichtig**
Bevor Sie beginnen, benötigen Sie eine Amazon-ECS-Umgebung auf einem AWS Fargate -Cluster mit Standardeinstellungen, einen Workspace in Amazon Managed Service für Prometheus und einen Workspace in Amazon Managed Grafana. Wir gehen davon aus, dass Sie mit Container-Workloads, Amazon Managed Service für Prometheus und Amazon Managed Grafana vertraut sind.
Weitere Informationen finden Sie unter den folgenden Links:
+ Informationen zum Erstellen einer Amazon ECS-Umgebung auf einem Fargate-Cluster mit Standardeinstellungen finden Sie unter [Erstellen eines Clusters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html) im *Amazon ECS-Entwicklerhandbuch*.
+ Informationen zum Erstellen eines Workspace in Amazon Managed Service für Prometheus finden Sie unter [Einen Workspace erstellen](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
+ Informationen zum Erstellen eines Workspace in Amazon Managed Grafana-finden Sie unter [Einen Workspace erstellen](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html) im *Benutzerhandbuch von Amazon Managed Grafana*.
## Schritt 1: Definieren Sie ein benutzerdefiniertes ADOT-Collector-Container-Image
Verwenden Sie die folgende Konfigurationsdatei als Vorlage, um Ihr eigenes ADOT-Kollektor-Container-Image zu definieren. Ersetzen Sie *my-remote-URL* und *my-region* durch Ihre `region` Werte `endpoint` und. Speichern Sie die Konfiguration in einer Datei namens *adot-config.yaml*.
**Anmerkung**
Diese Konfiguration verwendet die `sigv4auth` Erweiterung zur Authentifizierung von Aufrufen an Amazon Managed Service für Prometheus. Weitere Informationen zur Konfiguration `sigv4auth` finden Sie unter [Authenticator — Sigv4 on](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/sigv4authextension). GitHub
```
receivers:
prometheus:
config:
global:
scrape_interval: 15s
scrape_timeout: 10s
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: [ 0.0.0.0:9090 ]
awsecscontainermetrics:
collection_interval: 10s
processors:
filter:
metrics:
include:
match_type: strict
metric_names:
- ecs.task.memory.utilized
- ecs.task.memory.reserved
- ecs.task.cpu.utilized
- ecs.task.cpu.reserved
- ecs.task.network.rate.rx
- ecs.task.network.rate.tx
- ecs.task.storage.read_bytes
- ecs.task.storage.write_bytes
exporters:
prometheusremotewrite:
endpoint: my-remote-URL
auth:
authenticator: sigv4auth
logging:
loglevel: info
extensions:
health_check:
pprof:
endpoint: :1888
zpages:
endpoint: :55679
sigv4auth:
region: my-region
service: aps
service:
extensions: [pprof, zpages, health_check, sigv4auth]
pipelines:
metrics:
receivers: [prometheus]
exporters: [logging, prometheusremotewrite]
metrics/ecs:
receivers: [awsecscontainermetrics]
processors: [filter]
exporters: [logging, prometheusremotewrite]
```
## Schritt 2: Übertragen Sie Ihr ADOT-Collector-Container-Image in ein Amazon ECR-Repository
Verwenden Sie ein Dockerfile, um Ihr Container-Image zu erstellen und in ein Repository von Amazon Elastic Container Registry (ECR) zu pushen.
1. Erstellen Sie das Dockerfile, um Ihr Container-Image zu kopieren und dem OTEL Docker-Image hinzuzufügen.
```
FROM public.ecr.aws/aws-observability/aws-otel-collector:latest
COPY adot-config.yaml /etc/ecs/otel-config.yaml
CMD ["--config=/etc/ecs/otel-config.yaml"]
```
1. Erstellen Sie ein Amazon-ECR-Repository.
```
# create repo:
COLLECTOR_REPOSITORY=$(aws ecr create-repository --repository aws-otel-collector \
--query repository.repositoryUri --output text)
```
1. Erstellen Sie Ihr Container-Image.
```
# build ADOT collector image:
docker build -t $COLLECTOR_REPOSITORY:ecs .
```
**Anmerkung**
Dies setzt voraus, dass Sie Ihren Container in derselben Umgebung erstellen, in der er ausgeführt werden soll. Wenn nicht, müssen Sie den `--platform` Parameter möglicherweise beim Erstellen des Images verwenden.
1. Melden Sie sich im Amazon-ECR-Repository an. Ersetzen Sie es *my-region* durch Ihren Wert`region`.
```
# sign in to repo:
aws ecr get-login-password --region my-region | \
docker login --username AWS --password-stdin $COLLECTOR_REPOSITORY
```
1. Pushen Sie Ihr Container-Image.
```
# push ADOT collector image:
docker push $COLLECTOR_REPOSITORY:ecs
```
## Schritt 3: Erstellen Sie eine Amazon ECS-Aufgabendefinition, um Amazon Managed Service for Prometheus zu scrapen
Erstellen Sie eine Amazon-ECS-Aufgabendefinition zum Scrapen von Amazon Managed Service für Prometheus. Ihre Aufgabendefinition sollte einen Container mit dem Namen `adot-collector` und einen Container mit dem Namen `prometheus` enthalten. `prometheus` generiert Metriken und `adot-collector` Scrapes`prometheus`.
**Anmerkung**
Amazon Managed Service für Prometheus wird als Service ausgeführt und sammelt Metriken aus Containern. In diesem Fall führen die Container Prometheus lokal im Agentenmodus aus, wodurch die lokalen Metriken an Amazon Managed Service für Prometheus gesendet werden.
**Beispiel: Aufgabendefinition**
Im Folgenden finden Sie ein Beispiel dafür, wie Ihre Aufgabendefinition aussehen kann. Sie können dieses Beispiel als Vorlage verwenden, um Ihre eigene Aufgabendefinition zu erstellen. Ersetzen Sie den `image`-Wert von `adot-collector` durch Ihre Repository-URL und Ihr Bild-Tag (`$COLLECTOR_REPOSITORY:ecs`). Ersetzen Sie die `region`-Werte von `adot-collector` und `prometheus` durch Ihre `region`-Werte.
```
{
"family": "adot-prom",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "adot-collector",
"image": "account_id.dkr.ecr.region.amazonaws.com/image-tag",
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-adot-collector",
"awslogs-region": "my-region",
"awslogs-stream-prefix": "ecs",
"awslogs-create-group": "True"
}
}
},
{
"name": "prometheus",
"image": "prom/prometheus:main",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-prom",
"awslogs-region": "my-region",
"awslogs-stream-prefix": "ecs",
"awslogs-create-group": "True"
}
}
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "1024"
}
```
## Schritt 4: Erteilen Sie Ihrer Aufgabe Berechtigungen für den Zugriff auf Amazon Managed Service for Prometheus
Um die gesammelten Metriken an Amazon Managed Service for Prometheus zu senden, muss Ihre Amazon ECS-Aufgabe über die richtigen Berechtigungen verfügen, um die AWS API-Operationen für Sie aufzurufen. Sie müssen eine IAM-Rolle für Ihre Aufgaben erstellen und die `AmazonPrometheusRemoteWriteAccess`-Richtlinie anhängen. Weitere Informationen zum Erstellen dieser Rolle und Anhängen der Richtlinie finden Sie unter [Eine IAM-Rolle und Richtlinie für Ihre Aufgaben erstellen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html#create_task_iam_policy_and_role).
Nachdem Sie `AmazonPrometheusRemoteWriteAccess` zu Ihrer IAM-Rolle hinzufügen und diese Rolle für Ihre Aufgaben verwendet haben, kann Amazon ECS Ihre gescrapten Metriken an Amazon Managed Service für Prometheus senden.
## Schritt 5: Visualisieren Sie Ihre Kennzahlen in Amazon Managed Grafana
**Wichtig**
Bevor Sie beginnen, müssen Sie eine Fargate-Aufgabe in Ihrer Amazon-ECS-Aufgabendefinition ausführen. Andernfalls kann Amazon Managed Service für Prometheus Ihre Metriken nicht verarbeiten.
1. Wählen Sie im Navigationsbereich Ihres Amazon Managed Grafana-Arbeitsbereichs unter dem AWS Symbol **Datenquellen** aus.
1. Wählen Sie auf der Registerkarte **Datenquellen** unter **Service** die Option **Amazon Managed Service für Prometheus** und Ihre **Standardregion** aus.
1. Wählen Sie **Datenquelle hinzufügen** aus.
1. Verwenden Sie die Präfixe `ecs` und `prometheus`, um Ihre Metriken abzufragen und anzuzeigen.
# Einrichten der Erfassung von Metriken aus einer Amazon-EC2-Instance mithilfe von Remote-Write
In diesem Abschnitt wird erläutert, wie Sie einen Prometheus-Server mit Remote-Write in einer Instance von Amazon Elastic Compute Cloud (Amazon EC2) ausführen. Es wird erklärt, wie Sie Metriken aus einer in Go geschriebenen Demo-Anwendung sammeln und sie an einen Workspace in Amazon Managed Service für Prometheus senden.
## Voraussetzungen
**Wichtig**
Bevor Sie beginnen, müssen Sie Prometheus v2.26 oder höher installiert haben. Wir gehen davon aus, dass Sie mit Prometheus, Amazon EC2 und Amazon Managed Service für Prometheus vertraut sind. Informationen zur Installation von Prometheus finden Sie unter [Erste Schritte](https://prometheus.io/docs/prometheus/latest/getting_started/) auf der Prometheus-Website.
Wenn Sie mit Amazon EC2 oder Amazon Managed Service für Prometheus nicht vertraut sind, empfehlen wir Ihnen, zunächst die folgenden Abschnitte zu lesen:
+ [Was ist Amazon Elastic Compute Cloud?](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)
+ [Was ist Amazon Managed Service für Prometheus?](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
## Erstellen Sie eine IAM-Rolle für Amazon EC2
Um Metriken zu streamen, müssen Sie zunächst eine IAM-Rolle mit der AWS verwalteten Richtlinie erstellen. **AmazonPrometheusRemoteWriteAccess** Anschließend können Sie eine Instance mit der Rolle starten und Metriken in Ihren Workspace in Amazon Managed Service für Prometheus streamen.
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Roles (Rollen)** und dann **Create role (Rolle erstellen)** aus.
1. Wählen Sie als Typ der vertrauenswürdigen Entität **AWS -Service** aus. Wählen Sie für den Anwendungsfall **EC2** aus. Wählen Sie **Weiter: Berechtigungen** aus.
1. Geben Sie im Suchfeld **AmazonPrometheusRemoteWriteAccess** ein. Wählen Sie als **Richtlinienname **AmazonPrometheusRemoteWriteAccess****die Option **Richtlinie anhängen** aus. Wählen Sie **Weiter: Tags** aus.
1. (Optional) Erstellen Sie IAM-Tags für Ihre IAM-Rolle. Wählen Sie **Weiter: Prüfen** aus.
1. Geben Sie einen Namen für die neue Rolle ein. Wählen Sie **Richtlinie erstellen** aus.
## Starten Sie eine Amazon-EC2-Instance
Befolgen Sie die Anweisungen unter [Eine Instance starten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role) im *Amazon EC2-Benutzerhandbuch für Linux-Instances*, um eine Amazon-EC2-Instance zu starten.
## Setzen Sie die Demo-App ein
Nachdem Sie Ihre IAM-Rolle erstellt und eine EC2-Instance mit der Rolle gestartet haben, können Sie eine Demo-Anwendung ausführen, um zu sehen, wie sie funktioniert.
**Um eine Demo-Anwendung auszuführen und Metriken zu testen**
1. Verwenden Sie die folgende Vorlage, um eine Go-Datei mit dem Namen `main.go` zu erstellen.
```
package main
import (
"github.com/prometheus/client_golang/prometheus/promhttp"
"net/http"
)
func main() {
http.Handle("/metrics", promhttp.Handler())
http.ListenAndServe(":8000", nil)
}
```
1. Führen Sie den folgenden Befehl aus, um die richtigen Abhängigkeiten zu installieren.
```
sudo yum update -y
sudo yum install -y golang
go get github.com/prometheus/client_golang/prometheus/promhttp
```
1. Setzen Sie die Demo-App ein.
```
go run main.go
```
Die Demo-App sollte auf Port 8000 laufen und alle offengelegten Prometheus-Metriken anzeigen. Das ist ein Beispiel dieser Metriken.
```
curl -s http://localhost:8000/metrics
...
process_max_fds 4096# HELP process_open_fds Number of open file descriptors.# TYPE process_open_fds gauge
process_open_fds 10# HELP process_resident_memory_bytes Resident memory size in bytes.# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 1.0657792e+07# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.# TYPE process_start_time_seconds gauge
process_start_time_seconds 1.61131955899e+09# HELP process_virtual_memory_bytes Virtual memory size in bytes.# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 7.77281536e+08# HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.# TYPE process_virtual_memory_max_bytes gauge
process_virtual_memory_max_bytes -1# HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served.# TYPE promhttp_metric_handler_requests_in_flight gauge
promhttp_metric_handler_requests_in_flight 1# HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 1
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0
```
## Erstellen eines Workspace in Amazon Managed Service für Prometheus
Um einen Workspace in Amazon Managed Service für Prometheus zu erstellen, folgen Sie den Anweisungen unter [Einen Workspace erstellen](AMP-create-workspace.md).
## Setzen Sie einen Prometheus-Server ein
1. Verwenden Sie die folgende YAML-Beispieldatei als Vorlage, um eine neue Datei mit dem Namen `prometheus.yaml` zu erstellen. *my-region*Ersetzen Sie für `url` durch Ihren Regionswert und *my-workspace-id* durch die Workspace-ID, die Amazon Managed Service for Prometheus für Sie generiert hat. Ersetzen Sie für `region` durch den *my-region* Wert für Ihre Region.
**Beispiel: YAML-Datei**
```
global:
scrape_interval: 15s
external_labels:
monitor: 'prometheus'
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:8000']
remote_write:
-
url: https://aps-workspaces.my-region.amazonaws.com/workspaces/my-workspace-id/api/v1/remote_write
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
sigv4:
region: my-region
```
1. Führen Sie den Prometheus-Server aus, um die Metriken der Demo-App an Ihren Workspace in Amazon Managed Service für Prometheus zu senden.
```
prometheus --config.file=prometheus.yaml
```
Der Prometheus-Server sollte jetzt die Metriken der Demo-App an Ihren Workspace in Amazon Managed Service für Prometheus senden.
# Eine Prometheus-Instance als Kollektor verwenden
Sie können eine Prometheus-Instance verwenden, die im *Agentenmodus* läuft (bekannt als *Prometheus-Agent), um Metriken zu sammeln und sie an Ihren Amazon Managed Service for Prometheus-Workspace* zu senden.
In den folgenden Themen werden verschiedene Möglichkeiten beschrieben, eine im Agentenmodus ausgeführte Prometheus-Instance als Kollektor für Ihre Metriken einzurichten.
**Warnung**
Wenn Sie einen Prometheus-Agenten erstellen, sind Sie für dessen Konfiguration und Wartung verantwortlich. [Vermeiden Sie es, Prometheus-Scrape-Endpunkte dem öffentlichen Internet auszusetzen, indem Sie Sicherheitsfunktionen aktivieren.](https://prometheus.io/docs/prometheus/latest/configuration/https/)
Wenn Sie mehrere Prometheus-Instances einrichten, die dieselben Metriken überwachen, und diese aus Gründen der Hochverfügbarkeit an einen einzigen Workspace in Amazon Managed Service für Prometheus senden, müssen Sie die Deduplizierung einrichten. Wenn Sie die Schritte zur Einrichtung der Deduplizierung nicht befolgen, werden Ihnen alle an Amazon Managed Service für Prometheus gesendeten Datenbeispiele, einschließlich doppelter Beispiele, in Rechnung gestellt. Anweisungen zur Einrichtung der Deduplizierung finden Sie unter [Deduplizierung von Hochverfügbarkeitsmetriken, die an Amazon Managed Service für Prometheus gesendet werden](AMP-ingest-dedupe.md).
**Topics**
+ [Richten Sie die Erfassung von einem neuen Prometheus-Server mithilfe des Befehls „Helm“ ein](AMP-onboard-ingest-metrics-new-Prometheus.md)
+ [Richten Sie die Erfassung von einem vorhandenen Prometheus-Server in Kubernetes auf EC2 ein](AMP-onboard-ingest-metrics-existing-Prometheus.md)
+ [Richten Sie die Erfassung von einem vorhandenen Prometheus-Server in Kubernetes auf Fargate ein](AMP-onboard-ingest-metrics-existing-Prometheus-fargate.md)
# Richten Sie die Erfassung von einem neuen Prometheus-Server mithilfe des Befehls „Helm“ ein
Mit den Anweisungen in diesem Abschnitt können Sie Amazon Managed Service für Prometheus schnell einrichten. Sie richten einen neuen Prometheus-Server in einem Amazon-EKS-Cluster ein und der neue Server verwendet eine Standardkonfiguration, um Metriken an Amazon Managed Service für Prometheus zu senden. Für diese Methode müssen die folgenden Voraussetzungen erfüllt sein:
+ Sie benötigen einen Amazon EKS-Cluster, aus dem der neue Prometheus-Server Metriken sammelt.
+ In Ihrem Amazon EKS-Cluster muss ein [Amazon EBS CSI-Treiber](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) installiert sein (von Helm erforderlich).
+ Sie müssen Helm CLI 3.0 oder höher verwenden.
+ Sie müssen einen Linux- oder macOS-Computer verwenden, um die Schritte in den folgenden Abschnitten auszuführen.
## Schritt 1: Hinzufügen neuer Helm-Chart-Repositorys
Geben Sie die folgenden Befehle ein, um neue Helm-Chart-Repositorys hinzuzufügen. Weitere Informationen zu diesen Befehlen finden Sie unter [Helm Repo](https://helm.sh/docs/helm/helm_repo/).
```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add kube-state-metrics https://kubernetes.github.io/kube-state-metrics
helm repo update
```
## Schritt 2: Erstellen eines Prometheus-Namespace
Geben Sie den folgenden Befehl ein, um einen Prometheus-Namespace für den Prometheus-Server und andere Monitoring-Komponenten zu erstellen. *prometheus-namespace*Ersetzen Sie durch den Namen, den Sie für diesen Namespace wünschen.
```
kubectl create namespace prometheus-namespace
```
## Schritt 3: Einrichten von IAM-Rollen für Servicekonten
Für die Onboarding-Methode, die wir dokumentieren, müssen Sie IAM-Rollen für Servicekonten im Amazon-EKS-Cluster verwenden, in dem der Prometheus-Server läuft.
Mit IAM-Rollen für Servicekonten können Sie eine IAM-Rolle mit einem Kubernetes-Servicekonto verknüpfen. Dieses Servicekonto kann dann AWS -Berechtigungen für die Container in einem beliebigen Pod bereitstellen, der dieses Servicekonto verwendet. Weitere Informationen finden Sie unter [IAM-Rollen für Servicekonten](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Wenn Sie diese Rollen noch nicht eingerichtet haben, folgen Sie den Anweisungen unter [Einrichten von Servicerollen für die Erfassung von Metriken aus Amazon-EKS-Clustern](set-up-irsa.md#set-up-irsa-ingest), um die Rollen einzurichten. Die Anweisungen in diesem Abschnitt erfordern die Verwendung von `eksctl`. Weitere Informationen finden Sie unter [Erste Schritte mit Amazon Elastic Kubernetes Service – `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html).
**Anmerkung**
Wenn Sie nicht auf EKS oder sind AWS und nur den Zugriffsschlüssel und den geheimen Schlüssel für den Zugriff auf Amazon Managed Service for Prometheus verwenden, können Sie das `EKS-IAM-ROLE` basierte SigV4 nicht verwenden.
## Schritt 4: Einrichten des neuen Servers und Beginn der Erfassung von Metriken
Gehen Sie wie folgt vor, um den neuen Prometheus-Server zu installieren, der Metriken an Ihren Workspace in Amazon Managed Service für Prometheus sendet.
**Um einen neuen Prometheus-Server zu installieren, um Metriken an Ihren Workspace in Amazon Managed Service für Prometheus zu senden**
1. Erstellen Sie mithilfe eines Texteditors eine Datei mit dem Namen `my_prometheus_values_yaml` mit folgenden Inhalten.
+ *IAM\$1PROXY\$1PROMETHEUS\$1ROLE\$1ARN*Ersetzen Sie es durch den ARN des **amp-iamproxy-ingest-role**, in dem Sie es erstellt haben[Einrichten von Servicerollen für die Erfassung von Metriken aus Amazon-EKS-Clustern](set-up-irsa.md#set-up-irsa-ingest).
+ *WORKSPACE\$1ID*Ersetzen Sie es durch die ID Ihres Amazon Managed Service for Prometheus-Workspace.
+ *REGION*Ersetzen Sie es durch die Region Ihres Amazon Managed Service for Prometheus-Workspace.
```
## The following is a set of default values for prometheus server helm chart which enable remoteWrite to AMP
## For the rest of prometheus helm chart values see: https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml
##
serviceAccounts:
server:
name: amp-iamproxy-ingest-service-account
annotations:
eks.amazonaws.com/role-arn: ${IAM_PROXY_PROMETHEUS_ROLE_ARN}
server:
remoteWrite:
- url: https://aps-workspaces.${REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write
sigv4:
region: ${REGION}
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
```
1. Geben Sie den folgenden Befehl ein, um den Prometheus-Server zu starten.
+ Ersetzen Sie *prometheus-chart-name* durch Ihren Prometheus-Versionsnamen.
+ Ersetzen Sie es *prometheus-namespace* durch den Namen Ihres Prometheus-Namespaces.
```
helm install prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace \
-f my_prometheus_values_yaml
```
**Anmerkung**
Sie können den `helm install`-Befehl auf viele Arten anpassen. Weitere Informationen finden Sie unter [Helm-Installation](https://helm.sh/docs/helm/helm_install/) in der *Helm-Dokumentation*.
# Richten Sie die Erfassung von einem vorhandenen Prometheus-Server in Kubernetes auf EC2 ein
Amazon Managed Service für Prometheus unterstützt die Erfassung von Metriken von Prometheus-Servern in Clustern, auf denen Amazon EKS ausgeführt wird, und in selbstverwalteten Kubernetes-Clustern, die auf Amazon EC2 ausgeführt werden. Die detaillierten Anweisungen in diesem Abschnitt beziehen sich auf einen Prometheus-Server in einem Amazon-EKS-Cluster. Die Schritte für einen selbstverwalteten Kubernetes-Cluster auf Amazon EC2 sind dieselben, mit der Ausnahme, dass Sie die OIDC-Anbieter- und IAM-Rollen für Servicekonten selbst im Kubernetes-Cluster einrichten müssen.
In den Anweisungen in diesem Abschnitt wird Helm als Kubernetes-Paketmanager verwendet.
**Topics**
+ [Schritt 1: Einrichten von IAM-Rollen für Servicekonten](#AMP-onboard-existing-Prometheus-IRSA)
+ [Schritt 2: Aktualisieren Sie Ihren vorhandenen Prometheus-Server mithilfe von Helm](#AMP-onboard-ingest-metrics-existing-remotewrite)
## Schritt 1: Einrichten von IAM-Rollen für Servicekonten
Für die Onboarding-Methode, die wir dokumentieren, müssen Sie IAM-Rollen für Servicekonten im Amazon-EKS-Cluster verwenden, in dem der Prometheus-Server läuft. Diese Rollen werden als *Servicerollen* bezeichnet.
Mit Servicerollen können Sie eine IAM-Rolle mit einem Kubernetes-Servicekonto verknüpfen. Dieses Dienstkonto kann dann AWS Berechtigungen für die Container in jedem Pod gewähren, der dieses Dienstkonto verwendet. Weitere Informationen finden Sie unter [IAM-Rollen für Servicekonten](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Wenn Sie diese Rollen noch nicht eingerichtet haben, folgen Sie den Anweisungen unter [Einrichten von Servicerollen für die Erfassung von Metriken aus Amazon-EKS-Clustern](set-up-irsa.md#set-up-irsa-ingest), um die Rollen einzurichten.
## Schritt 2: Aktualisieren Sie Ihren vorhandenen Prometheus-Server mithilfe von Helm
Die Anweisungen in diesem Abschnitt beinhalten die Einrichtung von Remote-Write und SigV4 zur Authentifizierung und Autorisierung des Prometheus-Servers für Remote–Write in Ihrem Workspace in Amazon Managed Service für Prometheus.
### Verwenden von Prometheus Version 2.26.0 oder höher
Gehen Sie wie folgt vor, wenn Sie einen Helm-Chart mit einem Prometheus Server-Image der Version 2.26.0 oder höher verwenden.
**So richten Sie Remote-Write von einem Prometheus-Server aus mithilfe von Helm-Chart ein**
1. Erstellen Sie einen neuen Remote-Write-Abschnitt in Ihrer Helm-Konfigurationsdatei:
+ `${IAM_PROXY_PROMETHEUS_ROLE_ARN}`Ersetzen Sie es durch den ARN des **amp-iamproxy-ingest-role**, in dem Sie es erstellt haben[Schritt 1: Einrichten von IAM-Rollen für Servicekonten](#AMP-onboard-existing-Prometheus-IRSA). Der Rollen-ARN sollte das Format `arn:aws:iam::your account ID:role/amp-iamproxy-ingest-role` haben.
+ Ersetzen Sie `${WORKSPACE_ID}` durch Ihre Workspace-ID von Amazon Managed Service für Prometheus.
+ Ersetzen Sie `${REGION}` durch die Region des Workspace in Amazon Managed Service für Prometheus (z. B. `us-west-2`).
```
## The following is a set of default values for prometheus server helm chart which enable remoteWrite to AMP
## For the rest of prometheus helm chart values see: https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml
##
serviceAccounts:
server:
name: amp-iamproxy-ingest-service-account
annotations:
eks.amazonaws.com/role-arn: ${IAM_PROXY_PROMETHEUS_ROLE_ARN}
server:
remoteWrite:
- url: https://aps-workspaces.${REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write
sigv4:
region: ${REGION}
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
```
1. Aktualisieren Sie Ihre bestehende Prometheus-Server-Konfiguration mit Helm:
+ Ersetzen Sie `prometheus-chart-name` durch Ihren Prometheus-Versionsnamen.
+ Ersetzen Sie `prometheus-namespace` durch den Kubernetes-Namespace, in dem Ihr Prometheus-Server installiert ist.
+ Ersetzen Sie `my_prometheus_values_yaml` durch den Pfad zu Ihrer Helm-Konfigurationsdatei.
+ Ersetzen Sie `current_helm_chart_version` durch die aktuelle Version Ihres Prometheus-Server-Helm-Charts. Sie können die aktuelle Chart-Version finden, indem Sie den Befehl [Helmliste](https://helm.sh/docs/helm/helm_list/) verwenden.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus \
-n prometheus-namespace \
-f my_prometheus_values_yaml \
--version current_helm_chart_version
```
### Verwenden früherer Versionen von Prometheus
Gehen Sie wie folgt vor, wenn Sie eine ältere Version von Prometheus als 2.26.0 verwenden. Bei diesen Schritten wird ein Sidecar-Ansatz verwendet, da frühere Versionen von Prometheus den Signaturprozess von AWS Signature Version 4 (Sigv4) nicht nativ unterstützen.AWS
Bei diesen Anleitungen wird davon ausgegangen, dass Sie Helm verwenden, um Prometheus bereitzustellen.
**So richten Sie Remote-Write von einem Prometheus-Server aus ein**
1. Erstellen Sie auf Ihrem Prometheus-Server eine neue Remote-Write-Konfiguration. Erstellen Sie zunächst eine neue Aktualisierungsdatei. Wir werden die Datei `amp_ingest_override_values.yaml` aufrufen.
Fügen Sie der YAML-Datei die folgenden Werte hinzu.
```
serviceAccounts:
server:
name: "amp-iamproxy-ingest-service-account"
annotations:
eks.amazonaws.com/role-arn: "${SERVICE_ACCOUNT_IAM_INGEST_ROLE_ARN}"
server:
sidecarContainers:
- name: aws-sigv4-proxy-sidecar
image: public.ecr.aws/aws-observability/aws-sigv4-proxy:1.0
args:
- --name
- aps
- --region
- ${REGION}
- --host
- aps-workspaces.${REGION}.amazonaws.com
- --port
- :8005
ports:
- name: aws-sigv4-proxy
containerPort: 8005
statefulSet:
enabled: "true"
remoteWrite:
- url: http://localhost:8005/workspaces/${WORKSPACE_ID}/api/v1/remote_write
```
Ersetzen Sie `${REGION}` durch die Region des Workspace in Amazon Managed Service für Prometheus.
`${SERVICE_ACCOUNT_IAM_INGEST_ROLE_ARN}`Ersetzen Sie es durch den ARN des **amp-iamproxy-ingest-role**, in dem Sie es erstellt haben[Schritt 1: Einrichten von IAM-Rollen für Servicekonten](#AMP-onboard-existing-Prometheus-IRSA). Der Rollen-ARN sollte das Format `arn:aws:iam::your account ID:role/amp-iamproxy-ingest-role` haben.
Ersetzen Sie `${WORKSPACE_ID}` durch Ihre Workspace-ID.
1. Aktualisieren Sie Ihr Prometheus Helm-Chart. Suchen Sie zunächst nach dem Namen Ihres Helm-Charts, indem Sie den folgenden Befehl eingeben. Suchen Sie in der Ausgabe dieses Befehls nach einem Chart mit einem Namen, der `prometheus` enthält:
```
helm ls --all-namespaces
```
Geben Sie dann den folgenden Befehl ein.
```
helm upgrade --install prometheus-helm-chart-name prometheus-community/prometheus -n prometheus-namespace -f ./amp_ingest_override_values.yaml
```
*prometheus-helm-chart-name*Ersetzen Sie es durch den Namen der Prometheus-Helmkarte, die im vorherigen Befehl zurückgegeben wurde. Ersetzen Sie *prometheus-namespace* durch den Namen Ihres Namespaces.
#### Helm-Charts werden heruntergeladen
Wenn Sie Helm-Charts noch nicht lokal heruntergeladen haben, können Sie sie mit dem folgenden Befehl herunterladen.
```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm pull prometheus-community/prometheus --untar
```
# Richten Sie die Erfassung von einem vorhandenen Prometheus-Server in Kubernetes auf Fargate ein
Amazon Managed Service für Prometheus unterstützt die Erfassung von Metriken von Prometheus-Servern in selbstverwalteten Kubernetes-Clustern, die auf Fargate ausgeführt werden. Um Metriken von Prometheus-Servern in Amazon-EKS-Clustern zu erfassen, die auf Fargate laufen, überschreiben Sie die Standardkonfigurationen in einer Konfigurationsdatei mit dem Namen amp\$1ingest\$1override\$1values.yaml wie folgt:
```
prometheus-node-exporter:
enabled: false
alertmanager:
enabled: false
serviceAccounts:
server:
name: amp-iamproxy-ingest-service-account
annotations:
eks.amazonaws.com/role-arn: ${IAM_PROXY_PROMETHEUS_ROLE_ARN}
server:
persistentVolume:
enabled: false
remoteWrite:
- url: https://aps-workspaces.${REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write
sigv4:
region: ${REGION}
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
```
Installieren Sie Prometheus mithilfe der Overrides mit dem folgenden Befehl:
```
helm install prometheus-for-amp prometheus-community/prometheus \
-n prometheus \
-f amp_ingest_override_values.yaml
```
Beachten Sie, dass wir in der Helm-Chart-Konfiguration den Node Exporter und den Alert Manager deaktiviert und die Prometheus-Serverbereitstellung ausgeführt haben.
Sie können die Installation mit der folgenden Beispiel-Testabfrage überprüfen.
```
$ awscurl --region region --service aps "https://aps-workspaces.region_id.amazonaws.com/workspaces/workspace_id/api/v1/query?query=prometheus_api_remote_read_queries"
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"prometheus_api_remote_read_queries","instance":"localhost:9090","job":"prometheus"},"value":[1648461236.419,"0"]}]}}21
```
# Amazon Managed Service für Prometheus für Hochverfügbarkeitsdaten einrichten
Wenn Sie Daten an Amazon Managed Service für Prometheus senden, werden sie automatisch in AWS Availability Zones in der Region repliziert und Ihnen von einem Host-Cluster bereitgestellt, der Skalierbarkeit, Verfügbarkeit und Sicherheit bietet. Je nach Ihrer speziellen Konfiguration möchten Sie möglicherweise zusätzliche Ausfallsicherungen für hohe Verfügbarkeit hinzufügen. Es gibt zwei gängige Methoden, wie Sie Ihrem Setup zusätzliche Sicherheitsfunktionen für hohe Verfügbarkeit hinzufügen können:
+ Wenn Sie mehrere Container oder Instances mit denselben Daten haben, können Sie diese Daten an Amazon Managed Service für Prometheus senden und die Daten automatisch deduplizieren lassen. Dadurch wird sichergestellt, dass Ihre Daten an Ihren Workspace in Amazon Managed Service für Prometheus gesendet werden.
Weitere Informationen zur Deduplizierung von Hochverfügbarkeitsdaten finden Sie unter [Deduplizierung von Hochverfügbarkeitsmetriken, die an Amazon Managed Service für Prometheus gesendet werden](AMP-ingest-dedupe.md).
+ Wenn Sie sicherstellen möchten, dass Sie Zugriff auf Ihre Daten haben, auch wenn die Region AWS nicht verfügbar ist, können Sie Ihre Metriken an einen zweiten Workspace in einer anderen Region senden.
Weitere Informationen zum Senden von Metrikdaten an mehrere Workspaces finden Sie unter [Verwenden Sie regionsübergreifende Workspaces, um Hochverfügbarkeit in Amazon Managed Service for Prometheus hinzuzufügen](AMP-send-to-multiple-workspaces.md).
**Topics**
+ [Deduplizierung von Hochverfügbarkeitsmetriken, die an Amazon Managed Service für Prometheus gesendet werden](AMP-ingest-dedupe.md)
+ [Senden Sie mit Prometheus Hochverfügbarkeitsdaten an Amazon Managed Service für Prometheus](Send-high-availability-data.md)
+ [Richten Sie mithilfe des Prometheus Operator Helm-Diagramms Hochverfügbarkeitsdaten für Amazon Managed Service for Prometheus ein](Send-high-availability-data-operator.md)
+ [Senden Sie Daten mit hoher Verfügbarkeit an Amazon Managed Service for Prometheus mit Distro für AWS OpenTelemetry](Send-high-availability-data-ADOT.md)
+ [Mit dem Prometheus-Community-Helm-Chart Hochverfügbarkeitsdaten an Amazon Managed Service für Prometheus senden](Send-high-availability-prom-community.md)
+ [Antworten auf häufig gestellte Fragen zur Hochverfügbarkeitskonfiguration in Amazon Managed Service for Prometheus](HA_FAQ.md)
+ [Verwenden Sie regionsübergreifende Workspaces, um Hochverfügbarkeit in Amazon Managed Service for Prometheus hinzuzufügen](AMP-send-to-multiple-workspaces.md)
# Deduplizierung von Hochverfügbarkeitsmetriken, die an Amazon Managed Service für Prometheus gesendet werden
Sie können Daten von mehreren Prometheus-*Agenten* (Prometheus-Instances, die im Agentenmodus ausgeführt werden) an Ihren Workspace in Amazon Managed Service für Prometheus senden. Wenn einige dieser Instances dieselben Metriken aufzeichnen und senden, haben Ihre Daten eine höhere Verfügbarkeit (auch wenn einer der Agenten keine Daten mehr sendet, empfängt der Workspace in Amazon Managed Service für Prometheus die Daten immer noch von einer anderen Instance). Sie möchten jedoch, dass Ihr Workspace in Amazon Managed Service für Prometheus die Metriken automatisch dedupliziert, sodass Sie die Metriken nicht mehrfach sehen und Ihnen nicht die mehrfache Datenerfassung und Speicherung in Rechnung gestellt werden.
Damit Amazon Managed Service für Prometheus automatisch Daten von mehreren Prometheus-Agenten deduplizieren kann, geben Sie der Gruppe von Agenten, die die doppelten Daten senden, einen einzelnen *Clusternamen* und jeder der Instances einen *Replikatnamen*. Der Clustername identifiziert, dass die Instances gemeinsam genutzte Daten haben, und der Replikatname ermöglicht es Amazon Managed Service für Prometheus, die Quelle jeder Metrik zu identifizieren. Die endgültigen gespeicherten Metriken beinhalten das Cluster-Etikett, nicht aber das Replikat. Die Metriken scheinen also aus einer einzigen Quelle zu stammen.
**Anmerkung**
Bestimmte Versionen von Kubernetes (1.28 und 1.29) geben möglicherweise ihre eigene Metrik mit einer Bezeichnung aus. `cluster` Dies kann zu Problemen mit der Amazon Managed Service for Prometheus-Deduplizierung führen. Weitere Informationen finden Sie in den [häufig gestellten Fragen zur Hochverfügbarkeit](HA_FAQ.md#HA_FAQ_cluster-label).
In den folgenden Themen wird gezeigt, wie Daten gesendet `cluster` und die `__replica__` Labels hinzugefügt werden, sodass Amazon Managed Service for Prometheus die Daten automatisch dedupliziert.
**Wichtig**
Wenn Sie keine Deduplizierung einrichten, werden Ihnen alle Datenbeispiele in Rechnung gestellt, die an Amazon Managed Service für Prometheus gesendet werden. Diese Datenbeispiele enthalten doppelte Beispiele.
# Senden Sie mit Prometheus Hochverfügbarkeitsdaten an Amazon Managed Service für Prometheus
Um eine Hochverfügbarkeitskonfiguration mit Prometheus einzurichten, müssen Sie externe Etiketten auf allen Instances einer Hochverfügbarkeitsgruppe anbringen, damit Amazon Managed Service für Prometheus sie identifizieren kann. Verwenden Sie das `cluster` Etikett, um einen Prometheus-Instance-Agenten als Teil einer Hochverfügbarkeitsgruppe zu identifizieren. Verwenden Sie das `__replica__` Etikett, um jedes Replikat in der Gruppe separat zu identifizieren. Sie müssen `__replica__` und `cluster` Etiketten anbringen, damit die Deduplizierung funktioniert.
**Anmerkung**
Das `__replica__` Etikett ist mit zwei Unterstrichen vor und nach dem Wort `replica` formatiert.
**Beispiel: Codeausschnitte**
In den folgenden Codeausschnitten identifiziert das `cluster`-Etiketten den Prometheus-Instance-Agenten `prom-team1` und das `_replica_`-Etikett identifiziert die Replikate `replica1` und `replica2`.
```
cluster: prom-team1
__replica__: replica1
```
```
cluster: prom-team1
__replica__: replica2
```
Da Amazon Managed Service für Prometheus Datenbeispiele von Hochverfügbarkeitsreplikaten mit diesen Etiketten speichert, entfernt es das `replica`-Etikett, wenn die Beispiele akzeptiert werden. Das bedeutet, dass Sie für Ihre aktuelle Serie nur ein 1:1 -Serien-Mapping haben werden und nicht eine Serie pro Replikat. Das `cluster` Etikett wird beibehalten.
**Anmerkung**
Bestimmte Versionen von Kubernetes (1.28 und 1.29) geben möglicherweise ihre eigene Metrik mit einer Bezeichnung aus. `cluster` Dies kann zu Problemen mit der Amazon Managed Service for Prometheus-Deduplizierung führen. Weitere Informationen finden Sie in den [häufig gestellten Fragen zur Hochverfügbarkeit](HA_FAQ.md#HA_FAQ_cluster-label).
# Richten Sie mithilfe des Prometheus Operator Helm-Diagramms Hochverfügbarkeitsdaten für Amazon Managed Service for Prometheus ein
Um eine Hochverfügbarkeitskonfiguration mit dem Prometheus-Operator in Helm einzurichten, müssen Sie externe Labels auf allen Instances einer Hochverfügbarkeitsgruppe anbringen, damit Amazon Managed Service for Prometheus sie identifizieren kann. Sie müssen auch die Attribute `replicaExternalLabelName` und `externalLabels` im Prometheus-Operator-Helm-Chart festlegen.
**Beispiel: YAML-Header**
Im folgenden YAML-Header `cluster` wird `externalLabel` hinzugefügt, um einen Prometheus-Instance-Agenten als Teil einer Hochverfügbarkeitsgruppe zu identifizieren, und `replicaExternalLabels` identifiziert jedes Replikat in der Gruppe.
```
replicaExternalLabelName: __replica__
externalLabels:
cluster: prom-dev
```
**Anmerkung**
Bestimmte Versionen von Kubernetes (1.28 und 1.29) geben möglicherweise ihre eigene Metrik mit einem Label aus. `cluster` Dies kann zu Problemen mit der Amazon Managed Service for Prometheus-Deduplizierung führen. Weitere Informationen finden Sie in den [häufig gestellten Fragen zur Hochverfügbarkeit](HA_FAQ.md#HA_FAQ_cluster-label).
# Senden Sie Daten mit hoher Verfügbarkeit an Amazon Managed Service for Prometheus mit Distro für AWS OpenTelemetry
AWS Distro for OpenTelemetry (ADOT) ist eine sichere und produktionsbereite Distribution des Projekts. OpenTelemetry ADOT stellt Ihnen Quellcode APIs, Bibliotheken und Agenten zur Verfügung, sodass Sie verteilte Traces und Metriken für die Anwendungsüberwachung sammeln können. Informationen zu ADOT finden Sie unter [Über AWS Distro for](https://aws-otel.github.io/about) Open Telemetry.
Um ADOT mit einer Hochverfügbarkeitskonfiguration einzurichten, müssen Sie ein ADOT-Collector-Container-Image konfigurieren und die externen Labels `cluster` auf den AWS Prometheus `__replica__` Remote Write Exporter anwenden. Dieser Exporter sendet Ihre gesammelten Metriken über den `remote_write`-Endpunkt an Ihren Workspace in Amazon Managed Service für Prometheus. Wenn Sie diese Etiketten auf dem Remote Write-Exporter einrichten, verhindern Sie, dass doppelte Metriken gespeichert werden, während redundante Replikate ausgeführt werden. Weitere Informationen zum AWS Prometheus Remote Write Exporter finden Sie unter [Erste Schritte mit dem Prometheus Remote Write Exporter für Amazon Managed Service for Prometheus](https://aws-otel.github.io/docs/getting-started/prometheus-remote-write-exporter).
**Anmerkung**
Bestimmte Versionen von Kubernetes (1.28 und 1.29) geben möglicherweise ihre eigene Metrik mit einer Bezeichnung aus. `cluster` Dies kann zu Problemen mit der Amazon Managed Service for Prometheus-Deduplizierung führen. Weitere Informationen finden Sie in den [häufig gestellten Fragen zur Hochverfügbarkeit](HA_FAQ.md#HA_FAQ_cluster-label).
# Mit dem Prometheus-Community-Helm-Chart Hochverfügbarkeitsdaten an Amazon Managed Service für Prometheus senden
Um eine Hochverfügbarkeitskonfiguration mit dem Prometheus-Community-Helm-Chart einzurichten, müssen Sie externe Etiketten auf allen Instances einer Hochverfügbarkeitsgruppe anbringen, damit Amazon Managed Service für Prometheus sie identifizieren kann. Hier ist ein Beispiel dafür, wie Sie `external_labels` zur einer einzelnen Instance von Prometheus aus dem Helm-Chart aus der Prometheus-Community hinzufügen könnten.
```
server:
global:
external_labels:
cluster: monitoring-cluster
__replica__: replica-1
```
**Anmerkung**
Wenn Sie mehrere Replikate benötigen, müssen Sie das Diagramm mehrmals mit unterschiedlichen Replikatwerten bereitstellen, da Sie mit dem Helm-Chart der Prometheus-Community den Replikatwert nicht dynamisch festlegen können, wenn Sie die Anzahl der Replikate direkt von der Controller-Gruppe aus erhöhen. Wenn Sie es vorziehen, dass das `replica` Etikett automatisch festgelegt wird, verwenden Sie das Helm-Chart des Prometheus-Operators.
**Anmerkung**
Bestimmte Versionen von Kubernetes (1.28 und 1.29) geben möglicherweise ihre eigene Metrik mit einer Bezeichnung aus. `cluster` Dies kann zu Problemen mit der Amazon Managed Service for Prometheus-Deduplizierung führen. Weitere Informationen finden Sie in den [häufig gestellten Fragen zur Hochverfügbarkeit](HA_FAQ.md#HA_FAQ_cluster-label).
# Antworten auf häufig gestellte Fragen zur Hochverfügbarkeitskonfiguration in Amazon Managed Service for Prometheus
## Sollte ich den Wert *\$1\$1replica\$1\$1* in ein anderes Label aufnehmen, um die Probenahmepunkte nachzuverfolgen?
In einer Hochverfügbarkeitsumgebung stellt Amazon Managed Service für Prometheus sicher, dass Datenbeispiele nicht dupliziert werden, indem ein führender Anbieter im Cluster von Prometheus-Instances ausgewählt wird. Wenn das Leader-Replikat 30 Sekunden lang keine Datenbeispiele mehr sendet, macht Amazon Managed Service für Prometheus automatisch eine andere Prometheus-Instance zu einem Leader-Replikat und erfasst Daten vom neuen Leader-Replikat, einschließlich aller fehlenden Daten. Daher lautet die Antwort nein, es wird nicht empfohlen. Dies kann zu folgenden Problemen führen:
+ Die Abfrage von `count` in **PromQL** kann während der Zeit der Wahl eines neuen Leaders zu einem höheren Wert als erwartet führen.
+ Die Anzahl von `active series` wird während der Wahl eines neuen Leaders erhöht und erreicht `active series limits`. Weitere Informationen finden Sie unter [AMP-Quoten](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html).
## Kubernetes scheint ein eigenes *Cluster-Label* zu haben und dedupliziert meine Metriken nicht. Wie lässt sich dieses Problem beheben?
In Kubernetes 1.28 `apiserver_storage_size_bytes` wurde eine neue Metrik mit einem Label eingeführt. `cluster` Dies kann zu Problemen mit der Deduplizierung in Amazon Managed Service for Prometheus führen, die vom Label abhängen. `cluster` In Kubernetes 1.3 wurde das Label umbenannt in `storage-cluster_id` (es wurde auch in späteren Patches von 1.28 und 1.29 umbenannt). Wenn Ihr Cluster diese Metrik mit dem `cluster` Label ausgibt, kann Amazon Managed Service for Prometheus die zugehörige Zeitreihe nicht deduplizieren. Wir empfehlen Ihnen, Ihren Kubernetes-Cluster auf die neueste gepatchte Version zu aktualisieren, um dieses Problem zu vermeiden. Alternativ können Sie das `cluster` Etikett auf Ihrer `apiserver_storage_size_bytes` Metrik neu etikettieren, bevor Sie sie in Amazon Managed Service for Prometheus aufnehmen.
**Anmerkung**
*Weitere Informationen zur Umstellung auf Kubernetes finden Sie im Kubernetes-Projekt unter [Label-Cluster in storage\$1cluster\$1id für die Metrik apiserver\$1storage\$1size\$1bytes umbenennen](https://github.com/kubernetes/kubernetes/pull/124283). GitHub*
# Verwenden Sie regionsübergreifende Workspaces, um Hochverfügbarkeit in Amazon Managed Service for Prometheus hinzuzufügen
Um Ihre Daten regionsübergreifend verfügbar zu machen, können Sie Messwerte an mehrere Workspaces in verschiedenen Regionen senden. AWS Prometheus unterstützt sowohl das Schreiben mehrerer Autoren als auch regionsübergreifendes Schreiben.
Das folgende Beispiel zeigt, wie Sie einen Prometheus-Server einrichten, der im Agent-Modus läuft, um mit Helm Metriken an zwei Workspaces in verschiedenen Regionen zu senden.
```
extensions:
sigv4auth:
service: "aps"
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'kubernetes-kubelet'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc.cluster.local:443
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/$${1}/proxy/metrics
exporters:
prometheusremotewrite/one:
endpoint: "https://aps-workspaces.workspace_1_region.amazonaws.com/workspaces/ws-workspace_1_id/api/v1/remote_write"
auth:
authenticator: sigv4auth
prometheusremotewrite/two:
endpoint: "https://aps-workspaces.workspace_2_region.amazonaws.com/workspaces/ws-workspace_2_id/api/v1/remote_write"
auth:
authenticator: sigv4auth
service:
extensions: [sigv4auth]
pipelines:
metrics/one:
receivers: [prometheus]
exporters: [prometheusremotewrite/one]
metrics/two:
receivers: [prometheus]
exporters: [prometheusremotewrite/two]
```