F5 : construire un dossier de support et exploiter QKView

Un dossier utile décrit une application, une période et un comportement observé. « BIG-IP est lent » ne suffit pas : précisez le nom du service, les utilisateurs concernés, le début du symptôme, sa fréquence et la différence avec une période normale. Séparez les faits collectés des causes envisagées.

Conservez les changements récents, l’architecture, les versions, le rôle HA des membres et le parcours de la connexion. Une capture sans horodatage ou sans point de collecte peut être difficile à confronter aux journaux. Indiquez le fuseau horaire et les écarts de synchronisation connus.

QKView collecte des informations de diagnostic ; iHealth les analyse et présente des diagnostics. Cela aide à repérer des éléments de configuration ou d’état qui méritent une investigation. Un diagnostic n’est pas automatiquement la cause du symptôme : confrontez-le à la chronologie et à l’impact observé.

Ajoutez les lectures et extraits pertinents au dossier, plutôt qu’une masse de données sans contexte. La collecte et le transfert doivent respecter les consignes de votre version, la charge du système et les règles de traitement des données. Utilisez le canal de support autorisé ; les archives peuvent révéler des informations d’infrastructure.

Classez les résultats en observations directement liées au service, risques indépendants et informations à confirmer. Une alerte connue sur la plateforme peut être réelle sans expliquer une erreur HTTP apparue après un changement de pool. Conservez cette distinction dans vos échanges pour éviter de mélanger correction préventive et résolution de l’incident.

Si le problème semble matériel, identifiez d’abord le modèle et les procédures supportées. Un diagnostic EUD est spécifique aux plateformes et peut nécessiter un arrêt ou une fenêtre de maintenance. Ne le lancez pas comme une étape générique sur un système de production : faites confirmer le périmètre et la procédure par le support.

Une application renvoie des erreurs intermittentes depuis une modification. Préparez une page contenant un exemple horodaté, le virtual server, les membres du pool, les changements et les observations de chaque côté du proxy. Formulez deux hypothèses et une vérification capable de les départager.

Le dossier doit permettre à un autre administrateur de comprendre ce qui a été vu sans inventer un résultat de commande. Pour compléter la collecte, utilisez les guides captures ciblées, ressources et journaux et NTP.