Introduction
Aujourd'hui, la plupart des organisations tournées vers l'avenir opèrent dans un environnement API-first, où les applications ne sont pas des entités autonomes mais des réseaux interconnectés de microservices. Avec ce changement, les contrôles de santé des API ont évolué, passant d'une simple interrogation des points d'extrémité à une observabilité à multiples facettes. Les entreprises peuvent adopter une approche de surveillance réactive et résoudre les problèmes au fur et à mesure qu'ils apparaissent ou investir dans une stratégie proactive soutenue par des signaux d'observabilité avancés et la prise en charge d'OpenTelemetry.
La voie réactive constitue souvent la base de référence. Pourtant, les solutions prêtes à l'emploi, alimentées par des plateformes de surveillance avancées, offrent une stratégie préventive plus holistique. Cependant, l'utilisation optimale de ces outils implique la prise en compte de multiples facteurs.
Dans cet article, nous examinons les principales caractéristiques des outils de surveillance des API, leur importance et la manière dont ils peuvent soutenir votre stratégie de surveillance globale.
Les huit fonctionnalités indispensables des outils modernes de surveillance des API
Le tableau ci-dessous résume les huit principales fonctionnalités indispensables que les ingénieurs DevOps attendent des outils modernes de surveillance des API. Notez que les fonctionnalités de base attendues de tout outil de surveillance, telles que les tableaux de bord, les rapports et les alertes, ne sont pas incluses dans cette liste car nous les considérons comme standard.
Signaux d'observabilité de l'API
L'observabilité des API permet aux équipes de maximiser les performances de tous les types d'API - privées, partenaires ou publiques. Les signaux d'observabilité - mesures, événements, journaux et traces - sont essentiels à cet égard. Ils fournissent collectivement une compréhension nuancée du comportement de l'API.
Chacun des quatre types de télémétrie a une valeur isolée ; toutefois, leur analyse collective fournit une vue d'ensemble de la santé et des performances de l'API.
Traces
Les traces cartographient le parcours des transactions de votre système et offrent des informations approfondies sur le comportement de vos points d'extrémité d'API en reliant les appels d'API individuels à des actions spécifiques. Imaginez une montée en puissance du trafic utilisateur qui déclenche une mise à l'échelle automatique des pods dans Kubernetes. Le traçage révèle comment la demande passe par l'équilibreur de charge, le serveur API, puis les instances de pods nouvellement créées, ce qui permet d'identifier toute latence ou erreur dans la mise à l'échelle automatique.
Une trace unique se compose de plusieurs travées, chacune couvrant différents microservices ou composants du système. Pour mieux comprendre, considérons chaque opération comme une étendue et un ensemble d'étendues comme une trace.
Lorsque vous évaluez des solutions de surveillance des API, tenez compte de la sophistication et de la flexibilité de leurs fonctions de traçage. Avec le traçage avancé, chaque plage peut également intégrer un contexte, tel que les requêtes SQL invoquées ou l'état de la mémoire cache de l'unité centrale. Ces travées sont reliées à des mesures et à des journaux, ce qui permet de créer un graphique de suivi complet. Vérifiez que les fonctions de visualisation de l'outil utilisent ces données pour cartographier avec précision les interactions des services afin de mettre en évidence les goulets d'étranglement potentiels et les inefficacités des services. Assurez-vous que la solution de traçage prend en charge tous les langages de programmation et toutes les technologies de base de données utilisés dans votre pile d'applications afin d'éviter les angles morts et de fournir une trace de haute fidélité. Une explication plus détaillée des portées et des traces est présentée dans la section suivante.
Métriques
Les métriques sont mesurées ou collectées à des intervalles distincts - allant de quelques millisecondes à quelques heures - pour capturer l'état de l'API. Il peut également s'agir de la télémétrie en temps réel de chaque demande, comme le temps de connexion à un point d'extrémité particulier de l'API. Cette double approche permet d'obtenir à la fois un instantané et une vue continue, offrant ainsi la représentation la plus complète des performances de votre API. Les données sont souvent classées par catégories pour une analyse nuancée qui vous permet d'évaluer à la fois le quoi et le pourquoi.
L'agrégation est toujours une option, mais la désagrégation à partir d'une moyenne ne donnera que des approximations. Plus le nombre de mesures brutes collectées est important, plus la résolution de votre analyse est élevée. Alors que l'échantillonnage permet d'obtenir une population approximative, la saisie des paramètres de performance de chaque demande permet une évaluation précise, moment par moment.
En guise de représentation, certaines mesures énumérées dans le tableau ci-dessous peuvent affecter directement/indirectement les performances d'une API.
{{banner-28="/design/banners"}}
Une fois les mesures en main, l'étape logique suivante consiste à consolider ces mesures disparates sous des formes plus faciles à gérer et à comprendre. L'utilisation de méthodes d'agrégation permet d'affiner les points de données brutes pour répondre à des questions spécifiques sur les performances. Voici quelques méthodes d'agrégation standard :
- Somme: Additionne toutes les valeurs. Utile pour compter le nombre total d'appels à l'API.
- Moyenne: La moyenne de toutes les valeurs métriques. Elle fournit une vue équilibrée mais est sensible aux valeurs aberrantes.
- Médiane: La valeur moyenne (identique au 50e percentile). Elle donne une tendance centrale plus stable que les moyennes.
- Percentiles: Indique une plage dans laquelle se situe un pourcentage particulier des valeurs observées. Aide à comprendre les valeurs aberrantes et le comportement du système sous différentes charges.
L'utilisation d'histogrammes avec des méthodes d'agrégation peut ajouter un autre niveau de granularité à votre surveillance d'API. Un histogramme regroupe les points de données en plages ou "bacs", offrant ainsi une vue de la distribution des fréquences. Par exemple, si vous étudiez la latence, un percentile peut révéler que la plupart de vos requêtes sont rapides, mais un histogramme montrera un nombre petit mais significatif de requêtes très lentes qui doivent être étudiées.
La sophistication de l'outil dans la gestion des mesures, l'application de diverses méthodes d'agrégation et l'utilisation d'histogrammes doit être un facteur déterminant dans votre choix.
Journaux
Les journaux offrent des détails granulaires qui sont exhaustifs. Une entrée de journal API standard peut inclure, par exemple, l'ID de la demande, la fonction de calcul sans serveur invoquée (telle que AWS Lambda), le taux de réussite ou d'échec du cache, et même les requêtes de base de données pertinentes. Une telle granularité facilite la corrélation des journaux d'événements et une évaluation précise de la sécurité.
Lors de l'évaluation d'un outil de surveillance des API, vérifiez s'il offre une agrégation centralisée des journaux. Cette fonction permet d'unifier les journaux de vos passerelles API, de vos points d'extrémité et de vos couches de service. Elle vous permet de suivre le parcours d'un appel API unique à travers plusieurs services, ce qui simplifie le débogage et accélère la résolution des incidents. La centralisation des données contextualisées permet également de faire la distinction entre les problèmes spécifiques aux API et les problèmes systémiques plus vastes.
Prenons par exemple les entrées de journal suivantes :
Erreur de dépendance du service
L'exemple ci-dessus met en évidence une erreur survenue dans un service dépendant lors du traitement d'une requête GET. Les journaux centralisés peuvent rapidement donner un aperçu des défaillances en cascade et de leur impact sur votre API.
Limite de débit dépassée
Une requête vers /api/v1/trekkers a dépassé la limite de taux. Grâce aux journaux centralisés, vous pouvez rapidement déterminer qui est responsable des appels excessifs et prendre des mesures correctives.
Il convient de noter que le stockage des journaux a un coût élevé en raison de leurs exigences de stockage. Une erreur courante consiste à collecter tous les types de journaux de tous les appareils à tout moment, alors qu'une approche plus stratégique consiste à sélectionner les journaux en fonction de leur valeur de dépannage et de leur pertinence pour les environnements de production.
{{banner-29="/design/banners"}}
Tests en plusieurs étapes
Les tests conventionnels vérifient principalement les points d'extrémité de manière isolée. Lors du choix d'un outil de surveillance des API, il convient de prendre en compte sa capacité à mettre en œuvre des tests de charge en plusieurs étapes qui simulent des interactions réelles, et pas seulement des appels isolés, afin de s'assurer qu'une API est fonctionnelle.
Une stratégie complète de test de l'API devrait inclure la plupart (sinon la totalité) des cas d'utilisation suivants :
Méthodes d'authentification sécurisées et diversifiées
Assurezl'efficacité de votre API dans différents contextes de sécurité. Recherchez la prise en charge d'utilisateurs virtuels et de diverses méthodes d'authentification, comme OAuth ou JWT, afin de reproduire les demandes de systèmes complexes. Le test en plusieurs étapes doit prendre en charge ces différents mécanismes d'authentification afin de reproduire fidèlement les expériences réelles des utilisateurs.
Cohérence entre les sites géographiques
Pour garantir la fiabilité globale d'une API, des tests en plusieurs étapes doivent être effectués à partir de différents lieux géographiques. Cela permet de s'assurer que chaque utilisateur bénéficie du même niveau de service, quel que soit l'endroit d'où il se connecte.
Répondre aux besoins de diverses plates-formes d'utilisateurs
On accède aux API par l'intermédiaire d'une grande variété de clients, depuis les applications mobiles jusqu'aux navigateurs de bureau. Les tests en plusieurs étapes doivent tenir compte de cette diversité, en offrant la possibilité d'émuler des interactions sur ces différentes plateformes et de dresser un tableau plus complet des performances globales de l'API.
Possibilité de contrôler l'ensemble du parcours de la transaction
L'une des principales lacunes de la surveillance des API est l'accent mis sur les composants situés à l'intérieur des limites du réseau d'une organisation. Il ne faut pas oublier que les API s'appuient généralement sur plusieurs points de contact externes, y compris des services tiers et divers éléments de l'internet public, pour réaliser une transaction.
Envisagez des outils de surveillance qui peuvent vous aider à analyser l'ensemble du chemin de la transaction et l'influence de l'internet public et de divers composants tiers sur les temps de réponse de votre API.
Surveillance synthétique et surveillance de l'utilisateur réel (RUM) : Simuler et vérifier la réalité
Nous avons abordé des techniques de surveillance telles que le traçage, qui permettent d'isoler les problèmes le long du chemin de la transaction ; dans cette section, nous aborderons la surveillance synthétique et la surveillance de l'utilisateur réel (RUM), qui se rapportent à ce que les utilisateurs finaux ressentent réellement par rapport à la manière dont l'environnement de l'application fonctionne. Mesurer l'expérience de l'utilisateur final permet d'éviter les scénarios dans lesquels les points finaux connus de l'API fonctionnent comme prévu, mais où les utilisateurs finaux subissent quand même un temps de réponse lent de l'interface utilisateur en raison de problèmes imprévus le long du chemin de la transaction.
La surveillance synthétique sert également d'expérience de contrôle dans votre paysage d'API, vous permettant d'exécuter des scénarios de simulation avec un trafic d'utilisateurs changeant. Pendant les périodes où la charge de travail est faible ou nulle, cette approche simule des appels d'API pour générer des données sur les performances. Vous obtenez ainsi une base de référence cohérente à mesurer lorsque le système est soumis à des contraintes ou même lorsque le trafic des utilisateurs est minime ou temporairement inexistant. La surveillance synthétique offre une émulation de transaction fiable et reproductible qui élimine la possibilité que les appareils clients de l'utilisateur final qui se comportent mal (comme un ordinateur de bureau lent) perturbent les relevés.
Plus important encore, lorsque les applications sont accessibles à partir de divers réseaux, la surveillance synthétique peut émuler des appels provenant de différents emplacements géographiques et réseaux de fournisseurs et vous aider à tester les performances de l'API à travers ces multiples voies. Alors que les tests synthétiques fournissent des informations scénarisées, l'utilisation de la surveillance des utilisateurs réels (RUM) permet de capturer les interactions non scénarisées du monde réel. Par exemple, les tests synthétiques peuvent révéler qu'une API fonctionne de manière optimale en Amérique du Nord, mais qu'elle présente des temps de latence en Asie ; le RUM peut valider cette information en montrant des plaintes d'utilisateurs ou des temps de transaction plus lents dans cette dernière région. Cette combinaison vous donne une vue interne et externe globale des performances de votre API, garantissant à tous vos utilisateurs des performances API cohérentes et optimales, quel que soit l'endroit où ils se connectent dans le monde.
{{banner-30="/design/banners"}}
Surveillance centrée sur l'utilisateur : Au-delà de la variabilité des plates-formes et des navigateurs
Il est fréquent de constater qu'une API fonctionne parfaitement sur un navigateur web moderne, mais qu'elle rencontre des difficultés sur une version plus ancienne ou un navigateur moins courant. Comme pour les versions modernes, les plateformes et les navigateurs interprètent et exécutent le code différemment. Certains peuvent disposer de moteurs JavaScript plus rapides, de meilleurs mécanismes de mise en cache ou de pipelines de rendu plus efficaces.
Choisissez un outil qui utilise l'analyse des agents utilisateurs pour séparer les mesures par navigateur et par système d'exploitation, ce qui permet d'enrichir votre base de données. Recherchez des fonctions qui vous permettent de segmenter les mesures en fonction de différentes dimensions pour une optimisation ciblée. Pouvez-vous filtrer les données de performance en fonction de la quantité de mémoire disponible sur l'appareil de l'utilisateur ? Pouvez-vous faire la distinction entre les expériences des utilisateurs urbains et ruraux ? Une telle analyse multidimensionnelle transforme les données en une structure plus navigable, ce qui permet de localiser plus facilement le problème de performance qui pourrait affecter un segment d'utilisateurs spécifique. L'outil choisi devrait également faciliter la surveillance de l'utilisateur réel côté client (RUM) afin de capturer des mesures dérivées de l'utilisation réelle de l'utilisateur final, comme le temps de chargement et le taux de réussite des transactions par plateforme et type de navigateur.
Naviguer dans des délais invisibles : DNS, FAI et CDN
Des recherches DNS lentes, des itinéraires retardés par les FAI ou des réseaux de diffusion de contenu (CDN) non réactifs introduisent une latence inattendue dans les réponses de votre API. Envisagez des outils offrant des alertes intelligentes pour signaler les problèmes tels que les retards de propagation DNS ou les manques de cache CDN. Ces outils devraient également inclure des diagnostics par traçage qui aident à visualiser les goulets d'étranglement du réseau à chaque saut.
Prise en charge du cadre open-source OpenTelemetry
Si les signaux d'observabilité sont fondamentaux, l'instrumentation jette les bases de l'exposition de l'état interne du système par le biais de traces, de mesures et de journaux en tant que données télémétriques.
Incubé par la Cloud Native Computing Foundation (CNCF) en 2019 et passé au statut de projet complet en 2021, OpenTelemetry est un cadre d'observabilité unifié pour collecter, générer, exporter et stocker des données de télémétrie. Ces données sont ensuite envoyées à un backend d'observabilité pour une analyse plus approfondie. La boîte à outils OpenTelemetry a deux utilités essentielles à cet égard :
- Propriété des données : Vous vous affranchissez des formats de données ou des outils propriétaires, ce qui vous donne un contrôle total sur les données télémétriques générées. Cela élimine également le risque de blocage des fournisseurs ou de paiement d'une prime pour une solution d'observabilité propriétaire, ce qui vous donne en fin de compte la flexibilité de choisir et de porter vers le meilleur outil de surveillance d'API adapté à votre cas d'utilisation.
- Normalisation et extensibilité : Favorise un ensemble unique d'API et de conventions, ce qui simplifie la courbe d'apprentissage pour les équipes. Qu'il s'agisse de traces, de mesures ou de journaux, l'adhésion aux formats OpenTelemetry rationalise l'ingestion de données dans différents outils d'observabilité sans modifier l'architecture sous-jacente.
Dans une configuration typique d'OpenTelemetry, le code de l'application instrumentée génère des portées et des métriques via l'API d'OpenTelemetry. Alors que les intervalles sont utilisés pour suivre le flux des requêtes à travers un système distribué, les métriques sont utilisées pour mesurer la performance d'un système. Les périodes et les mesures générées offrent des données brutes qui peuvent être incroyablement utiles pour mesurer les performances de l'API, suivre les demandes et comprendre la latence. Mais la puissance du framework ne se limite pas à la génération de données.
Le SDK OpenTelemetry applique également des règles d'échantillonnage et achemine les données par l'intermédiaire de divers processeurs. Les règles d'échantillonnage réduisent la quantité de données collectées, tandis que les processeurs transforment et enrichissent les données avant de les exporter.
Une fois ces données exportées vers un backend d'observabilité, vous pouvez les analyser pour surveiller la santé de l'API, suivre les mesures de performance et définir des alertes en cas d'anomalies. L'avantage est la possibilité d'une plateforme d'observabilité unifiée, où vous pouvez visualiser, analyser et corréler les traces et les mesures provenant de différentes parties d'un système, y compris les API.
{{banner-31="/design/banners"}}
Prise en charge des catalogues de services et de la documentation sur les API
Un catalogue de services offre généralement une vue plus large qui décrit les différents services (y compris les API) disponibles, qui peut y accéder et comment ils interagissent avec d'autres services. Lorsque vous évaluez les outils de surveillance des API, tenez compte de la compatibilité et de l'intégration entre votre catalogue de services et la spécification OpenAPI (OAS). Évaluez dans quelle mesure ils prennent en charge la création, la gestion et les modifications en temps réel des API.
La spécification OpenAPI (OAS) facilite l'élaboration d'un plan à double usage pour les API basées sur le protocole HTTP qui servent à la fois les développeurs et les machines. Cette double fonctionnalité s'étend au-delà de la documentation de l'API pour actualiser la logique de mise en œuvre, la création de SDK et les tests par le biais de serveurs fictifs, le tout orchestré à partir d'un seul fichier OpenAPI. L'adoption d'OpenAPI dans votre stratégie de surveillance offre la possibilité de générer automatiquement des contrôles de surveillance et des versions explicites à partir du fichier de description de l'OAS. Cela permet de s'assurer que même les API les plus obscures - celles qui sont obsolètes ou les versions plus anciennes - ne restent pas sans surveillance.
Étant donné que le fichier OpenAPI contient tous les détails concernant les points d'extrémité de l'API et les structures de demande/réponse, il fournit essentiellement toutes les informations dont un outil de surveillance a besoin pour vérifier le comportement de l'API. L'outil configure automatiquement ces vérifications en fonction de vos spécifications OpenAPI, ce qui garantit que vos API fonctionnent toujours de manière optimale dans des délais acceptables.
Il est important de choisir un outil de surveillance des API qui peut s'intégrer à OpenAPI afin d'éviter de créer des îlots distincts d'informations de catalogue qui peuvent diverger au fil du temps en l'absence d'une source unique de vérité.
Intégration avec les pipelines CI/CD
Si votre entreprise pratique la livraison continue pour mettre le code en production, votre outil de surveillance des API doit être intégré à une plateforme de livraison continue telle que Jenkins. Une approche de surveillance avec décalage à gauche permet le déploiement simultané des configurations de surveillance pendant la planification du sprint. Le décalage à gauche garantit que les points d'extrémité des API nouvelles ou mises à jour sont immédiatement surveillés, ce qui réduit le délai pendant lequel les problèmes peuvent passer inaperçus. Recherchez les caractéristiques suivantes dans vos outils de surveillance des API.
Repérer instantanément les nouvelles API
Dès qu'une nouvelle API est intégrée dans le référentiel de code et déployée via le pipeline CI/CD, l'outil de surveillance doit être en mesure de détecter ce changement. Si l'API est conçue à l'aide de la spécification OpenAPI (OAS), l'outil peut configurer automatiquement ses contrôles sur la base du fichier OAS fourni.
Actualisation des modifications de l'API
Le code d'une application évolue constamment. Les changements de versions d'API, l'introduction de nouveaux points d'accès ou les modifications apportées aux points d'accès existants doivent être immédiatement transmis à l'outil de surveillance via le pipeline CI/CD. Cette visibilité précoce est cruciale pour des ajustements immédiats et précis des configurations de surveillance.
Ajout automatique de nouveaux points d'extrémité
Chaque fois que de nouveaux points d'extrémité sont introduits ou découverts dans le pipeline CI/CD, ils sont automatiquement ajoutés à l'outil de surveillance pour être observés. Cela permet de s'assurer que tous les points d'extrémité sont inspectés avant d'être mis en service et de réduire les angles morts de votre stratégie de surveillance.
Tableau de bord et alertes
Une intégration précoce signifie également des avertissements précoces. Dans le cadre de l'intégration CI/CD, les tableaux de bord peuvent être mis à jour automatiquement pour refléter les API nouvellement déployées ou modifiées. Vous devriez être en mesure de définir automatiquement des règles d'alerte basées sur des conditions prédéfinies, garantissant des notifications en temps réel par le biais de webhooks pour toute anomalie.
L'éthique de l'intégration défend essentiellement le concept de "surveillance en tant que code", une pratique qui consiste à établir simultanément une stratégie de surveillance des API robuste et proactive lors de l'écriture, du test et du déploiement de votre code.
{{banner-32="/design/banners"}}
Prise en charge de tous les types d'API
Dans un cadre microservices, votre application utilisera probablement différents types d'API : SOAP pour les services hérités, REST pour les services web, HTTP pour les appels fondamentaux et GraphQL pour les besoins en données plus personnalisés. Pour chacune de ces instances, l'instrumentation manuelle implique généralement l'intégration d'une logique de surveillance pour chaque point de terminaison d'API. Cette approche offre un contrôle granulaire, mais au prix d'une perte de temps et d'inexactitudes humaines potentielles.
Un service de surveillance des API intégré à un kit de développement logiciel (SDK) constitue une solution plus efficace. Lorsqu'elles sont intégrées à votre pile technologique, ces bibliothèques précompilées injectent automatiquement la logique de surveillance nécessaire dans votre base de code. Aujourd'hui, la plupart des kits de développement logiciel prennent également en charge les différents types d'API et peuvent se configurer automatiquement en fonction de l'OAS. Cette automatisation réduit les erreurs humaines et le temps de configuration et garantit la cohérence des configurations de surveillance.
Les outils prenant en charge OpenTelemetry bénéficient d'une instrumentation manuelle et automatique pour différents langages de programmation. L'approche mixte rationalise la collecte de données télémétriques en offrant des API et des SDK pour les applications d'instrumentation personnalisées. Une configuration typique peut aller de la définition de variables environnementales à des propriétés système spécifiques à un langage. L'ensemble de ces options offre la possibilité de configurer les sources de données, les exportateurs et l'utilisation des ressources afin d'enrichir les données de télémétrie. Les bibliothèques instrumentées de manière native peuvent invoquer automatiquement les API d'OpenTelemetry, ce qui élimine la nécessité d'un codage personnalisé.
Pour ceux qui ne le sont pas, OpenTelemetry fournit des bibliothèques d'instrumentation spécifiques à chaque langue afin de rendre l'intégration de la télémétrie universellement accessible.
Prise en charge des microservices et de l'informatique sans serveur.
Dans un paysage moderne où la priorité est donnée aux API, celles-ci ne fonctionnent plus de manière isolée. Au contraire, elles font partie d'un écosystème plus large de services interdépendants, chacun ayant son propre ensemble d'API. Les entreprises doivent désormais se concentrer sur l'observabilité à l'échelle du système qui correspond à cette complexité.
Prenons l'exemple des microservices. Ces services modulaires communiquent par l'intermédiaire d'API REST, chacun remplissant une fonction distincte mais contribuant collectivement à une transaction. Une seule transaction peut passer par plusieurs de ces services, chacun ayant sa propre API. En outre, les microservices interagissent souvent par l'intermédiaire de gRPC, un cadre open-source très performant qui permet de multiples types de communication. Si votre outil de surveillance n'est pas capable de tracer chaque appel dans un tel cadre, la résolution des problèmes devient un défi monumental.
Les maillages de services tels que Istio, Consul by Hashicorp et Linkerd offrent une autre couche de complexité. Ils contrôlent la manière dont les différentes parties d'une application partagent les données et les services, en ajoutant une couche d'abstraction pour une communication sécurisée, fiable et rapide entre les services. L'impossibilité de contrôler cette couche ajoute un autre angle mort à votre paysage d'observabilité.
Et si vous tirez parti d'une architecture sans serveur, notez que la dépendance aux API pour activer les fonctions est fondamentale. Par exemple, AWS API Gateway sert de canal entre les fonctions sans serveur comme AWS Lambda et le système plus large. Ce service va au-delà du simple routage des demandes, offrant des capacités telles que la gestion du trafic et la composition d'API.
Surveillance de l'infrastructure à plusieurs niveaux
Certaines entreprises peuvent mal évaluer la corrélation entre l'observabilité de l'infrastructure et la surveillance des API. En se concentrant sur les points d'extrémité des API, elles négligent souvent les couches sous-jacentes de l'infrastructure qui ont un impact sur les performances des API.
Comme chaque couche d'abstraction s'accompagne de son propre ensemble de complexités et de mesures, le défi consiste à croiser les données entre ces couches disparates pour obtenir une vue intégrée. Il est essentiel d'utiliser des outils spécialisés capables de diagnostiquer les problèmes à plusieurs niveaux de votre infrastructure.
Envisagez un outil qui offre une vue intégrée des différentes couches de la pile technologique. Les outils spécialisés capables d'assurer une surveillance à plusieurs niveaux sont essentiels pour deux raisons : ils aident à diagnostiquer les problèmes entre les couches abstraites et offrent un aperçu complet de l'état de santé de votre API.
Commencez par les serveurs qui hébergent votre API. Les principales mesures à prendre en compte sont généralement l'utilisation de l'unité centrale, la taille du tas de la JVM, le nombre de threads et la latence du réseau. Tout pic à ce niveau peut directement affecter la réactivité de votre API, entraînant une augmentation de la latence et une réduction du débit.
La couche suivante concerne les bases de données et les services tiers avec lesquels votre API interagit. Le temps d'exécution des requêtes, les temps de réponse de l'API, les taux d'erreur, la mise en commun des connexions et les mécanismes de mise en cache sont des mesures critiques qui peuvent signaler des signes avant-coureurs d'un ralentissement de l'expérience de l'utilisateur final.
Contrairement aux approches de surveillance traditionnelles au niveau de l'hyperviseur et de la couche VM, les environnements conteneurisés apportent des couches supplémentaires à l'écosystème. Assurez-vous que l'outil que vous avez choisi surveille les systèmes d'orchestration tels que Kubernetes. Les mesures telles que les statuts des pods, les quotas de ressources et les contrôles de santé des conteneurs offrent différentes couches d'informations sur les performances de l'API.
Conclusion
La véritable valeur d'un outil de surveillance des API va au-delà de la simple collecte de données et de l'offre d'informations sur lesquelles vous pouvez agir. Il doit être suffisamment flexible pour s'adapter aux différents comportements des API, être capable d'interpréter des mesures complexes et s'intégrer de manière transparente à vos pipelines DevOps.
Bien que les fonctionnalités avancées telles que les tests en plusieurs étapes, les histogrammes et l'agrégation centralisée des journaux ajoutent de la profondeur à votre surveillance de l'API, elles ne sont pas garanties contre toutes les anomalies. Cela n'enlève rien à l'importance de l'adoption de ces stratégies.
CatchpointLe cadre de l' observabilité de va au-delà des mesures de base pour exécuter des transactions API qui testent la fonctionnalité, exécutent des charges utiles et analysent les réponses attendues. La plateforme Catchpoint surveille également votre réseau de points d'extrémité d'API et intègre les mesures de l'API avec les mesures de l'expérience de l'utilisateur final mesurées par la surveillance synthétique et la surveillance de l'utilisateur réel (RUM) et les met en corrélation avec les mesures de performance DNS et CDN ayant un impact sur le chemin de la transaction de bout en bout. Cela ajoute une autre dimension à la surveillance de votre API, raccourcit le temps de dépannage et offre une résolution proactive des problèmes.
Pour en savoir plus sur la façon dont Catchpoint offre une approche holistique de l'observabilité des API qui va au-delà de la simple surveillance, explorez une démo ici.
