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.
# 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]
```