Objectifs de niveau de service API

L'authentification par clé de session ( Instana ) API authentifie les requêtes à l'aide d'une clé de session ( API ) dans l'en-tête de requête d'autorisation ( HTTP ).

Exemple : l'exemple suivant utilise l'interface REST API avec curl pour récupérer toutes les métriques disponibles avec les agrégations possibles à l'aide d'un appel GET.

curl --request GET \
  --url https://instana.rocks/api/application-monitoring/catalog/metrics \
  --header 'authorization: apiToken xxxxxxxxxxxxxxxx'
 

Vous pouvez accéder à toutes les API d' Instana s directement depuis un navigateur Web après vous être connecté à l'interface utilisateur d' Instana. Entrez l'adresse URL dans le champ d'adresse du navigateur, puis appuyez sur Entrée. Une requête GET est envoyée au backend Instana avec les cookies de session utilisateur connecté existants.

Limitation : les navigateurs ne pouvant envoyer que des requêtes GET directement, les autres méthodes d' HTTP s ne sont pas possibles, sauf si elles sont prises en charge via l'intégration d'extensions tierces.

Pour accéder à toute l' API relative Configuration of service level indicators aux SLO à l'aide d'un jeton API, une autorisation est requise pour le jeton API correspondant.

La charge utile représente le contenu du corps de l' JSON pour l'objet de configuration SLO. Les actions GET, POST, DELETE et PUT sont utilisées pour récupérer, créer, supprimer et mettre à jour la configuration SLO. Pour plus d'informations sur ces éléments et leurs interactions, consultez la documentation « SLO Configurations » sur API.

Le SLO suivant surveille la saturation du processeur sur les hôtes de production, avec pour objectif une disponibilité de 99 % et une utilisation moyenne du processeur inférieure à 80 %. Le budget d'erreur est calculé en minutes sur une période de 7 jours consécutifs. Le budget d'erreurs utilise le modèle de saturation avec un indicateur basé sur le temps pour aider à garantir que les hôtes maintiennent des niveaux de CPU sains.

Charge utile :

  {
  "name": "Production Host CPU Saturation",
  "target": 0.99,
  "entity": {
    "type": "infrastructure",
    "infraType": "host",
    "tagFilterExpression": {
      "type": "TAG_FILTER",
      "name": "host.name",
      "stringValue": "prod-web-01",
      "numberValue": null,
      "booleanValue": null,
      "floatValue": null,
      "key": null,
      "value": "prod-web-01",
      "operator": "EQUALS",
      "entity": "NOT_APPLICABLE"
    }
  },
  "indicator": {
    "type": "timeBased",
    "metricName": "cpu.sys",
    "threshold": 0.8,
    "operator": ">=",
    "aggregation": "MEAN",
    "blueprint": "saturation"
  },
  "timeWindow": {
    "type": "rolling",
    "duration": 7,
    "durationUnit": "day",
    "timezone": "UTC"
  },
  "tags": [
    "infrastructure",
    "host",
    "cpu",
    "saturation"
  ]
}
 

Le SLO suivant surveille la saturation de la mémoire dans un cluster d' Kubernetes s à l'aide d'un indicateur basé sur les événements, avec un objectif de disponibilité de 95 %. Les événements sont classés comme bons lorsque le ratio mémoire est inférieur au seuil et comme mauvais lorsqu'il atteint ou dépasse le seuil. Le budget d'erreur est calculé pour chaque événement sur une période de 30 jours consécutifs à l'aide du modèle de saturation.

Charge utile :

 {
  "name": "K8s Cluster Memory Saturation",
  "target": 0.95,
  "entity": {
    "type": "infrastructure",
    "infraType": "kubernetesCluster",
    "tagFilterExpression": {
      "type": "TAG_FILTER",
      "name": "kubernetes.cluster.name",
      "stringValue": "production-cluster",
      "numberValue": null,
      "booleanValue": null,
      "floatValue": null,
      "key": null,
      "value": "production-cluster",
      "operator": "EQUALS",
      "entity": "NOT_APPLICABLE"
    }
  },
  "indicator": {
    "type": "eventBased",
    "metricName": "limitCapacityMemoryRatio",
    "threshold": 0.75,
    "operator": ">=",
    "aggregation": "MEAN",
    "blueprint": "saturation"
  },
  "timeWindow": {
    "type": "rolling",
    "duration": 30,
    "durationUnit": "day",
    "timezone": "UTC"
  },
  "tags": [
    "infrastructure",
    "kubernetes",
    "memory",
    "saturation"
  ]
}

Le SLO suivant utilise un indicateur personnalisé pour surveiller l'état du conteneur AWS ECS en fonction de métriques personnalisées, avec un objectif de disponibilité de 99 %. Les événements sont classés comme bons lorsque l'utilisation du processeur du conteneur est inférieure à 70 % et comme mauvais lorsqu'elle dépasse ce seuil. Cela démontre la flexibilité des indicateurs personnalisés dans le cadre de la surveillance des infrastructures adaptée aux besoins spécifiques des entreprises.

Charge utile :

 {
  "name": "ECS Container Custom Health",
  "target": 0.99,
  "entity": {
    "type": "infrastructure",
    "infraType": "awsEcsContainer",
    "tagFilterExpression": {
      "type": "TAG_FILTER",
      "name": "aws.ecs.cluster.name",
      "stringValue": "production-ecs-cluster",
      "numberValue": null,
      "booleanValue": null,
      "floatValue": null,
      "key": null,
      "value": "production-ecs-cluster",
      "operator": "EQUALS",
      "entity": "NOT_APPLICABLE"
    }
  },
  "indicator": {
    "type": "eventBased",
    "goodEventsFilter": {
      "type": "TAG_FILTER",
      "name": "cpu.usage",
      "stringValue": null,
      "numberValue": 0,
      "booleanValue": null,
      "floatValue": 0.7,
      "key": null,
      "value": 0.7,
      "operator": "LESS_THAN",
      "entity": "NOT_APPLICABLE"
    },
    "badEventsFilter": {
      "type": "TAG_FILTER",
      "name": "cpu.usage",
      "stringValue": null,
      "numberValue": 0,
      "booleanValue": null,
      "floatValue": 0.7,
      "key": null,
      "value": 0.7,
      "operator": "GREATER_OR_EQUAL_THAN",
      "entity": "NOT_APPLICABLE"
    },
    "goodEventInfraMetric": "cpu.usage",
    "badEventInfraMetric": "cpu.usage",
    "blueprint": "custom",
    "operator": null,
    "threshold": 0,
    "aggregation": "MEAN"
  },
  "timeWindow": {
    "type": "rolling",
    "duration": 1,
    "durationUnit": "week",
    "timezone": "America/New_York"
  },
  "tags": [
    "infrastructure",
    "aws",
    "ecs",
    "custom"
  ]
}

Les API de base suivantes permettent de créer, récupérer, mettre à jour et supprimer la configuration SLO sans interaction avec l'interface utilisateur. Le document « API » (L'impact des changements climatiques sur les ressources en eau) est disponible à l'adresse suivante : Instana GitHub.

Les SLO Legacy et Lite ont été mis en œuvre différemment du SLO précédent. L'indicateur de niveau de service (SLI) est un élément de configuration essentiel. Le SLO fait partie des paramètres du tableau de bord personnalisé permettant d'afficher les résultats en matière de niveau de service conformément aux exigences de l'entreprise.

• L'interface de configuration SLI ( API ) fournit des points de terminaison permettant de créer, de lire, de mettre à jour et de supprimer des configurations SLI pour les configurations SLI classiques et Lite.
• Les widgets de tableau de bord personnalisés API sont utilisés pour gérer les tableaux de bord personnalisés et les widgets SLO.

À titre d'exemple, la commande curl suivante peut être utilisée pour créer un SLI basé sur le temps nommé My First SLI pour une application avec l'ID appId qui dispose d'un service avec l'ID serviceId et qui est limité aux appels où l'ID du point de terminaison est égal à endpointId. Le SLI est agrégé pour le 90e centile de la latency métrique et une valeur seuil de 25 ms.

curl --location --request POST "{{base}}/api/settings/v2/sli" \
  --header "Authorization: apiToken {{apiToken}}" \
  --header "Content-Type: application/json" \
  --data '{
    "sliName": "My first SLI",
    "metricConfiguration": {
        "metricName": "latency",
        "metricAggregation": "P90",
        "threshold": 25
    },
    "sliEntity": {
        "sliType": "application",
        "applicationId": "appId",
        "serviceId": "serviceId",
        "endpointId": "endpointId",
        "boundaryScope": "ALL"
    }
  }'
 

Tout comme le rapport SLO API, le rapport SLI peut être invoqué pour renvoyer Legacy et les rapports Lite SLI. Contrairement au rapport SLO API, l'objectif SLO doit être fourni dans la demande.

Par exemple :

• Demande

https://instana.rocks/api/sli/report/Ca_h3OGvT3iu5Kt6LVsJ7g?slo=0.9&to=1743451200000&from=1743444000000
 

• Réponse

{
  "sli": 0.9166666666666666,
  "slo": 0.9,
  "totalErrorBudget": 12,
  "errorBudgetRemaining": 2,
  "fromTimestamp": 1743444000000,
  "toTimestamp": 1743451200000,
  "violationDistribution": {
    "0": 1,
    "1": 1,
    "2": 1,
    "3": 1,
    "4": 1,
    "5": 1,
    "6": 1,
 ... ...
    "99": 1,
    "100": 0
  }
}