Métriques custom à partir d'applications sans serveur

Présentation

Vous pouvez transmettre de plusieurs façons des métriques custom à Datadog depuis une fonction Lambda.

  • Créer des métriques custom à partir de logs ou de traces : si vos fonctions Lambda envoient déjà des données de trace ou de log à Datadog, et que les données à interroger sont stockées dans des logs ou traces, vous pouvez générer des métriques custom à partir de vos logs et traces sans avoir à redéployer le code de votre application ou à y apporter des modifications.
  • Envoyer des métriques custom à l’aide de l’extension Lambda Datadog : si vous souhaitez envoyer des métriques custom directement depuis votre fonction Lambda, Datadog vous recommande d’utiliser l’extension Lambda Datadog. Vérifiez si cette extension est prise en charge par le runtime de votre fonction Lambda.
  • Envoyer des métriques custom à l’aide du Lambda du Forwarder Datadog : si vous souhaitez envoyer des métriques custom à partir d’un runtime qui n’est pas pris en charge par l’extension Lambda Datadog, vous pouvez utiliser le Lambda du Forwarder Datadog.
  • (Obsolète) Envoyer des métriques custom depuis des logs CloudWatch : cette méthode consistant à envoyer des métriques custom en affichant un log au format MONITORING|<TIMESTAMP_EPOCH_UNIX>|<VALEUR_MÉTRIQUE>|<TYPE_MÉTRIQUE>|<NOM_MÉTRIQUE>|#<LISTE_TAGS> est désormais obsolète. Utilisez plutôt l’une des solutions ci-dessus.
  • (Non recommandé) Utiliser une bibliothèque tierce : la plupart des bibliothèques tierces n’envoient pas de métriques sous la forme de distributions, ce qui peut entraîner la perte de certaines valeurs.

Comprendre les métriques de distribution

Les métriques custom envoyées par les fonctions Lambda sont agrégées sous forme de distributions. En effet, elles sont conçues pour instrumenter des applications, sans tenir compte des hosts sous-jacents. Vous pouvez interroger les métriques à l’aide des agrégations avg, sum, max, min et count. Il est également possible d’activer les agrégations en centile (p50, p75, p90, p95, p99) et de gérer les tags des agrégations depuis la page Metric Summary.

Créer des métriques custom depuis des logs ou des traces

Avec des métriques basées sur des logs, vous pouvez enregistrer le nombre de logs qui correspondent à une requête ou résumer une valeur numérique contenue dans un log, comme la durée des requêtes. Les métriques basées sur des logs constituent une solution rentable vous permettant de synthétiser des données de log provenant de l’ensemble du flux d’ingestion. En savoir plus sur la création de métriques basées sur des logs.

Vous pouvez également générer des métriques à partir de l’ensemble des spans ingérées, qu’elles soient ou non indexées par un filtre de rétention. Consultez cette section pour en savoir plus sur la création de métriques basées sur des spans.

Avec l’extension Lambda Datadog

Collecte de métriques custom depuis AWS Lambda

Datadog recommande d’utiliser l’extension Lambda Datadog pour envoyer des métriques custom depuis des runtimes Lambda compatibles.

  1. Suivez les instructions d’installation générales de la surveillance sans serveur pour votre runtime Lambda.
  2. Si vous ne souhaitez pas recueillir de traces depuis votre fonction Lambda, définissez la variable d’environnement DD_TRACE_ENABLED sur false.
  3. Si vous ne souhaitez pas recueillir de logs depuis votre fonction Lambda, définissez la variable d’environnement DD_SERVERLESS_LOGS_ENABLED sur false.
  4. Importez et utilisez la fonction auxiliaire depuis la bibliothèque Lambda Datadog, par exemple lambda_metric ou sendDistributionMetric, pour envoyer vos métriques custom à partir de l’exemple de code.

SI votre fonction Lambda est exécutée sur un VPC, vérifiez qu’elle peut communiquer avec les endpoints d’API Datadog, que ce soit via une connexion publique, PrivateLink ou un proxy.

Avec le Forwarder Datadog

Datadog recommande d’utiliser le Lambda du Forwarder Datadog pour envoyer des métriques custom à partir des runtimes Lambda qui ne sont pas pris en charge par l’extension Lambda Datadog.

  1. Suivez les instructions d’installation générales de la surveillance sans serveur pour configurer votre fonction Lambda, installez la bibliothèque Lambda Datadog et la fonction Lambda du Forwarder Datadog, puis abonnez le Forwarder au groupe de logs de votre fonction.
  2. Si vous ne souhaitez pas recueillir de traces depuis votre fonction Lambda, définissez la variable d’environnement DD_TRACE_ENABLED sur false sur votre fonction Lambda.
  3. Si vous ne souhaitez pas recueillir de logs depuis votre fonction Lambda, définissez le paramètre DdForwardLog de la pile CloudFormation du Forwarder sur false.
  4. Importez et utilisez la fonction auxiliaire depuis la bibliothèque Lambda Datadog, par exemple lambda_metric ou sendDistributionMetric, pour envoyer vos métriques custom à partir de l’exemple de code.

Si votre runtime ne prend pas en charge la bibliothèque Lambda Datadog, vous pouvez afficher vous-même des métriques dans vos logs CloudWatch, au format JSON attendu. Sélectionnez l’onglet Autre dans la section relative à l’exemple de code pour en savoir plus.

Exemple de code pour l’envoi de métriques custom

Remarque : les arguments au sein des méthodes d’envoi des métriques custom doivent respecter les règles ci-dessous.

  • <NOM_MÉTRIQUE> identifie de façon unique votre métrique et respecte la stratégie de nommage des métriques.
  • <VALEUR_MÉTRIQUE> DOIT être un nombre (c’est-à-dire un entier ou un nombre flottant).
  • <LISTE_TAGS> est facultatif et mis en forme, par exemple : ['owner:Datadog', 'env:demo', 'cooltag'].
from datadog_lambda.metric import lambda_metric

def lambda_handler(event, context):
    lambda_metric(
        "coffee_house.order_value",             # Nom de la métrique
        12.45,                                  # Valeur de la métrique
        tags=['product:latte', 'order:online']  # Tags associés
    )
const { sendDistributionMetric } = require('datadog-lambda-js');

async function myHandler(event, context) {
    sendDistributionMetric(
        'coffee_house.order_value', // Nom de la métrique
        12.45, // Valeur de la métrique
        'product:latte', // Premier tag
        'order:online' // Deuxième tag
    );
    return {
        statusCode: 200,
        body: 'hello, dog!'
    };
}
package main

import (
  "github.com/aws/aws-lambda-go/lambda"
  "github.com/DataDog/datadog-lambda-go"
)

func main() {
  // Vous devez uniquement ajouter un wrapper autour du gestionnaire de votre fonction (et non autour des fonctions auxiliaires).
  lambda.Start(ddlambda.WrapFunction(myHandler, nil))
  /* OU utiliser des options de configuration manuelle
  lambda.Start(ddlambda.WrapFunction(myHandler, &ddlambda.Config{
    BatchInterval: time.Second * 15
    APIKey: "my-api-key",
  }))
  */
}

func myHandler(ctx context.Context, event MyEvent) (string, error) {
  ddlambda.Distribution(
    "coffee_house.order_value",     // Nom de la métrique
    12.45,                          // Valeur de la métrique
    "product:latte", "order:online" // Tags associés
  )
  // ...
}
require 'datadog/lambda'

def handler(event:, context:)
    # Vous devez uniquement ajouter un wrapper autour du gestionnaire de votre fonction (et non autour des fonctions auxiliaires).
    Datadog::Lambda.wrap(event, context) do
        Datadog::Lambda.metric(
          'coffee_house.order_value',         # Nom de la métrique
          12.45,                              # Valeur de la métrique
          "product":"latte", "order":"online" # Tags associés
        )
        return { statusCode: 200, body: 'Hello World' }
    end
end
public class Handler implements RequestHandler<APIGatewayV2ProxyRequestEvent, APIGatewayV2ProxyResponseEvent> {
    public Integer handleRequest(APIGatewayV2ProxyRequestEvent request, Context context){
        DDLambda dd = new DDLambda(request, lambda);

        Map<String,String> myTags = new HashMap<String, String>();
            myTags.put("product", "latte");
            myTags.put("order", "online");

        dd.metric(
            "coffee_house.order_value", // Nom de la métrique
            12.45,                      // Valeur de la métrique
            myTags);                    // Tags associés
    }
}

Écrivez une fonction réutilisable qui enregistre vos métriques custom au format suivant :

{
    "m": "Nom de la métrique",
    "v": "Valeur de la métrique",
    "e": "Timestamp Unix (en secondes)",
    "t": "Tableau de tags"
}

Par exemple :

{
    "m": "coffee_house.order_value",
    "v": 12.45,
    "e": 1572273854,
    "t": ["product:latte", "order:online"]
}

[OBSOLÈTE] CloudWatch Logs

Cette méthode d’envoi de métriques custom n’est plus prise en charge et n’est pas disponible pour les nouveaux clients. Utilisez plutôt l’une des solutions recommandées

Remarque : si vous utilisez l’une des solutions recommandées, vos prochaines métriques custom doivent être instrumentées sous de nouveaux noms lors de leur envoi à Datadog. Une métrique de distribution ne peut pas coexister avec une métrique d’un autre type dans Datadog si les deux portent le même nom.

Cette méthode nécessite d’ajouter les autorisations AWS suivantes dans votre [stratégie IAM Datadog][0].

Autorisation AWSDescription
logs:DescribeLogGroupsÉnumérer les groupes de logs disponibles.
logs:DescribeLogStreamsÉnumérer les flux de logs disponibles pour un groupe.
logs:FilterLogEventsRécupérer des événements de log spécifiques depuis un flux pour générer des métriques.

Pour envoyer des métriques custom à Datadog à partir de vos logs Lambda, affichez une ligne de log en utilisant le format suivant :

MONITORING|<TIMESTAMP_UNIX_EPOCH>|<VALEUR_MÉTRIQUE>|<TYPE_MÉTRIQUE>|<NOM_MÉTRIQUE>|#<LISTE_TAGS>

Où :

  • MONITORING signale à l’intégration Datadog que cette entrée de log doit être recueillie.
  • <UNIX_EPOCH_TIMESTAMP> est à définir en secondes, et non en millisecondes.
  • <VALEUR_MÉTRIQUE> DOIT être un nombre (c’est-à-dire un entier ou un nombre flottant).
  • <TYPE_MÉTRIQUE> correspond à count, gauge, histogram ou check.
  • <NOM_MÉTRIQUE> identifie de façon unique votre métrique et respecte la stratégie de nommage des métriques.
  • <LISTE_TAGS> est facultatif et doit être précédé de #. Les tags sont séparés par des virgules. Le tag function_name:<nom_de_la_fonction> est automatiquement appliqué aux métriques custom.

Remarque : la somme de chaque timestamp est utilisée pour les counts et la dernière valeur d’un timestamp donné est utilisée pour les gauges. Nous vous déconseillons d’afficher une déclaration de log chaque fois qu’une métrique est incrémentée, car cela augmente le temps d’analyse de vos logs. Mettez à jour de façon continue la valeur de la métrique dans votre code et affichez une déclaration de log pour cette métrique avant la fin de la fonction.

PREVIEWING: esther/docs-9518-update-example-control-sensitive-log-data