Traitement des incidents liés aux applications SIP
Cette rubrique vous permet d'identifier et de résoudre les incidents liés aux applications SIP.
Pourquoi et quand exécuter cette tâche
Utilisez les éléments de base suivants pour l'identification des incidents liés aux conteneurs SIP lors de l'identification et la résolution des incidents liés aux applications SIP.
- L'utilisation système d'une unité centrale moyenne ne doit pas dépasser les 60-70 %.
- Le conteneur ne doit pas utiliser plus de 70 % de la taille de pile de la machine virtuelle allouée. Assurez-vous que le système dispose d'une mémoire physique suffisante pour prendre en charge la taille de pile de la machine virtuelle. Les charges d'appels et les expirations de session ont un grand impact sur l'utilisation du segment de mémoire.
- La récupération de place maximale de la machine virtuelle sur laquelle s'exécute le conteneur ne doit pas dépasser 500 ms et la moyenne doit être inférieure à 400 ms. La récupération de place en mode prolixe peut être utilisée pour mesurer cela et la vue de l'infrastructure PMI peut être utilisé pour visualiser les délais de récupération de place, l'utilisation du segment de mémoire, les sessions actives, etc., sous forme graphique.
Procédure
- Vérifiez les ports d'écoute de la configuration.
- Utilisez netstat –an pour afficher les ports d'écoute.
- Vérifiez que les hôtes virtuels sont définis
- Vérifiez si des alias d'hôte sont définis.
- Est-ce qu'une application est installée ? Est-elle lancée ?
- Pour une configuration de proxy : Est-ce qu'un cluster par défaut est configuré ? Si un proxy et un serveur se trouvent sur la machine, existe-t-il un conflit entre les ports ?
Résultats
- Symptôme : De nombreuses retransmissions, unités centrales reviennent à zéro périodiquement, ou une exception ThreadPoolQueueIsFullException apparaît dans les journaux.
Solution : Il s'agit d'un problème DNS typique causé par des recherches DNS inversées. Il peut être confirmé à l'aide d'un outil comme Ethereal. Le problème est peut-être le suivant : si vous effectuez une capture réseau et que vous envoyez de nombreuses requêtes DNS qui contiennent une adresse IP, vous recevez alors un nom d'hôte dans la réponse. Assurez-vous que nscd est en cours d'exécution si vous vous trouvez sur HP ou sur une autre plateforme qui nécessite une mise en cache du service de nommage. La plateforme Microsoft Windows ne requiert pas de mise en cache du service de nommage. Une autre solution consiste à ajouter des noms d'hôte au fichier /etc/hosts.
- Symptôme : De nombreuses retransmissions, unités centrales culminent à 100 % périodiquement.
Solution : Généralement, cela est dû à la récupération de place et peut être vérifié en activant la récupération de place en mode prolixe (accessible dans la console d'administration) et en examinant la longueur des cycles de récupération de place. Dans ce cas, la solution consiste à activer la récupération de place générationnelle en définissant les arguments facultatifs de la machine JVM sur -Xgcpolicy:gencon.
- Symptôme : De nombreuses retransmissions, unités centrales culminent à 100 % pendant de longues périodes et la récupération de place générationnelle est activée.Solution . Généralement, cela est dû aux objets de session SIP qui ne sont pas invalidés ou qui n'ont pas expiré pendant une longue période de temps. Pour y remédier, attribuez une valeur inférieure à la valeur d'expiration de la session dans le fichier sip.xml de l'application. Le moyen le plus efficace pour y parvenir consiste à faire en sorte que l'application appelle les objets invalidés de la session une fois le dialogue terminé (c'est-à-dire après la réception d'une requête BYE). L'entrée suivante du fichier SystemOut.log indique si la valeur d'expiration de la session vaut pour chaque application installée dans le conteneur :
SipXMLParser 3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For App: TCK back-to-back user agent”
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications. - Symptôme : De nombreux messages "480 Service indisponible (Service Not Available)" ont été reçus de la part du conteneur lors de l'envoi de nouveaux messages INVITE au conteneur SIP.
Il se peut également que le message suivant s'affiche dans le fichier SystemOut.log lorsque le serveur est dans l'état suivant : "LoadManager E LoadManager warn.server.oveloaded".
Solution :Généralement, cela est dû au fait que l'une des unités de mesure configurables du conteneur SIP a été dépassée. Ceci inclut les valeurs "Nombre maximal de sessions d'application" et "Nombre maximal de messages par période moyenne". La solution consiste à ajuster ces valeurs à la hausse.
- Symptôme : De nombreux renvois et appels ne sont pas complétés avec des exceptions OutOfMemory dans le fichier SystemErr.log.
Solution : Habituellement, cela signifie que la taille de pile de la machine virtuelle associée à votre conteneur n'est pas assez grande et doit être ajustée à la hausse. Vous pouvez ajuster cette valeur depuis la console d'administration.
- Symptôme : Vous recevez un message "503 Service indisponible (Service Unavailable)" lors de l'envoi d'une requête SIP à un proxy SIP.
Solution : Habituellement, cela signifie qu'il n'existe aucun cluster par défaut (ou règle de routage du cluster qui correspond au message) configuré au niveau du proxy. Ce message s'affiche également lorsque le proxy SIP est bien configuré, mais que les conteneurs SIP d'arrière-plan se sont arrêtés, de manière normale ou non.
- Symptôme : Vous recevez un message "404 Introuvable (Not Found)" lors de l'envoi d'une requête SIP à un proxy SIP.
Solution : Habituellement, cela signifie qu'il n'existe aucun hôte virtuel configuré pour les conteneurs qui se trouvent dans le cluster par défaut. Cela pourrait également signifier que les serveurs se trouvant dans le cluster par défaut du proxy ne contiennent pas d'application SIP ou que le message ne correspond pas à l'une des applications installées dans le cluster par défaut.
- Symptôme : Un comportement de type "mémoire insuffisante" se produit.
Solution : Cela peut être dû au fait que la taille de pile maximale est trop faible. Les applications SIP peuvent consommer une quantité de mémoire importante car les sessions existent pendant une longue période d'attente des appels. La taille de pile maximale de 512 Mo ne fournit pas une mémoire suffisante pour la charge de travail du trafic SIP. Attribuez la valeur minimale recommandée de 768 Mo ou plus à la taille de pile maximale pour les applications SIP.
- Symptôme : Le message "403 Forbidden (Interdit)" s'affiche lors de l'envoi d'une demande SIP à un conteneur SIP.
Solution : En règle générale, cela signifie que le système n'a trouvé aucune application SIP appropriée pour traiter la demande SIP reçue (aucune règle de correspondance ne concordait avec le message).