Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Collecteurs gérés par le client
Cette section contient des informations sur l’ingestion de données en configurant vos propres collecteurs qui envoient des métriques à Amazon Managed Service for Prometheus à l’aide de l’écriture à distance Prometheus.
Lorsque vous utilisez vos propres collecteurs pour envoyer des métriques à Amazon Managed Service for Prometheus, il vous incombe de sécuriser vos métriques et de vous assurer que le processus d’ingestion répond à vos besoins de disponibilité.
La plupart des collecteurs gérés par le client utilisent l’un des outils suivants :
+ **AWS Distro for OpenTelemetry (ADOT) — ADOT** est une distribution open source entièrement prise en charge, sécurisée et prête à la production OpenTelemetry qui permet aux agents de collecter des métriques. Vous pouvez utiliser ADOT pour collecter des métriques et les envoyer à votre espace de travail Amazon Managed Service for Prometheus. Pour plus d'informations sur le collecteur ADOT, voir [AWS Distro](https://aws.amazon.com/otel/) for. OpenTelemetry
+ **Agent Prometheus** – Vous pouvez configurer votre propre instance du serveur Prometheus open source, exécuté en tant qu’agent, pour collecter des métriques et les transmettre à votre espace de travail Amazon Managed Service for Prometheus.
Les rubriques suivantes décrivent l’utilisation de ces deux outils et incluent des informations générales sur la configuration de vos propres collecteurs.
**Topics**
+ [Sécurisation de l’ingestion de vos métriques](AMP-secure-metric-ingestion.md)
+ [Utiliser AWS Distro pour en OpenTelemetry tant que collectionneur](AMP-ingest-with-adot.md)
+ [Utilisation d’une instance Prometheus comme collecteur](AMP-ingest-with-prometheus.md)
+ [Configurer Amazon Managed Service pour Prometheus pour garantir la haute disponibilité des données](AMP-ingest-high-availability.md)
# Sécurisation de l’ingestion de vos métriques
Amazon Managed Service for Prometheus vous aide à sécuriser l’ingestion de vos métriques.
## Utilisation AWS PrivateLink avec Amazon Managed Service pour Prometheus
Le trafic réseau lié à l'ingestion des métriques dans Amazon Managed Service for Prometheus peut être effectué via un point de terminaison Internet public ou via un point de terminaison VPC via. AWS PrivateLink L'utilisation AWS PrivateLink garantit que le trafic réseau provenant de votre réseau VPCs est sécurisé sur le AWS réseau sans passer par l'Internet public. Pour créer un point de terminaison AWS PrivateLink VPC pour Amazon Managed Service for Prometheus, consultez. [Utilisation d’Amazon Managed Service for Prometheus avec des points de terminaison de VPC d’interface](AMP-and-interface-VPC.md)
## Authentification et autorisation
AWS Identity and Access Management (IAM) est un service Web qui vous permet de contrôler en toute sécurité l'accès aux ressources. AWS Vous pouvez utiliser IAM pour contrôler les personnes qui s’authentifient (sont connectées) et sont autorisées (disposent d’autorisations) à utiliser des ressources. Amazon Managed Service for Prometheus s’intègre à IAM pour vous aider à protéger vos données. Lorsque vous configurez Amazon Managed Service for Prometheus, vous devez créer des rôles IAM qui lui permettent d’ingérer des métriques des serveurs Prometheus et qui permettent aux serveurs Grafana d’interroger les métriques stockées dans vos espaces de travail Amazon Managed Service for Prometheus. Pour plus d’informations sur IAM, consultez [En quoi consiste IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html).
Une autre fonctionnalité AWS de sécurité qui peut vous aider à configurer Amazon Managed Service pour Prometheus est AWS le processus AWS de signature Signature Version 4 (SigV4). Signature Version 4 est le processus permettant d'ajouter des informations d'authentification aux AWS demandes envoyées par HTTP. Pour des raisons de sécurité, la plupart des demandes AWS doivent être signées avec une clé d'accès, qui consiste en un identifiant de clé d'accès et une clé d'accès secrète. Ces deux clés sont généralement appelées informations d’identification de sécurité. Pour plus d’informations sur SigV4, consultez la section [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html).
# Utiliser AWS Distro pour en OpenTelemetry tant que collectionneur
Cette section décrit comment configurer le collecteur AWS Distro for OpenTelemetry (ADOT) pour qu'il soit extrait d'une application instrumentée par Prometheus et envoie les métriques à Amazon Managed Service for Prometheus. Pour plus d'informations sur le collecteur ADOT, voir [AWS Distro](https://aws.amazon.com/otel/) for. OpenTelemetry
Les rubriques suivantes décrivent trois manières différentes de configurer ADOT en tant que collecteur pour vos métriques, selon que celles-ci proviennent d'Amazon EKS, d'Amazon ECS ou d'une instance Amazon EC2.
**Topics**
+ [Configurer l'ingestion de métriques à l'aide de AWS Distro pour un OpenTelemetry cluster Amazon Elastic Kubernetes Service](AMP-onboard-ingest-metrics-OpenTelemetry.md)
+ [Configurer l'ingestion de métriques depuis Amazon ECS à l'aide de AWS Distro for Open Telemetry](AMP-onboard-ingest-metrics-OpenTelemetry-ECS.md)
+ [Configuration de l’ingestion de métriques à partir d’une instance Amazon EC2 à l’aide de l’écriture à distance](AMP-onboard-ingest-metrics-remote-write-EC2.md)
# Configurer l'ingestion de métriques à l'aide de AWS Distro pour un OpenTelemetry cluster Amazon Elastic Kubernetes Service
Vous pouvez utiliser le collecteur AWS Distro for OpenTelemetry (ADOT) pour extraire les métriques d'une application instrumentée par Prometheus et les envoyer à Amazon Managed Service for Prometheus.
**Note**
Pour plus d'informations sur le collecteur ADOT, consultez [AWS Distro](https://aws.amazon.com/otel/) for. OpenTelemetry
Pour plus d'informations sur les applications instrumentées par Prometheus, consultez. [Quelles sont les métriques compatibles avec Prometheus ?](prom-compatible-metrics.md)
La collecte des métriques Prometheus avec ADOT implique trois OpenTelemetry composants : le récepteur Prometheus, l'exportateur d'écriture à distance Prometheus et l'extension d'authentification Sigv4.
Vous pouvez configurer Prometheus Receiver à l’aide de votre configuration Prometheus existante pour effectuer la découverte de service et la collecte des métriques. Prometheus Receiver collecte des métriques dans le format d’exposition Prometheus. Toutes les applications ou points de terminaison que vous souhaitez collecter doivent être configurés avec la bibliothèque client Prometheus. Prometheus Receiver prend en charge l’ensemble complet des configurations de collecte et de réétiquetage de Prometheus décrites dans la section [Configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) de la documentation Prometheus. Vous pouvez coller ces configurations directement dans les configurations de votre collecteur ADOT.
Prometheus Remote Write Exporter utilise le point de terminaison `remote_write` pour envoyer les métriques collectées à l’espace de travail de votre portail de gestion. Les demandes HTTP pour exporter des données seront signées avec AWS Sigv4, le AWS protocole d'authentification sécurisée, avec l'extension d'authentification Sigv4. Pour plus d'informations, consultez [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html).
Le collecteur reconnaît automatiquement les points de terminaison des métriques Prometheus sur Amazon EKS et utilise la configuration trouvée dans [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config).
La démonstration suivante est un exemple de cette configuration sur un cluster exécutant Amazon Elastic Kubernetes Service ou Kubernetes autogéré. Pour effectuer ces étapes, vous devez disposer AWS d'informations d'identification provenant de l'une des options potentielles de la chaîne AWS d'informations d'identification par défaut. Pour plus d'informations, consultez [Configuration du AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). Cette démonstration utilise un exemple d’application qui est utilisé pour les tests d’intégration du processus. L’exemple d’application expose les métriques au niveau du point de terminaison `/metrics`, comme la bibliothèque client Prometheus.
## Conditions préalables
Avant de commencer les étapes de configuration d’ingestion suivantes, vous devez configurer votre rôle IAM pour le compte de service et la politique d’approbation.
**Pour configurer le rôle IAM pour le compte de service et la politique d’approbation**
1. Créez le rôle IAM pour le compte de service en suivant les étapes décrites dans [Configuration de rôles de service pour l’ingestion de métriques à partir de clusters Amazon EKS](set-up-irsa.md#set-up-irsa-ingest).
Le collecteur ADOT utilisera ce rôle lorsqu’il collectera et exportera des métriques.
1. Modifiez ensuite la politique d’approbation. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/home).
1. Dans le volet de navigation de gauche, choisissez **Rôles** et recherchez ceux **amp-iamproxy-ingest-role**que vous avez créés à l'étape 1.
1. Choisissez l’onglet **Relations d’approbation**, puis **Modifier la relation d’approbation**.
1. Dans le JSON de la politique de relation d’approbation, remplacez `aws-amp` par `adot-col`, puis choisissez **Update Trust Policy**. La politique d’approbation obtenue doit être similaire à ce qui suit :
------
#### [ 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. Choisissez l’onglet **Autorisations** et assurez-vous que la politique d’autorisations suivante est associée au rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aps:RemoteWrite",
"aps:GetSeries",
"aps:GetLabels",
"aps:GetMetricMetadata"
],
"Resource": "*"
}
]
}
```
------
## Activation de la collecte de métriques Prometheus
**Note**
Lorsque vous créez un espace de noms dans Amazon EKS, `alertmanager` l’exportateur de nœuds sont désactivés par défaut.
**Pour activer la collecte Prometheus sur un cluster Amazon EKS ou Kubernetes**
1. Forkez et clonez l'exemple d'application depuis le référentiel à l'adresse [aws-otel-community](https://github.com/aws-observability/aws-otel-community).
Exécutez ensuite les commandes suivantes.
```
cd ./sample-apps/prometheus-sample-app
docker build . -t prometheus-sample-app:latest
```
1. Transférez cette image vers un registre tel qu'Amazon ECR ou DockerHub.
1. Déployez l’exemple d’application dans le cluster en copiant cette configuration Kubernetes et en l’appliquant. Remplacez l’image par celle que vous venez d’envoyer en remplaçant `{{PUBLIC_SAMPLE_APP_IMAGE}}` dans le fichier `prometheus-sample-app.yaml`.
```
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. Exécutez la commande suivante pour vérifier que l’exemple d’application a démarré. Dans la sortie de la commande, `prometheus-sample-app` apparaît dans la colonne `NAME`.
```
kubectl get all -n aoc-prometheus-pipeline-demo
```
1. Démarrez une instance par défaut du collecteur ADOT. Pour ce faire, commencez par entrer la commande suivante pour extraire la configuration Kubernetes du collecteur ADOT.
```
curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/examples/eks/aws-prometheus/prometheus-daemonset.yaml -o prometheus-daemonset.yaml
```
Modifiez ensuite le fichier modèle en remplaçant le point de terminaison **remote\$1write** de votre espace de travail Amazon Managed Service for Prometheus par `YOUR_ENDPOINT` et votre région par `YOUR_REGION`. Utilisez le point de terminaison **remote\$1write** affiché dans la console Amazon Managed Service for Prometheus lorsque vous consultez les détails de votre espace de travail.
`YOUR_ACCOUNT_ID`Dans la section du compte de service de la configuration de Kubernetes, vous devrez également remplacer votre AWS identifiant de compte.
Dans cet exemple, la configuration du collecteur ADOT utilise une annotation (`scrape=true`) pour indiquer les points de terminaison cible à collecter. Cela permet au collecteur ADOT de distinguer le point de terminaison de l’exemple d’application des points de terminaison kube-system dans votre cluster. Vous pouvez le supprimer des configurations de réétiquetage si vous souhaitez récupérer un autre exemple d’application.
1. Entrez la commande suivante pour déployer le collecteur ADOT.
```
kubectl apply -f prometheus-daemonset.yaml
```
1. Exécutez la commande suivante pour vérifier que le collecteur ADOT a démarré. Recherchez `adot-col` dans la colonne `NAMESPACE`.
```
kubectl get pods -n adot-col
```
1. Vérifiez que le pipeline fonctionne à l’aide de l’exportateur de journalisation. Notre exemple de modèle est déjà intégré à l’exportateur de journalisation. Entrez les commandes suivantes :
```
kubectl get pods -A
kubectl logs -n adot-col name_of_your_adot_collector_pod
```
Certaines des métriques collectées de l’exemple d’application ressembleront à celles de l’exemple suivant.
```
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. Pour vérifier si Amazon Managed Service for Prometheus a reçu les statistiques, utilisez `awscurl`. [Cet outil vous permet d'envoyer des requêtes HTTP via la ligne de commande avec l'authentification AWS Sigv4. Vous devez donc disposer d'informations d' AWS identification configurées localement avec les autorisations appropriées pour effectuer des requêtes auprès d'Amazon Managed Service for Prometheus. Pour obtenir des instructions sur `awscurl` l'installation, consultez awscurl.](https://github.com/okigan/awscurl)
Dans la commande suivante, remplacez `AMP_REGION` et `AMP_ENDPOINT` par les informations relatives à votre espace de travail Amazon Managed Service for Prometheus.
```
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"]}]}}
```
Si vous recevez une métrique en réponse, cela signifie que la configuration de votre pipeline est réussie et que la métrique s’est propagée avec succès depuis l’exemple d’application dans Amazon Managed Service for Prometheus.
**Nettoyage**
Pour nettoyer cette démo, entrez les commandes suivantes.
```
kubectl delete namespace aoc-prometheus-pipeline-demo
kubectl delete namespace adot-col
```
## Configuration avancée
Prometheus Receiver prend en charge l’ensemble complet des configurations de collecte et de réétiquetage de Prometheus décrites dans la section [Configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) de la documentation Prometheus. Vous pouvez coller ces configurations directement dans les configurations de votre collecteur ADOT.
La configuration de Prometheus Receiver inclut vos configurations de découverte de service, de collecte et de réétiquetage. La configuration du récepteur ressemble à ce qui suit.
```
receivers:
prometheus:
config:
[[Your Prometheus configuration]]
```
Voici un exemple de configuration.
```
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
```
Si vous disposez d’une configuration Prometheus existante, vous devez remplacer les caractères `$` par les caractères `$$` pour éviter que les valeurs soient remplacées par des variables d’environnement. \$1Ceci est particulièrement important pour la valeur de remplacement de relabel\$1configurations. Par exemple, si vous commencez par la configuration relabel\$1configuration suivante :
```
relabel_configs:
- source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
regex: (.+);(.+);(.+)
replacement: ${1}://${2}${3}
target_label: __param_target
```
Elle deviendra :
```
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 et SigV4 Authentication Extension**
Les configurations de Prometheus Remote Write Exporter et Sigv4 Authentication Extension sont plus simples que celle de Prometheus Receiver. À ce stade du pipeline, les métriques ont déjà été ingérées et nous sommes prêts à exporter ces données dans Amazon Managed Service for Prometheus. L’exemple suivant montre la configuration minimale requise pour communiquer avec Amazon Managed Service for Prometheus.
```
extensions:
sigv4auth:
service: "aps"
region: "user-region"
exporters:
prometheusremotewrite:
endpoint: "https://aws-managed-prometheus-endpoint/api/v1/remote_write"
auth:
authenticator: "sigv4auth"
```
Cette configuration envoie une demande HTTPS signée par AWS SigV4 à l'aide des AWS informations d'identification de la chaîne d'informations AWS d'identification par défaut. Pour plus d’informations, consultez [Configuration de l’ AWS SDK pour Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). Vous devez spécifier le service `aps`.
Quelle que soit la méthode de déploiement, le collecteur ADOT doit avoir accès à l'une des options répertoriées dans la chaîne d' AWS informations d'identification par défaut. L'extension d'authentification Sigv4 dépend de AWS SDK pour Go et l'utilise pour récupérer les informations d'identification et s'authentifier. Vous devez vous assurer que ces informations d’identification disposent d’autorisations d’écriture à distance pour Amazon Managed Service for Prometheus.
# Configurer l'ingestion de métriques depuis Amazon ECS à l'aide de AWS Distro for Open Telemetry
Cette section explique comment collecter des métriques depuis Amazon Elastic Container Service (Amazon ECS) et les intégrer dans Amazon Managed Service for Prometheus à l' AWS aide de Distro for Open Telemetry (ADOT). Elle décrit également comment visualiser vos métriques dans Amazon Managed Grafana.
## Conditions préalables
**Important**
Avant de commencer, vous devez disposer d’un environnement Amazon ECS sur un cluster AWS Fargate avec des paramètres par défaut, d’un espace de travail Amazon Managed Service for Prometheus et d’un espace de travail Amazon Managed Grafana. Nous supposons que vous connaissez les charges de travail liées aux conteneurs, Amazon Managed Service for Prometheus et Amazon Managed Grafana.
Pour plus d'informations, consultez les liens suivants :
+ Pour plus d’informations sur la création d’un environnement Amazon ECS dans un cluster Fargate avec des paramètres par défaut, consultez la section [Création d’un cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html) dans le *Guide du développeur Amazon ECS*.
+ Pour plus d’informations sur la création d’un espace de travail Amazon Managed Service for Prometheus, consultez la section [Création d’un espace de travail](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) dans le *Guide de l’utilisateur Amazon Managed Service for Prometheus*.
+ Pour plus d’informations sur la création d’un espace de travail Amazon Managed Grafana, consultez la section [Création d’un espace de travail](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html) dans le *Guide de l’utilisateur Amazon Managed Grafana*.
## Étape 1 : définir une image de conteneur de collecteur ADOT personnalisée
Utilisez le fichier de configuration suivant comme modèle pour définir votre propre image de conteneur de collecteur ADOT. Remplacez *my-remote-URL* et *my-region* par vos `region` valeurs `endpoint` et. Enregistrez la configuration dans un fichier appelé *adot-config.yaml*.
**Note**
Cette configuration utilise l’extension `sigv4auth` pour authentifier les appels à Amazon Managed Service for Prometheus. Pour plus d'informations sur la configuration`sigv4auth`, voir [Authenticator - Sigv4 activé](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]
```
## Étape 2 : Transférez l'image de votre conteneur ADOT Collector vers un référentiel Amazon ECR
Utilisez un fichier Dockerfile pour créer et envoyer votre image de conteneur à un référentiel Amazon Elastic Container Registry (ECR).
1. Créez le fichier Dockerfile pour copier et ajouter votre image de conteneur à l’image Docker OTEL.
```
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. créer un référentiel Amazon ECR ;
```
# create repo:
COLLECTOR_REPOSITORY=$(aws ecr create-repository --repository aws-otel-collector \
--query repository.repositoryUri --output text)
```
1. Créez voter image de conteneur.
```
# build ADOT collector image:
docker build -t $COLLECTOR_REPOSITORY:ecs .
```
**Note**
Cela suppose que vous créez votre conteneur dans le même environnement que celui dans lequel il sera exécuté. Dans le cas contraire, vous devrez peut-être utiliser le paramètre `--platform` lors de la création de l’image.
1. Connectez-vous au référentiel Amazon ECR. Remplacez *my-region* par votre `region` valeur.
```
# sign in to repo:
aws ecr get-login-password --region my-region | \
docker login --username AWS --password-stdin $COLLECTOR_REPOSITORY
```
1. Envoyez votre image de conteneur.
```
# push ADOT collector image:
docker push $COLLECTOR_REPOSITORY:ecs
```
## Étape 3 : créer une définition de tâche Amazon ECS pour supprimer Amazon Managed Service for Prometheus
Créez une définition de tâche Amazon ECS pour la collecte dans Amazon Managed Service for Prometheus. Votre définition de tâche doit inclure un conteneur nommé `adot-collector` et un conteneur nommé`prometheus`. `prometheus` génère des métriques et `adot-collector` effectue la collecte dans `prometheus`.
**Note**
Amazon Managed Service for Prometheus fonctionne en tant que service et collecte des métriques à partir de conteneurs. Dans ce cas, les conteneurs exécutent Prometheus localement, en mode Agent, et envoient les métriques locales à Amazon Managed Service for Prometheus.
**Exemple : définition de tâche**
Voici un exemple de définition de tâche. Vous pouvez utiliser cet exemple comme modèle pour créer votre propre définition de tâche. Remplacez la valeur `image` de `adot-collector` par l’URL du référentiel et la balise d’image (`$COLLECTOR_REPOSITORY:ecs`). Remplacez les valeurs `region` de `adot-collector` et `prometheus` par vos valeurs `region`.
```
{
"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"
}
```
## Étape 4 : autorisez votre tâche à accéder à Amazon Managed Service for Prometheus
Pour envoyer les métriques récupérées à Amazon Managed Service for Prometheus, votre tâche Amazon ECS doit disposer des autorisations appropriées pour appeler AWS les opérations d'API à votre place. Vous devez créer un rôle IAM pour vos tâches et y attacher la politique `AmazonPrometheusRemoteWriteAccess`. Pour plus d’informations sur la création de ce rôle et l’attachement de cette politique, consultez la section [Création d’un rôle et d’une politique IAM pour vos tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html#create_task_iam_policy_and_role).
Une fois que vous avez attaché `AmazonPrometheusRemoteWriteAccess` à votre rôle IAM et que vous l’avez utilisé pour vos tâches, Amazon ECS peut envoyer vos métriques collectées à Amazon Managed Service for Prometheus.
## Étape 5 : Visualisez vos statistiques dans Amazon Managed Grafana
**Important**
Avant de commencer, vous devez exécuter une tâche Fargate sur votre définition de tâche Amazon ECS. Sinon, Amazon Managed Service for Prometheus ne pourra pas utiliser vos métriques.
1. Dans le volet de navigation de votre espace de travail Amazon Managed Grafana, sélectionnez **Sources de données** sous l' AWS icône.
1. Dans l’onglet **Sources de données**, pour **Service**, sélectionnez **Amazon Managed Service for Prometheus** et choisissez votre **région par défaut.**
1. Choisissez **Add data source**.
1. Utilisez les préfixes `ecs` et `prometheus` pour interroger et visualiser vos métriques.
# Configuration de l’ingestion de métriques à partir d’une instance Amazon EC2 à l’aide de l’écriture à distance
Cette section explique comment exécuter un serveur Prometheus avec l’écriture à distance dans une instance Amazon Elastic Compute Cloud (Amazon EC2). Elle explique comment collecter des métriques à partir d’une application de démonstration écrite dans Go et les envoyer à un espace de travail Amazon Managed Service for Prometheus.
## Conditions préalables
**Important**
Avant de commencer, vous devez avoir installé Prometheus version 2.26 ou une version ultérieure. Nous supposons que vous connaissez Prometheus, Amazon EC2 et Amazon Managed Service for Prometheus. Pour plus d’informations sur l’installation de Prometheus, consultez la section [Mise en route](https://prometheus.io/docs/prometheus/latest/getting_started/) sur le site Web de Prometheus.
Si vous ne connaissez pas Amazon EC2 ou Amazon Managed Service for Prometheus, nous vous recommandons de commencer par lire les sections suivantes :
+ [Qu’est-ce qu’Amazon Elastic Compute Cloud ?](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)
+ [Qu’est-ce qu’Amazon Managed Service for Prometheus ?](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
## Création d’un rôle IAM pour Amazon EC2
Pour diffuser des métriques, vous devez d'abord créer un rôle IAM avec la politique AWS **AmazonPrometheusRemoteWriteAccess**gérée. Vous pouvez ensuite lancer une instance avec le rôle et les métriques de diffusion dans votre espace de travail Amazon Managed Service for Prometheus.
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Sélectionnez **Rôles** dans le volet de navigation, puis **Créer un rôle**.
1. Pour le type d’entité de confiance, choisissez **service AWS **. Pour le cas d’utilisation, choisissez **EC2**. Choisissez **Suivant : Autorisations**.
1. Dans la barre de recherche, saisissez **AmazonPrometheusRemoteWriteAccess**. Dans **Nom de la stratégie**, sélectionnez **AmazonPrometheusRemoteWriteAccess**, puis choisissez **Attacher la politique**. Choisissez **Suivant : balises**.
1. (Facultatif) Créez des balises IAM pour votre rôle IAM. Choisissez **Suivant : Vérification**.
1. Saisissez un nom pour votre rôle. Choisissez **Create Policy** (Créer une politique).
## Lancement d’une instance Amazon EC2
Pour lancer une instance Amazon EC2, suivez les instructions de la section [Launch an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role) du *Guide de l’utilisateur Amazon Elastic Compute Cloud pour les instances Linux*.
## Exécutez l’application de démonstration.
Après avoir créé votre rôle IAM et lancé une instance EC2 avec ce rôle, vous pouvez exécuter une application de démonstration pour le voir fonctionner.
**Pour exécuter une application de démonstration et tester les métriques**
1. Pour créer un fichier Go nommé `main.go`, utilisez le modèle suivant.
```
package main
import (
"github.com/prometheus/client_golang/prometheus/promhttp"
"net/http"
)
func main() {
http.Handle("/metrics", promhttp.Handler())
http.ListenAndServe(":8000", nil)
}
```
1. Exécutez les commandes suivantes pour installer les bonnes dépendances.
```
sudo yum update -y
sudo yum install -y golang
go get github.com/prometheus/client_golang/prometheus/promhttp
```
1. Exécutez l’application de démonstration.
```
go run main.go
```
L’application de démonstration doit fonctionner sur le port 8000 et afficher toutes les métriques Prometheus exposées. Voici un exemple de ces métriques.
```
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
```
## Création d’un espace de travail Amazon Managed Service for Prometheus
Pour créer un espace de travail Amazon Managed Service for Prometheus, suivez les instructions de la section [Create a workspace](AMP-create-workspace.md).
## Exécution d’un serveur Prometheus
1. Utilisez l’exemple de fichier YAML suivant comme modèle pour créer un nouveau fichier nommé `prometheus.yaml`. Pour`url`, remplacez-le *my-region* par la valeur de votre région et *my-workspace-id* par l'ID d'espace de travail généré pour vous par Amazon Managed Service for Prometheus. Pour`region`, remplacez *my-region* par la valeur de votre région.
**Exemple : fichier YAML**
```
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. Exécutez le serveur Prometheus pour envoyer les métriques de l’application de démonstration à votre espace de travail Amazon Managed Service for Prometheus.
```
prometheus --config.file=prometheus.yaml
```
Le serveur Prometheus doit maintenant envoyer les métriques de l’application de démonstration à votre espace de travail Amazon Managed Service for Prometheus.
# Utilisation d’une instance Prometheus comme collecteur
Vous pouvez utiliser une instance Prometheus, exécutée *en* mode agent (connue sous le nom d'agent *Prometheus), pour récupérer des métriques et les envoyer à votre espace de travail Amazon Managed Service for Prometheus*.
Les rubriques suivantes décrivent les différentes manières de configurer une instance Prometheus exécutée en mode agent en tant que collecteur pour vos métriques.
**Avertissement**
Lorsque vous créez un agent Prometheus, vous êtes responsable de sa configuration et de sa maintenance. [Évitez d'exposer les terminaux Prometheus Scrape à l'Internet public en activant les fonctionnalités de sécurité.](https://prometheus.io/docs/prometheus/latest/configuration/https/)
Si vous avez configuré plusieurs instances Prometheus qui surveillent le même ensemble de métriques et que vous les avez envoyées à un seul espace de travail Amazon Managed Service for Prometheus à des fins de haute disponibilité, vous devez configurer la déduplication. Si vous ne suivez pas les étapes de configuration de la déduplication, tous les échantillons de données envoyés à Amazon Managed Service for Prometheus vous seront facturés, y compris les échantillons en double. Pour obtenir des instructions sur la configuration de la déduplication, consultez la section [Déduplication des métriques haute disponibilité envoyées à Amazon Managed Service for Prometheus](AMP-ingest-dedupe.md).
**Topics**
+ [Configuration de l’ingestion à partir d’un nouveau serveur Prometheus à l’aide de Helm](AMP-onboard-ingest-metrics-new-Prometheus.md)
+ [Configuration de l’ingestion depuis un serveur Prometheus existant dans Kubernetes sur EC2](AMP-onboard-ingest-metrics-existing-Prometheus.md)
+ [Configuration de l’ingestion depuis un serveur Prometheus existant dans Kubernetes sur Fargate](AMP-onboard-ingest-metrics-existing-Prometheus-fargate.md)
# Configuration de l’ingestion à partir d’un nouveau serveur Prometheus à l’aide de Helm
Les instructions de cette section vous permettent d’être rapidement opérationnel avec Amazon Managed Service for Prometheus. Vous configurez un nouveau serveur Prometheus dans un cluster Amazon EKS, et ce nouveau serveur utilise une configuration par défaut pour envoyer des métriques à Amazon Managed Service for Prometheus. Voici les prérequis pour cette méthode :
+ Vous devez disposer d'un cluster Amazon EKS à partir duquel le nouveau serveur Prometheus collectera les métriques.
+ Un [pilote Amazon EBS CSI doit être installé sur votre cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) (requis par Helm).
+ Vous devez utiliser Helm CLI 3.0 ou version ultérieure.
+ Vous devez utiliser un ordinateur Linux ou macOS pour effectuer les étapes décrites dans les sections suivantes.
## Étape 1 : Ajouter de nouveaux référentiels de Charts Helm
Pour ajouter de nouveaux référentiels de Charts de Helm, entrez les commandes suivantes. Pour plus d’informations sur l’utilisation de ces commandes, consultez la section [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
```
## Étape 2 : Créer un espace de noms Prometheus
Entrez la commande suivante pour créer un espace de noms Prometheus pour le serveur Prometheus et les autres composants de surveillance. *prometheus-namespace*Remplacez-le par le nom que vous souhaitez pour cet espace de noms.
```
kubectl create namespace prometheus-namespace
```
## Étape 3 : Configurer des rôles IAM pour les comptes de service
Pour cette méthode d’intégration indiquée, vous devez utiliser des rôles IAM pour les comptes de service du cluster Amazon EKS où le serveur Prometheus est exécuté.
Avec les rôles IAM pour les comptes de service, vous pouvez associer un rôle IAM à un compte de service Kubernetes. Ce compte de service peut ensuite fournir des autorisations AWS aux pods de n’importe quel pod qui utilise ce compte de service. Pour plus d’informations, consultez la section [Rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Si vous n’avez pas encore configuré ces rôles, suivez les instructions de la section [Configuration de rôles de service pour l’ingestion de métriques à partir de clusters Amazon EKS](set-up-irsa.md#set-up-irsa-ingest) pour les configurer. Les instructions de cette section nécessitent l’utilisation de `eksctl`. Pour plus d’informations, consultez la section [Démarrer avec Amazon Elastic Kubernetes Service – `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html).
**Note**
Lorsque vous n'êtes pas sur EKS ou AWS que vous utilisez simplement une clé d'accès et une clé secrète pour accéder à Amazon Managed Service for Prometheus, vous ne pouvez pas utiliser `EKS-IAM-ROLE` le SigV4 basé.
## Étape 4 : Configurer le nouveau serveur et commencer à ingérer des métriques
Pour installer le nouveau serveur Prometheus qui envoie des métriques à votre espace de travail Amazon Managed Service for Prometheus, procédez comme suit.
**Pour installer un nouveau serveur Prometheus afin d’envoyer des métriques à votre espace de travail Amazon Managed Service for Prometheus**
1. À l’aide d’un éditeur de texte, créez un fichier nommé `my_prometheus_values_yaml` avec le contenu suivant.
+ *IAM\$1PROXY\$1PROMETHEUS\$1ROLE\$1ARN*Remplacez-le par l'ARN du **amp-iamproxy-ingest-role**que vous avez créé dans[Configuration de rôles de service pour l’ingestion de métriques à partir de clusters Amazon EKS](set-up-irsa.md#set-up-irsa-ingest).
+ *WORKSPACE\$1ID*Remplacez-le par l'ID de votre espace de travail Amazon Managed Service for Prometheus.
+ Remplacez *REGION* par la région de votre espace de travail Amazon Managed Service for Prometheus.
```
## 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. Saisissez la commande suivante pour créer le serveur Prometheus.
+ Remplacez *prometheus-chart-name* par le nom de votre version de Prometheus.
+ *prometheus-namespace*Remplacez-le par le nom de votre espace de noms Prometheus.
```
helm install prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace \
-f my_prometheus_values_yaml
```
**Note**
Vous pouvez personnaliser la commande `helm install` de différentes façons. Pour plus d’informations, consultez [Installation de Helm](https://helm.sh/docs/helm/helm_install/) dans la documentation Helm.
# Configuration de l’ingestion depuis un serveur Prometheus existant dans Kubernetes sur EC2
Amazon Managed Service for Prometheus prend en charge l’ingestion de métriques à partir de serveurs Prometheus dans des clusters exécutés sur Amazon EKS et dans des clusters Kubernetes exécutés sur Amazon EC2. Les instructions détaillées de cette section concernent un serveur Prometheus dans un cluster Amazon EKS. Les étapes pour un cluster Kubernetes autogéré sur Amazon EC2 sont les mêmes, sauf que vous devrez configurer vous-même le fournisseur OIDC et les rôles IAM pour les comptes de service dans le cluster Kubernetes.
Les instructions de cette section utilisent Helm comme gestionnaire de packages Kubernetes.
**Topics**
+ [Étape 1 : Configurer des rôles IAM pour les comptes de service](#AMP-onboard-existing-Prometheus-IRSA)
+ [Étape 2 : Mettre à niveau votre serveur Prometheus existant à l’aide de Helm](#AMP-onboard-ingest-metrics-existing-remotewrite)
## Étape 1 : Configurer des rôles IAM pour les comptes de service
Pour cette méthode d’intégration indiquée, vous devez utiliser des rôles IAM pour les comptes de service du cluster Amazon EKS où le serveur Prometheus est exécuté. Ces rôles sont également appelés *fonctions du service*.
Avec les rôles de service, vous pouvez associer un rôle IAM à un compte de service Kubernetes. Ce compte de service peut ensuite fournir des AWS autorisations aux conteneurs de n'importe quel pod utilisant ce compte de service. Pour plus d’informations, consultez la section [Rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Si vous n’avez pas encore configuré ces rôles, suivez les instructions de la section [Configuration de rôles de service pour l’ingestion de métriques à partir de clusters Amazon EKS](set-up-irsa.md#set-up-irsa-ingest) pour les configurer.
## Étape 2 : Mettre à niveau votre serveur Prometheus existant à l’aide de Helm
Les instructions de cette section incluent la configuration de l’écriture à distance et de sigv4 pour authentifier et autoriser le serveur Prometheus à écrire à distance sur votre espace de travail Amazon Managed Service for Prometheus.
### Utilisation de Prometheus version 2.26.0 ou ultérieure
Suivez ces étapes si vous utilisez des Charts de Helm avec une image du serveur Prometheus version 2.26.0 ou ultérieure.
**Pour configurer l’écriture à distance depuis un serveur Prometheus à l’aide de Charts de Helm**
1. Créez une nouvelle section d’écriture à distance dans votre fichier de configuration Helm :
+ `${IAM_PROXY_PROMETHEUS_ROLE_ARN}`Remplacez-le par l'ARN du **amp-iamproxy-ingest-role**que vous avez créé dans[Étape 1 : Configurer des rôles IAM pour les comptes de service](#AMP-onboard-existing-Prometheus-IRSA). L’ARN du rôle doit être au format `arn:aws:iam::your account ID:role/amp-iamproxy-ingest-role`.
+ Remplacez `${WORKSPACE_ID}` par l’ID de votre espace de travail Amazon Managed Service for Prometheus.
+ Remplacez `${REGION}` par la Région de votre espace de travail Amazon Managed Service for Prometheus (comme `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. Mettez à jour la configuration existante de votre serveur Prometheus à l’aide de Helm :
+ Remplacez `prometheus-chart-name` par le nom de votre version de Prometheus.
+ Remplacez `prometheus-namespace` par l’espace de noms Kubernetes dans lequel votre serveur Prometheus est installé.
+ Remplacez `my_prometheus_values_yaml` par le chemin d’accès à votre fichier de configuration Helm.
+ Remplacez `current_helm_chart_version` par la version actuelle de vos Charts de Helm du serveur Prometheus. Vous pouvez trouver la version actuelle du graphique à l’aide de la commande [helm list](https://helm.sh/docs/helm/helm_list/).
```
helm upgrade prometheus-chart-name prometheus-community/prometheus \
-n prometheus-namespace \
-f my_prometheus_values_yaml \
--version current_helm_chart_version
```
### Utilisation de versions antérieures de Prometheus
Suivez ces étapes si vous utilisez une version de Prometheus antérieure à la version 2.26.0. Ces étapes utilisent une approche parallèle, car les versions antérieures de Prometheus ne prennent pas en charge nativement le processus de AWS signature Signature version 4 (SigV4).AWS
Ces instructions supposent que vous utilisez Helm pour déployer Prometheus.
**Pour configurer l’écriture à distance depuis un serveur Prometheus**
1. Sur votre serveur Prometheus, créez une nouvelle configuration d’écriture à distance. Commencez par créer un nouveau fichier de mise à jour. Nous appellerons ce fichier `amp_ingest_override_values.yaml`.
Ajoutez les valeurs suivantes au fichier YALM.
```
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
```
Remplacez `${REGION}` par la Région de votre espace de travail Amazon Managed Service for Prometheus.
`${SERVICE_ACCOUNT_IAM_INGEST_ROLE_ARN}`Remplacez-le par l'ARN du **amp-iamproxy-ingest-role**que vous avez créé dans[Étape 1 : Configurer des rôles IAM pour les comptes de service](#AMP-onboard-existing-Prometheus-IRSA). L’ARN du rôle doit être au format `arn:aws:iam::your account ID:role/amp-iamproxy-ingest-role`.
Remplacez `${WORKSPACE_ID}` par votre ID d’espace de travail.
1. Mettez à niveau vos Charts de Helm Prometheus. Commencez par rechercher le nom de vos Charts de Helm en entrant la commande suivante. Dans la sortie de cette commande, recherchez un graphique dont le nom inclut `prometheus`.
```
helm ls --all-namespaces
```
Entrez ensuite la commande suivante.
```
helm upgrade --install prometheus-helm-chart-name prometheus-community/prometheus -n prometheus-namespace -f ./amp_ingest_override_values.yaml
```
Remplacez *prometheus-helm-chart-name* par le nom du diagramme de barre de Prometheus renvoyé dans la commande précédente. Remplacez *prometheus-namespace* par le nom de votre espace de noms.
#### Téléchargement de Charts de Helm
Si vous n’avez pas encore téléchargé les Charts de Helm en local, vous pouvez utiliser la commande suivante pour les télécharger.
```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm pull prometheus-community/prometheus --untar
```
# Configuration de l’ingestion depuis un serveur Prometheus existant dans Kubernetes sur Fargate
Amazon Managed Service for Prometheus prend en charge l’ingestion de métriques à partir de serveurs Prometheus dans des clusters Kubernetes autogérés exécutés sur Fargate. Pour ingérer des métriques depuis des serveurs Prometheus dans des clusters Amazon EKS exécutés sur Fargate, remplacez les configurations par défaut dans un fichier de configuration nommé amp\$1ingest\$1override\$1values.yaml comme suit :
```
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
```
Installez Prometheus en utilisant les remplacements avec la commande suivante :
```
helm install prometheus-for-amp prometheus-community/prometheus \
-n prometheus \
-f amp_ingest_override_values.yaml
```
Notez que dans la configuration des Charts de Helm, nous avons désactivé l’exportateur de nœuds et le gestionnaire d’alertes, ainsi que le déploiement du serveur Prometheus.
Vous pouvez vérifier l’installation à l’aide de l’exemple de requête de test suivant.
```
$ 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
```
# Configurer Amazon Managed Service pour Prometheus pour garantir la haute disponibilité des données
Lorsque vous envoyez des données à Amazon Managed Service for Prometheus, elles sont automatiquement répliquées dans les zones de disponibilité AWS de la région et vous sont proposées à partir d’un cluster d’hôtes, garantissant l’évolutivité, la disponibilité et la sécurité. Vous souhaiterez peut-être ajouter des dispositifs de sécurité haute disponibilité supplémentaires, en fonction de votre configuration particulière. Il existe deux méthodes courantes pour ajouter des mesures de sécurité haute disponibilité à votre configuration :
+ Si plusieurs conteneurs ou instances contiennent les mêmes données, vous pouvez envoyer ces données à Amazon Managed Service for Prometheus et les dédupliquer automatiquement. Cela permet de garantir que vos données seront envoyées à votre espace de travail Amazon Managed Service for Prometheus.
Pour plus d’informations sur la déduplication des données haute disponibilité, consultez la section [Déduplication des métriques haute disponibilité envoyées à Amazon Managed Service for Prometheus](AMP-ingest-dedupe.md).
+ Si vous souhaitez vous assurer l’accès à vos données, même lorsque la région AWS n’est pas disponible, vous pouvez envoyer vos métriques à un deuxième espace de travail, dans une autre région.
Pour plus d’informations sur l’envoi de données de métriques à plusieurs espaces de travail, consultez la section [Utilisez des espaces de travail interrégionaux pour ajouter de la haute disponibilité à Amazon Managed Service for Prometheus](AMP-send-to-multiple-workspaces.md).
**Topics**
+ [Déduplication des métriques haute disponibilité envoyées à Amazon Managed Service for Prometheus](AMP-ingest-dedupe.md)
+ [Envoi de données haute disponibilité à Amazon Managed Service for Prometheus avec Prometheus](Send-high-availability-data.md)
+ [Configurez des données de haute disponibilité pour Amazon Managed Service for Prometheus à l'aide du diagramme Prometheus Operator Helm](Send-high-availability-data-operator.md)
+ [Envoyez des données à haute disponibilité à Amazon Managed Service pour AWS Prometheus avec Distro for OpenTelemetry](Send-high-availability-data-ADOT.md)
+ [Envoi de données haute disponibilité à Amazon Managed Service for Prometheus avec les Charts de Helm de la communauté Prometheus](Send-high-availability-prom-community.md)
+ [Réponses aux questions les plus fréquemment posées sur la configuration de haute disponibilité dans Amazon Managed Service for Prometheus](HA_FAQ.md)
+ [Utilisez des espaces de travail interrégionaux pour ajouter de la haute disponibilité à Amazon Managed Service for Prometheus](AMP-send-to-multiple-workspaces.md)
# Déduplication des métriques haute disponibilité envoyées à Amazon Managed Service for Prometheus
Vous pouvez envoyer des données provenant de plusieurs *agents* Prometheus (instances Prometheus exécutées en mode Agent) à votre espace de travail Amazon Managed Service for Prometheus. Si certaines de ces instances enregistrent et envoient les mêmes métriques, la disponibilité de vos données sera plus élevée (même si l’un des agents arrête d’envoyer des données, l’espace de travail Amazon Managed Service for Prometheus continuera de recevoir les données d’une autre instance). Cependant, vous souhaitez que votre espace de travail Amazon Managed Service for Prometheus déduplique automatiquement les métriques afin de ne pas les voir plusieurs fois et de ne pas être facturé pour l’ingestion et le stockage des données à plusieurs reprises.
Pour qu’Amazon Managed Service for Prometheus déduplique automatiquement les données de plusieurs agents Prometheus, vous devez attribuer à l’ensemble des agents qui envoient les données en double un *nom de cluster* unique, et à chacune des instances un *nom de réplique*. Le nom du cluster identifie les instances comme ayant des données partagées, et le nom de la réplique permet à Amazon Managed Service for Prometheus d’identifier la source de chaque métrique. Les métriques finales stockées incluent l’étiquette du cluster, mais pas la réplique. Elles semblent donc provenir d’une source unique.
**Note**
Certaines versions de Kubernetes (1.28 et 1.29) peuvent émettre leur propre métrique avec une étiquette. `cluster` Cela peut entraîner des problèmes avec la déduplication Amazon Managed Service for Prometheus. Consultez la [FAQ sur la haute disponibilité](HA_FAQ.md#HA_FAQ_cluster-label) pour plus d'informations.
Les rubriques suivantes expliquent comment envoyer des données et inclure les `__replica__` étiquettes `cluster` et, afin qu'Amazon Managed Service for Prometheus déduplique automatiquement les données.
**Important**
Si vous ne configurez pas la déduplication, tous les échantillons de données envoyés à Amazon Managed Service for Prometheus vous seront facturés. Ces échantillons de données incluent les échantillons en double.
# Envoi de données haute disponibilité à Amazon Managed Service for Prometheus avec Prometheus
Pour définir une configuration haute disponibilité avec Prometheus, vous devez appliquer des étiquettes externes sur toutes les instances d’un groupe haute disponibilité, afin qu’Amazon Managed Service for Prometheus puisse les identifier. Utilisez l’étiquette `cluster` pour identifier un agent d’instance Prometheus dans un groupe haute disponibilité. Utilisez l’étiquette `__replica__` pour identifier chaque réplique du groupe séparément. Vous devez appliquer les étiquettes `__replica__` et `cluster` pour que la déduplication fonctionne.
**Note**
L’étiquette `__replica__` est formatée avec deux symboles de soulignement avant et après le mot `replica`.
**Exemple : extraits de code**
Dans les extraits de code suivants, l’étiquette `cluster` identifie l’agent d’instance Prometheus `prom-team1` et l’étiquette `_replica_` identifie les répliques `replica1` et `replica2`.
```
cluster: prom-team1
__replica__: replica1
```
```
cluster: prom-team1
__replica__: replica2
```
Comme Amazon Managed Service for Prometheus stocke des échantillons de données provenant de répliques haute disponibilité avec ces étiquettes, il retire l’étiquette `replica` lorsque les échantillons sont acceptés. Cela signifie que vous n’aurez qu’un mappage de série 1:1 pour votre série actuelle au lieu d’une série par réplique. L’étiquette `cluster` est conservée.
**Note**
Certaines versions de Kubernetes (1.28 et 1.29) peuvent émettre leur propre métrique avec une étiquette. `cluster` Cela peut entraîner des problèmes avec la déduplication Amazon Managed Service for Prometheus. Consultez la [FAQ sur la haute disponibilité](HA_FAQ.md#HA_FAQ_cluster-label) pour plus d'informations.
# Configurez des données de haute disponibilité pour Amazon Managed Service for Prometheus à l'aide du diagramme Prometheus Operator Helm
Pour configurer une configuration haute disponibilité avec l'opérateur Prometheus dans Helm, vous devez appliquer des étiquettes externes sur toutes les instances d'un groupe de haute disponibilité, afin qu'Amazon Managed Service for Prometheus puisse les identifier. Vous devez également définir les attributs `replicaExternalLabelName` et `externalLabels` sur les Charts de Helm de l’opérateur Prometheus.
**Exemple : en-tête YAML**
Dans l’en-tête YAML suivant, `cluster` est ajouté à `externalLabel` pour identifier un agent d’instance Prometheus dans le cadre d’un groupe haute disponibilité, et `replicaExternalLabels` identifie chaque réplique du groupe.
```
replicaExternalLabelName: __replica__
externalLabels:
cluster: prom-dev
```
**Note**
Certaines versions de Kubernetes (1.28 et 1.29) peuvent émettre leur propre métrique avec une étiquette. `cluster` Cela peut entraîner des problèmes avec la déduplication Amazon Managed Service for Prometheus. Consultez la [FAQ sur la haute disponibilité](HA_FAQ.md#HA_FAQ_cluster-label) pour plus d'informations.
# Envoyez des données à haute disponibilité à Amazon Managed Service pour AWS Prometheus avec Distro for OpenTelemetry
AWS Distro for OpenTelemetry (ADOT) est une distribution sécurisée et prête pour la production du projet. OpenTelemetry ADOT vous fournit des sources APIs, des bibliothèques et des agents, afin que vous puissiez collecter des traces et des métriques distribuées pour la surveillance des applications. Pour plus d'informations sur ADOT, voir [À propos de AWS Distro for Open](https://aws-otel.github.io/about) Telemetry.
Pour configurer ADOT avec une configuration haute disponibilité, vous devez configurer une image de conteneur du collecteur ADOT et appliquer les étiquettes externes à l'exportateur d'`cluster`écriture `__replica__` à distance Prometheus AWS . Cet exportateur envoie vos métriques collectées à votre espace de travail Amazon Managed Service for Prometheus via le point de terminaison `remote_write`. Lorsque vous définissez ces étiquettes sur l’exportateur d’écriture à distance, vous empêchez la conservation des métriques en double lors de l’exécution des répliques redondantes. Pour plus d'informations sur l' AWS exportateur d'écriture à distance Prometheus, [consultez Getting started with Prometheus Remote Write Exporter pour Amazon Managed Service for Prometheus](https://aws-otel.github.io/docs/getting-started/prometheus-remote-write-exporter).
**Note**
Certaines versions de Kubernetes (1.28 et 1.29) peuvent émettre leur propre métrique avec une étiquette. `cluster` Cela peut entraîner des problèmes avec la déduplication Amazon Managed Service for Prometheus. Consultez la [FAQ sur la haute disponibilité](HA_FAQ.md#HA_FAQ_cluster-label) pour plus d'informations.
# Envoi de données haute disponibilité à Amazon Managed Service for Prometheus avec les Charts de Helm de la communauté Prometheus
Pour définir une configuration haute disponibilité avec les Charts de Helm de la communauté Prometheus, vous devez appliquer des étiquettes externes sur toutes les instances d’un groupe haute disponibilité, afin qu’Amazon Managed Service for Prometheus puisse les identifier. Voici un exemple de la manière dont vous pouvez ajouter les `external_labels` à une seule instance de Prometheus à partir des Charts de Helm de la communauté Prometheus.
```
server:
global:
external_labels:
cluster: monitoring-cluster
__replica__: replica-1
```
**Note**
Si vous souhaitez avoir plusieurs répliques, vous devez déployer le graphique plusieurs fois avec différentes valeurs de répliques, car les Charts de Helm de la communauté Prometheus ne permettent pas de définir dynamiquement la valeur de la réplique lorsque vous augmentez le nombre de répliques directement à partir du groupe de contrôleurs. Si vous préférez que l’étiquette `replica` soit définie automatiquement, utilisez les Charts de Helm prometheus-operator.
**Note**
Certaines versions de Kubernetes (1.28 et 1.29) peuvent émettre leur propre métrique avec une étiquette. `cluster` Cela peut entraîner des problèmes avec la déduplication Amazon Managed Service for Prometheus. Consultez la [FAQ sur la haute disponibilité](HA_FAQ.md#HA_FAQ_cluster-label) pour plus d'informations.
# Réponses aux questions les plus fréquemment posées sur la configuration de haute disponibilité dans Amazon Managed Service for Prometheus
## Dois-je inclure la valeur *\$1\$1replica\$1\$1* dans une autre étiquette pour suivre les points de prélèvement ?
Dans un environnement haute disponibilité, Amazon Managed Service for Prometheus garantit que les échantillons de données ne sont pas dupliqués en élisant un leader dans le cluster d’instances Prometheus. Si la réplique leader cesse d’envoyer des échantillons de données pendant 30 secondes, Amazon Managed Service for Prometheus transforme automatiquement une autre instance de Prometheus en réplique leader et ingère les données du nouveau leader, y compris les données manquantes. Par conséquent, la réponse est non, ce n’est pas recommandé. Cela peut entraîner des problèmes tels que les suivants :
+ L’interrogation d’un `count` dans **ProMQL** peut renvoyer une valeur supérieure à celle attendue pendant la période d’élection d’un nouveau leader.
+ Le nombre de `active series` augmente pendant la période d’élection d’un nouveau leader et il atteint les `active series limits`. Pour plus d’informations, consultez la section [ AMP Quotas](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html).
## Kubernetes semble avoir son propre label de *cluster* et ne déduplique pas mes métriques. Comment corriger ce problème ?
Une nouvelle métrique `apiserver_storage_size_bytes` a été introduite dans Kubernetes 1.28, avec une étiquette. `cluster` Cela peut entraîner des problèmes de déduplication dans Amazon Managed Service for Prometheus, qui dépendent de l'étiquette. `cluster` Dans Kubernetes 1.3, le label est renommé en `storage-cluster_id` (il est également renommé dans les derniers patchs 1.28 et 1.29). Si votre cluster émet cette métrique avec l'`cluster`étiquette, Amazon Managed Service for Prometheus ne peut pas dédupliquer la série chronologique associée. Nous vous recommandons de mettre à niveau votre cluster Kubernetes vers la dernière version corrigée pour éviter ce problème. Vous pouvez également `cluster` réétiqueter l'étiquette de votre `apiserver_storage_size_bytes` métrique avant de l'intégrer dans Amazon Managed Service for Prometheus.
**Note**
*Pour plus de détails sur la modification apportée à Kubernetes, voir [Renommer le cluster d'étiquettes en storage\$1cluster\$1id pour la métrique apiserver\$1storage\$1size\$1bytes](https://github.com/kubernetes/kubernetes/pull/124283) dans le projet Kubernetes. GitHub*
# Utilisez des espaces de travail interrégionaux pour ajouter de la haute disponibilité à Amazon Managed Service for Prometheus
Pour ajouter la disponibilité entre régions à vos données, vous pouvez envoyer des métriques à plusieurs espaces de travail répartis dans AWS différentes régions. Prometheus prend en charge à la fois les dispositifs d’écriture et l’écriture entre régions.
L’exemple suivant montre comment configurer un serveur Prometheus exécuté en mode Agent pour envoyer des métriques à deux espaces de travail dans différentes régions grâce à Helm.
```
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]
```