Concepts clés
Sur cette page
Quelques idées suffisent à expliquer tout Onagre. Cette page présente chacune d'elles à l'aide d'un exemple tiré d'une boutique en ligne fictive, Corvane.
Sonde#
Une sonde décrit une chose à contrôler : ce qu'il faut contrôler (une URL, une requête en base de données, un port…), à quelle fréquence, et ce qui est considéré comme sain. À chaque exécution, elle produit un résultat : en ligne ou hors ligne, avec le temps de réponse et, pour certains types, une valeur mesurée.
La sonde
Storefront — Homepagede Corvane interrogehttps://www.corvane.example/chaque minute et attend un statut HTTP compris entre 200 et 399.
Dans l'application, les sondes se créent avec New monitor et sont listées sous Resources : « monitor » et « monitored resource » sont les noms que l'interface donne aux sondes. Chaque type de sonde est décrit dans Sondes.
Incident#
Un incident consigne un problème détecté par une sonde. Il s'ouvre au premier contrôle en échec et se résout automatiquement au premier contrôle réussi. Entre-temps, un membre de l'équipe peut le prendre en charge pour signaler qu'il s'en occupe.
À 07:53, le fournisseur SMS se met à répondre
degraded_performance: la sondeNotifications — SMS gatewayéchoue et un incident s'ouvre.
Voir Incidents.
Alerting et intégrations#
Une intégration est un canal de notification : un canal Slack, un canal Teams, un webhook, un téléphone via Pushover ou l'application mobile Onagre, l'e-mail d'un membre de l'équipe. L'alerting est la liste des intégrations liées à une sonde : lorsque cette sonde ouvre ou résout un incident, ces intégrations sont notifiées.
La sonde de la passerelle SMS alerte
Slack #ops-alertset le téléphone d'astreinte. Tous deux reçoivent un message à l'ouverture de l'incident, puis un autre lorsqu'il est résolu.
Voir Alerting et notifications.
Agent et Hub#
Un agent est le programme qui exécute réellement les contrôles. Onagre fournit un agent public sur internet : il contrôle les sites web et API publics sans rien à installer. Pour contrôler une ressource qui n'est pas joignable depuis internet — une base de données, une API interne — vous installez un agent privé dans votre réseau. Il se connecte vers Onagre et n'a jamais besoin d'un port entrant.
Le Hub est le service Onagre auquel les agents se connectent : il indique à chaque agent quoi contrôler et quand, et reçoit les résultats. Vous ne le configurez jamais ; il est mentionné lorsque vous ouvrez votre pare-feu pour un agent.
Voir Surveillance publique et privée.
Service#
Un service regroupe les sondes qui surveillent une partie de votre système — Checkout & Payments, Public API, Notifications — et affiche son état de santé global. Les services peuvent dépendre les uns des autres : Mobile Backend dépend de Notifications. La Service Map (carte des services) dessine ces dépendances et montre comment une panne se propage.
Voir Services.
Environnement#
Un environnement — Production, Staging, Development — sépare les sondes qui surveillent différentes copies de votre système. Chaque environnement possède ses propres variables (des valeurs en clair réutilisées dans les sondes, comme ${API_HOST}) et ses secrets (des chaînes de connexion chiffrées pour les bases de données et les brokers).
Voir Environnements.
Fenêtre de maintenance#
Une fenêtre de maintenance suspend les contrôles pendant des travaux planifiés, afin qu'une mise à jour de serveur n'ouvre pas d'incidents et ne réveille personne. Voir Fenêtres de maintenance.
Modèle#
Un modèle part d'un besoin — Website availability, Nightly backup, PostgreSQL availability — et prépare la sonde correspondante : vous complétez ce qui est propre à votre environnement et la créez en quelques clics. Voir Modèles.