#Surveillance

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.
Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité.
La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés.
Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc.
Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Salut les devs,

Aujourd’hui j’aimerais aborder un sujet qui m’a fait passer des moments difficiles (j’en suis convaincu, celà a déjà dû être le cas d’un bon nombre d’entre-vous) “le bottleneck”. C’est un sujet très vaste, cet article se concentrera sur l’identification des requêtes HTTP entrantes qui pourraient être à l’origine de problèmes de lenteur. Je vous mettrai aussi à disposition un petit outil que j’ai développé pouvant aider à leur identification.

Nos logiciels deviennent de plus en plus complexes, traitent un grand nombre de requêtes provenant de différentes sources, il peut s’agir d'applications front-end ou de tiers applications back-end. Pour garantir des performances optimales, il est essentiel de disposer d'un système de log capable de prendre quelques mesures clés telles que le temps de réponse, le nombre de global référence et le nombre de lignes de code exécutées pour chaque réponse HTTP. Dans le cadre de mon travail, je suis impliqué dans le développement d’un logiciel dossier patient informatisé ainsi que sur l’analyse des incidents. La charge utilisateur provient essentiellement de requêtes HTTP (API REST ou application CSP), la nécessité de disposer de ce type de mesure lorsque des problèmes de lenteur généralisée se produisent est devenu une évidence.

InterSystems a le plaisir d'annoncer la sortie de la version 2.0 de System Alerting & Monitoring (SAM).