Performance et état de santé

snap-in MMC Performance. La différence entre la supervision des journaux d’événements et la supervision des objets de performances est la suivante : on consulte les journaux d’événements pour obtenir des informations sur une partie du système présentant un problème et on a recours aux objets de performances pour vérifier que certains paramètres restent dans des limites acceptables. Ainsi, vous utiliserez les objets de performances pour superviser l’espace disque parce que le journal système ne vous alertera que quand vous serez très près de la capacité maximale, donc déjà en situation délicate.

Une autre vérification des objets de performances Windows courante consiste à superviser l’utilisation de la CPU pour certains niveaux ou pendant certaines durées (par exemple, plus de 90 % pendant 10 minutes). Toutefois, les vérifications de l’utilisation de la CPU doivent être menées avec circonspection. En effet, il est facile de confondre l’utilisation légitime avec un processus débridé et, ce faisant, de générer une alerte positive fausse. Le danger des objets de performances est que d’autres applications peuvent créer les leurs et publier des données de télémesure propres à l’application. Ainsi, Active Directory (AD), SQL Server et Exchange Server ont leurs propres objets de performances.

L’absence d’événements d’erreurs dans un journal et des valeurs de performances situées dans des seuils acceptables sont des signes que tout se passe bien. Il peut néanmoins y avoir des problèmes que les indicateurs n’ont pas révélés. Les vérifications de l’état de santé du serveur sont le meilleur moyen de s’assurer périodiquement que les serveurs et les applications sont en ligne et qu’ils traitent correctement les requêtes. Les vérifications de l’état de santé du serveur sont fiables parce qu’elles effectuent une transaction test. Beaucoup de fournisseurs d’applications et de fournisseurs de services sur Internet vous permettent d’effectuer des transactions de test régulières sur le serveur, avec la périodicité de votre choix. Pour un serveur Web, vous pourriez demander périodiquement une certaine page Web et contrôler que la page est renvoyée correctement. Ou, pour une machine SQL Server, vous pourriez exécuter périodiquement une requête et en vérifier les résultats.

Cela dit, même des vérifications de l’état de santé peuvent ne pas tout remarquer. Ainsi, un simple ping toutes les 5 minutes peut indiquer que l’OS et la pile réseau sont opérationnels, mais cela ne garantit pas que l’application réelle se porte bien. Il arrive que des serveurs plantés répondent à des pings. Dans le même esprit, le simple fait de demander une page HTML à un serveur ne prouve pas forcément que l’application ASP (Active Server Pages) de e-commerce associée est en bon état de fonctionnement. C’est pourquoi vous devez essayer de faciliter les vérifications de l’état de santé. Si votre application ou service de vérification le permet, vous pourriez créer un compte de test sur une application e-commerce et l’utiliser pour tester ce qui se passe quand on ajoute un article au panier.

Autre précaution : Tenez l’application de vérification de l’état de santé séparée de l’environnement de production que vous supervisez. En effet, si vous hébergez une application de vérification de l’état de santé et si, par inadvertance, vous exécutez cette application sur le même serveur que vous êtes en train de superviser, vous ne saurez pas – par exemple – qui du serveur ou de la connexion Internet est en panne, parce que l’application ne pourra pas envoyer le message. En revanche, si vous exécutez l’application de vérification de l’état de santé à partir d’un serveur séparé – et, dans la mesure où le serveur est accessible par Internet à partir d’un réseau différent – l’application critique ne pourrait être indisponible à votre insu que si les deux environnements de production et de supervision étaient en panne simultanément.