Tous les produits AWS Marketplace
S4 Metrics
Observabilité

S4 Metrics

Gouverner la cardinalité des métriques CloudWatch

Maîtriser le coût de cardinalité des métriques Service AWS remplacé: Métriques personnalisées CloudWatch
Obtenir sur AWS Marketplace

Réduisez votre facture de métriques personnalisées CloudWatch : gouvernez la cardinalité des métriques à l’ingest, puis établissez une baseline automatique et consolidez les économies sur toute votre AWS Organization.

S4 Metrics gouverne la cardinalité des métriques personnalisées CloudWatch à l’edge d’ingest — suppression des dimensions à forte cardinalité, bucketisation des dimensions numériques et agrégation par fenêtres AVANT PutMetricData, afin de ne payer que les séries nécessaires au lieu d’une explosion non bornée. Le collecteur open source metricsd (intake StatsD/DogStatsD + OTLP/EMF/PutMetricData) applique cette gouvernance et émet vers CloudWatch, avec en option une copie full-resolution S3/Prometheus. La couche commerciale ajoute l’auto-baseline et un rollup consolidé AWS Organizations.

Le problème

CloudWatch facture les métriques personnalisées par série temporelle unique (combinaison de namespace + nom de métrique + valeur de dimension), où les 10,000 premières séries coûtent $0.30 chacune par mois selon un tarif dégressif. Une poignée de dimensions à haute cardinalité — user_id, request_id, path, instance_id — se multiplient de manière combinatoire en milliers de séries. Ce qui gonfle la facture, ce ne sont pas les octets ou le volume de requêtes, mais cette explosion illimitée de séries uniques.

Fonctionnement

  1. 1

    Rediriger la télémétrie vers metricsd

    Modifiez uniquement l'endpoint de vos émetteurs StatsD/DogStatsD, OTLP, EMF ou PutMetricData vers le collecteur metricsd, sans toucher au code de l'application.

  2. 2

    Analysez vos dimensions les plus coûteuses

    Auto-baseline analyse votre compte en lecture seule via ListMetrics, classe les dimensions selon leur contribution au nombre de séries facturables, et propose un ensemble de règles de gouvernance avec estimation de prix.

  3. 3

    Appliquer la gouvernance avant PutMetricData

    Appliquez les règles pour supprimer (drop), cumuler (roll up), segmenter (bucket) et agréger par fenêtre temporelle les dimensions avant émission, afin que seules les séries méritant d'être payées atteignent le chemin de facturation de CloudWatch.

Points forts

Gouvernance de la cardinalité à l’ingest : drop / bucket / aggregate avant PutMetricData.

L’auto-baseline classe vos dimensions les plus coûteuses et propose un jeu de règles chiffré.

Rollup consolidé AWS Organizations via un rôle cross-account READ-ONLY (ListMetrics uniquement).

Ce qui est inclus

  • Collecteur open source metricsd — ingestion de StatsD/DogStatsD, OTLP, EMF et PutMetricData, puis gouvernance, agrégation et envoi vers CloudWatch.
  • Moteur de gouvernance — conservation (keep), suppression (drop), regroupement (rollup), segmentation (bucket) et échantillonnage (sample) déterministes sur les dimensions, avec agrégation par fenêtre de 60 secondes et quantiles DDSketch pour cesser d'envoyer une série par requête.
  • Simulation en dollars tenant compte des paliers de facturation — une estimation avant/après/économies tarifée selon les paliers de CloudWatch, à partir d'un fichier ou d'un scan ListMetrics en direct et en lecture seule, avant d'appliquer quoi que ce soit.
  • Proposition de règles par auto-baseline (commercial) — classe vos dimensions les plus coûteuses et génère un ensemble de règles tarifées en format YAML OSS standard.
  • Synthèse consolidée des économies AWS Organizations (commercial) — estimations en lecture seule, ajustées aux paliers par compte et au global de l'organisation.
  • Tee optionnel en pleine résolution — duplique les dimensions supprimées vers S3 ou Prometheus remote-write afin de ne rien jeter, mais simplement de les retirer du chemin de facturation par série.
  • Règles au format YAML OSS standard — la version open source de metricsd les lit telles quelles ; aucun verrouillage.

Cas d'usage

Équipes dont la facture de métriques personnalisées s'emballe parce que user_id, request_id ou path se sont retrouvés dans une métrique et ont explosé en milliers de séries.

Organisations multi-comptes ayant besoin d'une vue unique, consolidée et ajustée aux paliers de facturation pour identifier où se situent les coûts de cardinalité.

Contrôle des coûts avant dépense — évaluez le coût d'un ensemble de règles potentielles avec la simulation (dry-run) et comparez les économies projetées au tarif de l'AMI avant de modifier quoi que ce soit.

Équipes devant conserver les détails en pleine résolution pour les investigations mais souhaitant les retirer du circuit de facturation par série (tee S3 / Prometheus).

FAQ

Vais-je perdre les données que je supprime ?

Non. Les dimensions supprimées peuvent être envoyées en pleine résolution (via tee) vers S3 ou Prometheus remote-write ; les détails ne sont pas supprimés, mais simplement déplacés vers un espace de stockage non facturé par série, vous permettant de relire user_id depuis le tee lors d'une investigation.

Est-ce que cela me lie à votre produit ?

Non. Chaque règle est du YAML OSS standard que metricsd open source lit textuellement, et les propositions passent par un cycle de validation (round-trip) via le moteur open source avant de vous être présentées. Résiliez l'abonnement, et votre collecteur ainsi que vos règles continueront de fonctionner sans changement.

Comment accède-t-il à mon compte en toute sécurité, et où fonctionne-t-il ?

La CLI commerciale est strictement en lecture seule — cloudwatch:ListMetrics, organizations:ListAccounts, sts:AssumeRole — et n'émet jamais de métriques ni ne modifie votre compte. Les scans cross-account endossent un rôle que vous créez qui accorde uniquement ListMetrics, avec un nom de session fixe pour l'audit CloudTrail. Tout fonctionne sur une AMI dans votre propre VPC.

Quelles entrées sont prises en charge ?

metricsd ingère StatsD/DogStatsD (UDP), ainsi que les métriques OTLP, EMF et PutMetricData sur HTTP. La migration se résume à une simple surcharge d'endpoint.

Quelle est la différence entre la version open source et la version commerciale ?

Le collecteur (ingest/govern/aggregate/emit) et le dry-run multiniveau sont open-source Apache-2.0 metricsd. La couche commerciale ajoute la baseline automatique ListMetrics qui écrit les règles à votre place, le rollup consolidé AWS Organizations, un tableau de bord d'économies et le déploiement AMI/CloudFormation en un clic — le tout construit sur le cœur OSS, sans jamais aucun fork.

Modèle de tarification

Frais logiciels horaires + EC2 (classe t3 / m5). Facturation à l’usage par type d’instance, option annuelle disponible.

Obtenir sur AWS Marketplace