Présentation des anomalies opérationnelles

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Les anomalies opérationnelles identifient les modèles de données inhabituels ou inattendus avec vos API. Les anomalies opérationnelles surveillent en permanence les données et effectuent une analyse statistique pour détecter les anomalies.

Les anomalies opérationnelles détectent automatiquement les types d'anomalies suivants :

  • Augmentation du nombre d'erreurs HTTP 4xx ou 5xx au niveau de l'organisation, de l'environnement et de la région
  • Augmentation de la latence de réponse totale pour le 90e centile (p90) au niveau de l'organisation, de l'environnement et de la région

Par exemple, dans ce graphique du taux d'erreur de l'API, celui-ci augmente soudainement à environ 7 h. Par rapport aux données menant à cette période, cette augmentation est suffisamment inhabituelle pour être considérée comme une anomalie.

Graphique d'une anomalie liée au taux d'erreur

Les anomalies opérationnelles peuvent également distinguer les variations qui sont moins susceptibles d'indiquer des anomalies. Par exemple, vous pouvez constater des variations mineures du taux d'erreur menant à une anomalie, mais qui ne sont pas suffisamment importantes pour être classées comme anomalies.

Anomalie ou variation de données aléatoire.

Les anomalies opérationnelles vous permettent :

  • Afficher et examiner les anomalies : les anomalies opérationnelles signalent les événements d'API inhabituels (anomalies). Vous pouvez en afficher le détail pour savoir où et quand l'incident s'est produit, et déterminer ce qui l'a déclenché afin de pouvoir rapidement résoudre le problème.
  • Créer des alertes d'anomalies et configurer des notifications pour qu'Apigee vous envoie un message en cas d'incident.

Conditions préalables à l'utilisation des anomalies opérationnelles

Pour utiliser les anomalies opérationnelles :

Activer AAPI Ops dans une organisation

Pour utiliser AAPI Ops, vous devez l'activer dans votre organisation. Avant cela, commencez par obtenir un jeton d'accès OAuth 2.0. Vous pouvez ensuite activer AAPI Ops à l'aide d'un appel d'API qui transmet le jeton d'accès.

Afficher la configuration actuelle des modules complémentaires

Avant d'activer l'AAPI Ops, vérifiez si elle est déjà activée en effectuant l'appel d'API suivant :

curl "https://apigee.googleapis.com/v1/organizations/YOUR_ORG" \
  -X GET \
  -H "Content-type: application/json" \
  -H "Authorization: Bearer $TOKEN"

YOUR_ORG est le nom de votre organisation et $TOKEN est la variable d'environnement d'un jeton d'accès OAuth. Cela renvoie des informations de base sur votre organisation, qui incluent une section pour les modules complémentaires Apigee commençant par la ligne suivante :

"addonsConfig": {

Vérifiez si cette section contient une entrée commençant par "advancedApiOpsConfig", comme dans l'exemple suivant :

"advancedApiOpsConfig": {
          "enabled": "true"
      }

Si cette entrée est présente, l'AAPI Ops est déjà activée dans l'organisation. Si ce n'est pas le cas, vous devez l'activer comme décrit ci-dessous.

Activer AAPI Ops

Pour activer AAPI Ops dans l'organisation avec la configuration par défaut, envoyez une requête POST comme celle présentée ci-dessous :

curl "https://apigee.googleapis.com/v1/organizations/ORG:setAddons" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-type: application/json" \
  -d '{
    "addonsConfig": {
      "advancedApiOpsConfig": {
          "enabled": "true"
      }
      <Current add-ons configuration>
    }
  }'

<Current add-ons configuration> est la configuration actuelle des modules complémentaires. Celle-ci est indiquée dans la réponse à l'appel permettant d'afficher la configuration actuelle des modules complémentaires. Par exemple, si la configuration actuelle des modules complémentaires est :

"addonsConfig": {
    "integrationConfig": {
        "enabled":"true"
     },
    "monetizationConfig": {
        "enabled":"true"
     }
  },

la commande permettant d'activer AAPI Ops serait la suivante :

curl "https://apigee.googleapis.com/v1/organizations/YOUR_ORG:setAddons" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-type: application/json" \
  -d '{
    "addonsConfig": {
      "advancedApiOpsConfig": {
          "enabled": "true"
      },
    "integrationConfig": {
          "enabled": "true"
      },
    "monetizationConfig": {
          "enabled": "true"
      }
    }
  }'

Une fois la requête envoyée, une réponse semblable à celle-ci s'affiche :

{
  "name": "organizations/apigee-docs-d/operations/0718a945-76e0-4393-a456-f9929603b32c",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.apigee.v1.OperationMetadata",
    "operationType": "UPDATE",
    "targetResourceName": "organizations/apigee-docs-d",
    "state": "IN_PROGRESS"
  }
}

Désactiver AAPI Ops dans votre organisation

Si, pour une raison quelconque, vous devez désactiver AAPI Ops dans votre organisation, vous pouvez envoyer une requête POST en transmettant la configuration des modules complémentaires dans le corps de votre requête, comme indiqué ci-dessous.

curl "https://apigee.googleapis.com/v1/organizations/$ORG:setAddons" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-type: application/json" \
  -d '{
    "addonsConfig": {
      "advancedApiOpsConfig": {
          "enabled": "false"
      }
     <Include current add-ons configuration>
    }
  }'

Voici un exemple de réponse indiquant que l'opération est en cours :

{
  "name": "organizations/$ORG/operations/06274ffb-8940-41da-836d-781cba190437",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.apigee.v1.OperationMetadata",
    "operationType": "UPDATE",
    "targetResourceName": "organizations/$ORG",
    "state": "IN_PROGRESS"
  }
}

Pour en savoir plus, consultez la page Configurer l'API de modules complémentaires de l'organisation.

Fonctionnement de la détection d'anomalies

La détection d'anomalies implique les étapes suivantes :

Entraîner des modèles

Les anomalies opérationnelles consistent à entraîner un modèle du comportement de vos proxys d'API à partir de données de séries temporelles historiques. Aucune action n'est requise de votre part pour entraîner le modèle. Apigee crée et entraîne automatiquement des modèles à partir des données d'API des six dernières heures. Par conséquent, Apigee a besoin d'au moins six heures de données sur un proxy d'API pour entraîner le modèle avant de pouvoir enregistrer une anomalie.

L'objectif de l'entraînement est d'améliorer la précision du modèle, qui peut ensuite être testé sur des données historiques. Le moyen le plus simple de tester la précision d'un modèle consiste à calculer son taux d'erreur, c'est-à-dire la somme de faux positifs et de faux négatifs, divisée par le nombre total d'événements prévus.

Consigner les événements d'anomalies

Au moment de l'exécution, les anomalies opérationnelles comparent le comportement actuel de vos proxys d'API avec le comportement prédit par le modèle. Les anomalies opérationnelles peuvent alors déterminer, avec un niveau de confiance spécifique, lorsqu'une métrique opérationnelle dépasse la valeur prédite. Par exemple, lorsque le taux d'erreurs 5xx dépasse le taux prédit par le modèle.

Lorsque Apigee détecte une anomalie, il consigne automatiquement l'événement dans le tableau de bord des anomalies opérationnelles. La liste des événements affichés dans le tableau de bord inclut toutes les anomalies détectées, ainsi que les alertes déclenchées.