Le serveur répond. Le service fonctionne-t-il vraiment ?

Source du concept: Monitoring Distributed Systems Google SRE. Le plan de surveillance et l'exemple ci-dessous sont une offre indépendante pour un petit environnement.

Le serveur peut répondre à ping, mais l'utilisateur ne peut pas ouvrir un rapport. Ce n'est pas une contradiction; nous avons mesuré deux choses différentes. À mon avis, le suivi devrait donner au moins une réponse claire à la question : -Le travail principal des utilisateurs est encore fait ?

Nous définissons la santé à la couche.

Personne à lui seul ne garantit la santé de l'ensemble du système. Même une réponse HTTP réussie peut être juste une bonne page d'erreur du programme; définir le contenu que vous attendez et le temps de réponse.

Commencez par un petit scénario.

Dans un exemple hypothétique, nous surveillons le système de déclaration. Nous choisissons un compte test avec un accès minimal, un petit rapport avec des données non sensibles et un résultat reconnaissable. Le test devrait être peu coûteux, ne pas divulguer d'information confidentielle dans le registre et ne pas créer de nouveau dossier opérationnel.

Si le programme est distinct, mesurez ses dépendances essentielles. Cependant, selon le processus, l'examen en direct de tous les services externes peut créer une relance inutile lorsqu'une dépendance échoue. La décision est prête à accepter la demande?

Les avertissements doivent avoir une destination et une action.

• Qu'a échoué l'utilisateur ?
• Quand et où sont-ils vus ?
• Qui est responsable de la réponse et quel est le premier examen proposé?

Ma suggestion est d'abord de faire un avertissement utile, puis d'augmenter le nombre de graphiques. Un tableau de bord que toutes les lumières sont vertes, mais l'utilisateur est insatisfait surveillera probablement la mauvaise question.

Étude connexe: Service documentaire..