Métriques personnalisées avec la vigie applicative - Amazon CloudWatch
Configuration des métriques personnalisées pour la vigie applicativeAffichage des métriques personnalisées dans la vigie applicativeQuestions fréquemment posées (FAQ)

Métriques personnalisées avec la vigie applicative

Pour surveiller les performances et la disponibilité des applications, la vigie applicative collecte des métriques standard (défaillances, erreurs et latence) et des métriques d’exécution à partir des applications détectées après son activation.

Les métriques personnalisées ajoutent un contexte précieux à la surveillance de vos applications et contribuent à accélérer le dépannage. Vous pouvez les utiliser pour :

  • Personnaliser l’analyse des données de télémétrie

  • Identifier les causes racine des problèmes

  • Prendre rapidement des décisions commerciales et opérationnelles précises

La vigie applicative vous permet d’afficher et de corréler les métriques personnalisées générées à partir d’un service avec les métriques standard et d’exécution. Par exemple, une application peut émettre des métriques pour la taille des demandes et le nombre d’échecs de cache. Ces métriques personnalisées fournissent des informations plus détaillées sur les problèmes de performances, vous aidant à diagnostiquer et à résoudre plus rapidement les baisses de disponibilité et les pics de latence.

Configuration des métriques personnalisées pour la vigie applicative

Vous pouvez générer des métriques personnalisées à partir de votre application à l’aide de deux méthodes : les métriques OpenTelemetry et les métriques de portée.

Métriques OpenTelemetry

Pour utiliser des métriques OpenTelemetry personnalisées avec la vigie applicative, vous devez utiliser soit l’agent CloudWatch, soit le collecteur OpenTelemetry. Les métriques OpenTelemetry personnalisées vous permettent de créer et d’exporter des métriques directement à partir du code de votre application à l’aide du kit SDK des métriques OpenTelemetry.

  1. Intégrez le service à la vigie applicative.

  2. Configurez l’agent ou le collecteur.

    • Lorsque vous utilisez l’agent CloudWatch, vous devez configurer metrics_collected avec un otlp. Par exemple, cloudwatch-config.json

      {
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  },
  "logs": {
    "metrics_collected": {
      "application_signals": {},
      "otlp": {
        "grpc_endpoint": "0.0.0.0:4317",
        "http_endpoint": "0.0.0.0:4318"
      }
    }
  }
}

    • Lorsque vous utilisez le collecteur OpenTelemetry, configurez un pipeline de métriques. Vous devez utiliser l’exportateur EMF CloudWatch pour le collecteur OpenTelemetry et activer les attributs de ressource pour les étiquettes de métriques. Il est recommandé de configurer dimension_rollup_option: NoDimensionRollup pour éviter d’émettre de nombreuses agrégations de métriques. Par exemple, config.yaml :

      receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  awsemf:
    region: $REGION
    namespace: $NAMESPACE
    log_group_name:$LOG_GROUP_NAME
    resource_to_telemetry_conversion:
      enabled: true
    dimension_rollup_option: "NoDimensionRollup"
    
  otlphttp/traces:
    compression: gzip
    traces_endpoint: https://xray.$REGION.amazonaws.com/v1/traces
    auth:
      authenticator: sigv4auth/traces

extensions:
  sigv4auth/logs:
    region: "$REGION"
    service: "logs"
  sigv4auth/traces:
    region: "$REGION"
    service: "xray"

processors:
  batch:

service:
  telemetry:
  extensions: [sigv4auth/logs, sigv4auth/traces]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [awsemf]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/traces]

  3. Configurez l'environnement. Lorsque plusieurs services portent le même nom et afin de corréler avec précision les métriques de la vigie applicative au nom de service correct, il est recommandé de configurer l’attribut de ressource deployment.environment.name. La configuration de cet attribut de ressource s’effectue généralement via les variables d’environnement.

    OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME,deployment.environment.name=$YOUR_ENV_NAME"

  4. Configurez l’exportation des métriques vers l’agent CloudWatch ou le collecteur OpenTelemetry. Vous pouvez utiliser l’une des approches suivantes :

    • (Recommandé) Pipeline d’exportation personnalisé : dans le code de l’application, créez un MeterProvider dédié qui exporte vers l’agent configuré ou le point de terminaison du collecteur. Par exemple :

      Resource resource = Resource.getDefault().toBuilder()
        .put(AttributeKey.stringKey("service.name"), serviceName)
        .put(AttributeKey.stringKey("deployment.environment.name"), environment)
        .build();

MetricExporter metricExporter = OtlpHttpMetricExporter.builder()
        .setEndpoint("http://localhost:4318/v1/metrics")
        .build();

MetricReader metricReader = PeriodicMetricReader.builder(metricExporter)
        .setInterval(Duration.ofSeconds(10))
        .build()

SdkMeterProvider meterProvider = SdkMeterProvider.builder()
    .setResource(resource)
    .registerMetricReader()
    .build();
    
Meter meter = meterProvider.get("myMeter");

    • Exportation basée sur l’agent : configurez les variables d’environnement de l’agent OTEL_METRICS_EXPORTER et OTEL_EXPORTER_OTLP_METRICS_ENDPOINT. Par exemple :

      OTEL_METRICS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://localhost:4318/v1/metrics

      Dans le code de l’application, utilisez le MeterProvider global créé par l’agent. Par exemple :

      Meter meter = GlobalOpenTelemetry.getMeter("myMeter");

  5. À l’aide du kit SDK de métriques OTEL dans le code de l’application, ajoutez les métriques OTEL. Par exemple, pour ajouter les métriques OTEL en Python :

    counter = meter.counterBuilder("myCounter").build();
counter.add(value);
counter.add(value, Attributes.of(AttributeKey.stringKey("Operation"), "myOperation"));

    L’ajout de l’attribut Operation n’est pas obligatoire, mais peut être utile pour corréler les opérations du service de la vigie applicative aux métriques OpenTelemetry personnalisées.

Métriques de portée

Les métriques de portée personnalisées ne fonctionnent actuellement qu’avec la recherche de transactions. Avec les métriques de portée personnalisées, vous pouvez :

  • Créer des métriques à l’aide de filtres de métriques

  • Traiter les attributs de portée ajoutés dans le code de l’application

  • Utiliser le kit SDK de traces OpenTelemetry pour la mise en œuvre

  1. Activer la surveillance de la vigie applicative avec la recherche de transactions. Pour plus d’informations, consultez Recherche de transactions.

    Pour garantir un échantillonnage des métriques à 100 %, il est recommandé d’envoyer 100 % des portées au point de terminaison.

  2. Ajoutez des attributs de portée à l’aide du kit SDK de traces OTEL. Il existe deux méthodes :

    • [Recommandé] Ajoutez des attributs aux portées générées automatiquement. Par exemple :

      Span.current().setAttribute("myattribute", value);

    • Ajoutez des attributs aux portées générées manuellement. Par exemple :

      Span span = tracer.spanBuilder("myspan").startSpan();
try (Scope scope = span.makeCurrent()) {
   span.setAttribute("myattribute",  value);
}

  3. Créez un filtre de métrique avec les valeurs suivantes. Pour plus d’informations sur la création d’un filtre de métrique, consultez Créer un filtre de métrique pour un groupe de journaux.

    • Groupe de journaux : aws/spans

    • Modèle de filtre : { $.attributes.['myattribute'] = * }

    • Nom de la métrique : myattribute (les valeurs doivent correspondre exactement, sinon la corrélation des intervalles ne fonctionnera pas)

    • Valeur de la métrique : $.attributes.['myattribute']

    • Dimensions – Nom du champ : Service, Valeur du champ : $.attributes.['aws.local.service'], Nom du champ : Environment, Valeur du champ : $.attributes.['aws.local.environment'], et Nom du champ : Operation, Valeur du champ : $.attributes.['aws.local.operation']

      Note

      Lorsque vous ajoutez des attributs à des portées générées manuellement, vous ne pouvez pas définir Operation car aws.local.operation ne sera pas présent dans les données de la portée.

Affichage des métriques personnalisées dans la vigie applicative

Vous pouvez désormais afficher les métriques personnalisées pour les services et les opérations dans la console de la vigie applicative :

  • Sélectionnez un service dans la liste Services pour afficher le nouvel onglet Métriques associées

  • Affichez les métriques standard, les métriques d’exécution et les métriques associées pour le service sélectionné

  • Filtrez et sélectionnez plusieurs métriques dans la liste

  • Représentez graphiquement les métriques sélectionnées pour identifier les corrélations et les causes racine des problèmes

Pour plus d’informations sur les métriques associées, consultez Afficher les métriques associées.

Questions fréquemment posées (FAQ)

Quel est l’impact de ne pas ajouter la configuration pour l’environnement des métriques personnalisées ?

La vigie applicative configure l’attribut de ressource deployment.environment.name pour lever toute ambiguïté entre les applications. La vigie applicative ne peut pas corréler les métriques personnalisées générées à partir de deux services différents portant le même nom avec le service correct sans lever l’ambiguïté.

Pour ajouter une configuration d’environnement à votre application, consultez Métriques OpenTelemetry.

Existe-t-il des limites pour les filtres de métrique ?

Vous ne pouvez créer que 100 filtres de métriques par groupe de journaux CloudWatch Logs. Chaque métrique définie peut avoir jusqu’à 3 dimensions. Vous pouvez consulter les limites des filtres de métriques ici Métriques OpenTelemetry.

Pourquoi les graphiques de métriques n’apparaissent-ils pas dans le tableau des métriques ?

La solution dépend de votre type de métrique :