Création d’un connecteur personnalisé à une source de données

Cette rubrique décrit comment connecter une source de données personnalisée à CloudWatch. Vous pouvez connecter une source de données personnalisée à CloudWatch de deux manières :

Utilisation d’un modèle

L’utilisation d’un modèle crée un exemple de fonction Lambda et peut vous aider à créer votre connecteur personnalisé plus rapidement. Ces exemples de fonctions fournissent des exemples de code pour de nombreux scénarios courants liés à la création d’un connecteur personnalisé. Vous pouvez examiner le code Lambda après avoir créé un connecteur avec un modèle, puis le modifier pour l’utiliser pour vous connecter à votre source de données.

En outre, si vous utilisez le modèle, CloudWatch se charge de créer la politique d’autorisations Lambda et d’associer des balises de ressources à la fonction Lambda.

Création d’une source de données personnalisée de toutes pièces

Suivez les étapes de cette section pour créer une fonction Lambda qui connecte CloudWatch à une source de données.

Étape 1 : créer la fonction

Un connecteur de source de données personnalisé doit prendre en charge les événements GetMetricData provenant de CloudWatch. Vous pouvez également éventuellement implémenter un événement DescribeGetMetricData pour fournir aux utilisateurs de la documentation sur l’utilisation du connecteur dans la console CloudWatch. La réponse DescribeGetMetricData peut également être utilisée pour définir les valeurs par défaut utilisées dans le générateur de requêtes personnalisées CloudWatch.

CloudWatch fournit des extraits de code sous forme d’exemples pour vous aider à démarrer. Pour plus d’informations, veuillez consulter le référentiel d’exemples à l’adresse https://github.com/aws-samples/cloudwatch-data-source-samples.

Contraintes

Evénement GetMetricData

Charge utile de la requête

Voici un exemple de charge utile de la requête GetMetricData envoyée en entrée à la fonction Lambda.

{
  "EventType": "GetMetricData",
  "GetMetricDataRequest": {
    "StartTime": 1697060700,
    "EndTime": 1697061600,
    "Period": 300,
    "Arguments": ["serviceregistry_external_http_requests{host_cluster!=\"prod\"}"] 
  }
}

Charge utile de la réponse

Voici un exemple de charge utile de la réponse GetMetricData renvoyée par la fonction Lambda.

{
   "MetricDataResults": [
      {
         "StatusCode": "Complete",
         "Label": "CPUUtilization",
         "Timestamps": [ 1697060700, 1697061000, 1697061300 ],
         "Values": [ 15000, 14000, 16000 ]
      }
   ]
}

La charge utile de la réponse contiendra soit un champ MetricDataResults, soit un champ Error, mais pas les deux.

Un champ MetricDataResults est une liste de champs de séries temporelles de type MetricDataResult. Chacun de ces champs de série temporelle peut comprendre les champs suivants.

Pour en savoir plus sur les objets Error, veuillez consulter les sections suivantes.

Formats de réponse aux erreurs

Vous pouvez éventuellement utiliser la réponse d’erreur pour fournir plus d’informations sur les erreurs. Nous vous recommandons de renvoyer une erreur lors de la validation du code lorsqu’une erreur de validation se produit, par exemple lorsqu’un paramètre est manquant ou de type incorrect.

Voici un exemple de réponse lorsque la fonction Lambda souhaite déclencher une exception de validation GetMetricData.

{
   "Error": {
      "Code": "Validation",
      "Value": "Invalid Prometheus cluster"
   }
}

Voici un exemple de réponse lorsque la fonction Lambda indique qu’elle n’est pas en mesure de renvoyer des données en raison d’un problème d’accès. La réponse est traduite en une seule série chronologique avec un code d’état Forbidden.

{
   "Error": {
      "Code": "Forbidden",
      "Value": "Unable to access ..."
   }
}

Voici un exemple de cas où la fonction Lambda déclenche une exception globale InternalError, qui est traduite en une série temporelle unique avec un code d’état InternalError et un message. Chaque fois qu’un code d’erreur a une valeur autre que Validation ou Forbidden, CloudWatch part du principe qu’il s’agit d’une erreur interne générique.

{
   "Error": {
      "Code": "PrometheusClusterUnreachable",
      "Value": "Unable to communicate with the cluster"
   }
}

Evénement DescribeGetMetricData

Charge utile de la requête

L’exemple qui suit illustre la charge utile d’une requête DescribeGetMetricData.

{
  "EventType": "DescribeGetMetricData"
}

Charge utile de la réponse

L’exemple qui suit illustre la charge utile d’une réponse DescribeGetMetricData.

{
    "Description": "Data source connector",
    "ArgumentDefaults": [{
        Value: "default value"
     }]
}

Considérations importantes relatives aux alarmes CloudWatch

Si vous comptez utiliser la source de données pour configurer des alarmes CloudWatch, vous devez la configurer pour qu’elle rapporte les données avec horodatage toutes les minutes à CloudWatch. Pour plus d’informations et d’autres considérations relatives à la création d’alarmes sur des métriques provenant de sources de données connectées, veuillez consulter la rubrique Création d’une alarme basée sur une source de données connectée.

(Facultatif) Utilisation de AWS Secrets Manager pour le stockage des informations d’identification

Si votre fonction Lambda doit utiliser des informations d’identification pour accéder à la source de données, nous vous recommandons d’utiliser AWS Secrets Manager pour stocker ces informations d’identification au lieu de les coder en dur dans votre fonction Lambda. Pour plus d’informations sur l’utilisation d’AWS Secrets Manager avec Lambda, veuillez consulter la rubrique Utilisez des secrets AWS Secrets Manager dans les fonctions AWS Lambda.

(Facultatif) Connexion à une source de données dans un VPC

Si votre source de données se trouve dans un VPC géré par Amazon Virtual Private Cloud, vous devez configurer votre fonction Lambda pour y accéder. Pour plus d’informations, veuillez consulter la rubrique Connexion des réseaux sortants aux ressources d’un VPC.

Vous devrez peut-être également configurer les points de terminaison du service VPC pour accéder à des services tels qu’AWS Secrets Manager. Pour plus d’informations, consultez Accès à un service AWS à l’aide du point de terminaison d’un VPC d’interface.

Étape 2 : créer une stratégie d’autorisations Lambda

Vous devez créer une déclaration de politique qui accorde à CloudWatch l’autorisation d’utiliser la fonction Lambda que vous avez créée. Vous pouvez utiliser l’AWS CLI ou la console Lambda pour créer la déclaration de politique.

Étape 3 : attacher une balise de ressource à la fonction Lambda

La console CloudWatch détermine quelles fonctions Lambda sont des connecteurs de source de données à l’aide d’une balise. Lorsque vous créez une source de données à l’aide de l’un des assistants, la balise est automatiquement appliquée par la pile CloudFormation qui la configure. Lorsque vous créez vous-même une source de données, vous pouvez utiliser la balise suivante pour votre fonction Lambda. Cela fait apparaître votre connecteur dans la liste déroulante Sources de données de la console CloudWatch lorsque vous interrogez des métriques.