Cette page a été traduite de l’anglais.
Outils pour développeurs
Créer un tableau de bord de surveillance et d’analyse d’API
Kliv est un constructeur d’applications par IA. Décrivez le tableau de bord de surveillance et d’analyse d’API dont vous avez besoin — sondes, budgets, consommation partenaire, incidents, pages de statut et alertes Slack — et il le construit.
Entrez simplement votre idée dans la zone de texte et AI la construira pour vous
Qu’est-ce que Kliv ?
Kliv n’est pas un éditeur de supervision avec des tableaux de bord figés — c’est une IA qui construit le logiciel pour vous.
Vous décrivez l’application dont vous avez besoin en langage courant, et Kliv construit la base de données, la logique, les écrans et les tâches planifiées. Vous êtes propriétaire du résultat, vous l’exécutez sur vos propres comptes, et vous pouvez le faire évoluer plus tard simplement en le demandant. Ce n’est pas un tableau de bord préfabriqué.
Sur cette page, cette application est un tableau de bord de surveillance et d’analyse d’API. Kliv construit toutes sortes d’applications web ; celle-ci surveille les points de terminaison, les partenaires, les budgets, les incidents et les pages de statut selon les besoins de votre équipe.
Pourquoi construire votre propre surveillance d’API ?
La plupart des outils de surveillance partent des URL et de la disponibilité. C’est utile, mais une équipe avec des intégrations partenaires a généralement besoin de réponses plus précises : quel partenaire consomme le plus de budget, quel point de terminaison a changé de comportement, qui a pris en charge l’alerte, et ce que disait la page de statut publique à ce moment-là.
Kliv construit la supervision autour de vos propres notions. Les points de terminaison ont des responsables et des budgets. Les partenaires ont des clés et une consommation. Les incidents ont une chronologie. La page de statut, les alertes et le post-mortem s’appuient tous sur le même historique, au lieu de le recopier dans des outils séparés.
Points de terminaison, sondes et budgets
Le tableau de bord repose sur des données que votre équipe peut inspecter.
Points de terminaison et budgets d’erreur
Chaque point de terminaison stocke son responsable, son SLO et son budget. Le graphique de consommation utilise le budget défini par votre équipe, pas une valeur par défaut imposée par un éditeur.
Sondes
Des fonctions côté serveur s’exécutent selon un planning, par exemple toutes les minutes pour le flux de suivi et toutes les heures pour l’export de facturation. Chaque exécution écrit une ligne, ce qui rend l’historique interrogeable.
Clés et consommation des partenaires
Chaque appel est compté sur une clé partenaire. Un partenaire connecté voit sa propre consommation et ses propres incidents, tandis que les règles de visibilité par ligne excluent les autres partenaires.
Alertes et prises en charge
Les seuils sont reliés aux budgets. Les alertes sont publiées là où l’équipe travaille, et les prises en charge enregistrent l’ingénieur et l’heure.
Page de statut
La page de statut publique est générée à partir de la table des incidents, ce qui garde les mises à jour et l’historique des incidents liés entre eux.
Un exemple : l’API de suivi de fret de Julien
Voici comment une équipe pourrait utiliser une surveillance d’API construite avec Kliv. Ce n’est qu’un exemple — vous décririez vos propres points de terminaison, partenaires, budgets et règles d’alerte.
La sonde détecte des échecs répétés
Le point de terminaison des tarifs de Julien renvoie trois erreurs 500 consécutives. La sonde écrit trois lignes en échec, et le seuil d’alerte lit ces lignes.
La bonne équipe voit l’alerte
L’alerte arrive dans #platform avec le graphique en pièce jointe. Un ingénieur la prend en charge depuis le fil de discussion, et l’incident s’ouvre avec un responsable déjà assigné.
La page de statut se met à jour à partir de l’incident
La page publique passe en dégradé parce que la ligne de l’incident l’indique. Les partenaires peuvent lire la mise à jour avant d’envoyer un e-mail au support.
La reprise est mesurée avant la clôture
Une fois le correctif déployé, la sonde ne clôture l’incident qu’après dix minutes consécutives de contrôles au vert. La reprise est mesurée à partir des données, pas déclarée à la main.
Le post-mortem commence par une chronologie
L’équipe dispose déjà de chaque ligne de sonde, alerte, prise en charge et changement de statut dans l’ordre, si bien que personne ne reconstitue l’incident de mémoire.
Décrivez le tableau de bord d’API que vous voulez
Kliv construit à partir de votre description, incluez donc les noms des points de terminaison, les plannings, les budgets, les partenaires, les canaux d’alerte, et ce que les clients doivent voir. Plus vous donnez de détails, plus la première version sera proche de vos besoins.
Surveillance d’API partenaire
Sondes, budgets, consommation des partenaires et page de statut.
“Construis un tableau de bord de surveillance d’API pour notre API de suivi de fret. Sonde /tracking toutes les minutes et /billing-export toutes les heures, fixe un SLO hebdomadaire de 99,5 % sur /tracking, trace la latence et le taux d’erreur par clé partenaire, publie une page de statut publique à partir des enregistrements d’incidents, et poste des alertes Slack dans #platform quand 25 % du budget hebdomadaire est consommé.”
Tableau de bord des services internes
Un tableau de bord de santé des services par équipe responsable.
“Construis un tableau de bord de santé des services internes. Chaque équipe enregistre ses points de terminaison, responsables, SLO et canaux Slack. Les sondes s’exécutent toutes les cinq minutes par défaut, les contrôles en échec ouvrent des incidents, et les alertes vont vers le canal de l’équipe responsable avec suivi des prises en charge.”
Suivi de livraison des webhooks
Appels sortants, tentatives et historique visible par les clients.
“Construis un outil de suivi de livraison des webhooks pour notre marketplace. Enregistre chaque appel sortant, code de statut, corps de réponse, tentative et URL de destination. Trace les échecs par destination, et permets à chaque client de se connecter pour voir l’historique de livraison de ses propres points de terminaison uniquement.”
Construit comme les systèmes qu’il surveille
Les changements peuvent passer en revue. Le code source de l’outil se synchronise avec votre dépôt, si bien que les définitions de sondes et les seuils d’alerte peuvent être revus comme n’importe quel autre changement en production.
Les compteurs de consommation peuvent devenir des relevés. La consommation est comptée là où elle est tracée. Si vous facturez le dépassement — par exemple 0,45 € pour mille appels après le million inclus — des relevés mensuels peuvent provenir de ces mêmes compteurs via votre propre compte Stripe. Vous pouvez aussi produire des relevés sans facturation.
Les alertes peuvent rester dans Slack. La connexion Slack publie les alertes avec leur contexte et peut enregistrer les prises en charge dans l’incident. Le jeton reste dans le coffre-fort de la plateforme, pas dans le code.
Les outils de surveillance sont souvent construits correctement après un incident. Le schéma plus large des outils internes est rassemblé dans la liste des choses faites correctement après coup.
Questions fréquentes
Qu’est-ce que Kliv exactement ?
Kliv est un constructeur d’applications par IA. Vous décrivez le tableau de bord d’API dont vous avez besoin, et il construit une véritable application avec sondes, incidents, pages de statut, relevés de consommation et écrans d’administration.
Est-ce une vraie application, ou un modèle préfabriqué ?
Une vraie application. Vos points de terminaison, clés partenaires, plannings, budgets, incidents et règles de visibilité sont stockés dans une base de données conçue pour votre équipe.
Puis-je la modifier une fois construite ?
Oui. Vous pouvez demander de nouvelles sondes, budgets, graphiques, vues partenaires ou règles d’alerte en langage courant, et Kliv met à jour l’application.
Les partenaires peuvent-ils voir le trafic des autres ?
Non. Une connexion partenaire ne lit que les clés, les graphiques de consommation et les incidents de ce partenaire. Les lignes des autres partenaires ne sont pas renvoyées.
Où s’exécutent les sondes ?
En tant que fonctions côté serveur à l’intérieur de l’application, selon les plannings que vous définissez. Chaque exécution écrit une ligne, c’est pourquoi l’historique est interrogeable plutôt que d’être une collection de captures d’écran.
Peut-on facturer les partenaires pour leur consommation ?
Oui. Les compteurs de consommation peuvent inclure des tarifs, comme un million d’appels inclus puis 0,45 € pour mille appels, facturés via votre propre compte Stripe. Vous pouvez aussi utiliser les mêmes compteurs pour de simples relevés de consommation.
Que devient la page de statut pendant une panne de l’API ?
Elle reste indépendante de l’API qu’elle surveille. La page de statut est hébergée avec votre application Kliv, donc la panne de l’API surveillée ne fait pas tomber la page d’explication.
Les alertes peuvent-elles aller sur Slack ?
Oui. Les alertes peuvent être publiées sur Slack avec leur contexte, et les prises en charge peuvent revenir du fil de discussion vers l’enregistrement de l’incident.
Puis-je utiliser mon propre domaine ?
Oui. Les pages de statut publiques et les tableaux de bord privés peuvent fonctionner sur votre propre domaine.
Puis-je quitter Kliv plus tard ?
Oui. Le code de l’application se synchronise avec votre propre dépôt Git, donc partir se résume à un git pull plutôt qu’à une reconstruction.
Ai-je besoin d’un outil d’analyse séparé ?
Non. Les graphiques peuvent lire directement vos lignes de sondes, d’incidents et de consommation, avec les événements que vous définissez pour votre propre équipe.
More in this category
Réalisé par des créateurs
Découvrez ce qui est possible
Découvrez de vraies applications créées avec Kliv par des développeurs et des créateurs du monde entier
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Surveillez-le avant qu’il ne vous réveille
Décrivez les points de terminaison, les seuils, les partenaires et les alertes. Kliv construit le système de surveillance, la page de statut et les rapports de consommation autour d’eux.