Les App Connectors établissent la connexion vers les applications internes. Tant qu'ils fonctionnent, personne ne les remarque, et c'est justement ce qui rend leur panne désagréable : elle n'est pas remarquée, mais signalée, le plus souvent par des utilisateurs qui ignorent la cause. Connector Status Overview rend visible l'état des connecteurs avant que l'effet n'atteigne l'utilisateur. Le gain n'est pas seulement du temps, mais aussi l'ordre des événements : vous connaissez l'incident avant qu'on vous le signale.
Le composant invisible
Les App Connectors sont le lien entre l'environnement Zscaler et les applications internes qui doivent être accessibles par ce biais. Ils fonctionnent discrètement et, en régime normal, ne donnent aucune raison d'y penser.
Cette discrétion a un revers. Quand un connecteur tombe en panne, ce n'est pas le connecteur qui disparaît de la perception, mais l'application derrière lui. L'utilisateur signale qu'une application est inaccessible. Le fait qu'un connecteur en soit la cause n'apparaît qu'à la fin de la recherche d'erreur, pas au début.
Pourquoi l'ordre des événements compte
La différence entre « Nous sommes au courant et nous y travaillons » et « Merci pour le signalement, nous allons vérifier » est considérable pour l'utilisateur. Dans le premier cas, il perçoit une organisation qui garde la maîtrise de la situation. Dans le second, une organisation qui l'utilise lui-même comme capteur.
S'y ajoute le gain de temps. Une panne signalée commence par une description du point de vue de l'utilisateur, qu'il faut d'abord traduire. Une panne observée commence directement par le constat.
Ce que montre Connector Status Overview
Connector Status Overview rend visible en un seul endroit l'état des App Connectors. Vous voyez lesquels fonctionnent et lesquels non, sans que personne n'ait à le demander.
Pour le helpdesk, cela change le travail quotidien sur un point discret : face au signalement « L'application X ne fonctionne pas », un coup d'œil à l'état du connecteur prend quelques secondes et permet d'inclure ou d'exclure immédiatement l'une des causes les plus fréquentes.
La redondance n'est pas un substitut à la visibilité
De nombreux environnements exploitent des connecteurs en redondance, de sorte que la panne d'un seul ne provoque pas de perturbation immédiate. C'est juste et important, mais cela n'est pas un substitut à la visibilité.
Car une panne passée inaperçue dans une configuration redondante signifie que la redondance est consommée sans que personne ne le sache. La panne suivante touche alors un environnement sans réserve. La visibilité est précisément précieuse là où la première panne reste sans conséquence.
Dans une configuration redondante, la première panne de connecteur ne provoque aucune perturbation. Elle consomme seulement la réserve. Qui ne la voit pas l'apprend à la seconde panne.
L'alerte arrive sur le téléphone - avertissement, et aussi fin d'alerte
La visibilité dans le cockpit est utile tant que quelqu'un regarde. La nuit, le week-end ou en réunion, personne ne regarde. C'est pourquoi CentaurNexus n'attend pas que quelqu'un ouvre la vue d'ensemble, mais se manifeste de lui-même : via l'application de notification, sur l'appareil que vous avez de toute façon sur vous.
Le contrôle a lieu toutes les trois minutes. Si un connecteur tombe en panne, une notification part. S'il revient, une notification part également, et elle indique la durée de la panne. Cette seconde direction est la partie que les solutions de surveillance ont tendance à omettre : elles signalent le problème et restent silencieuses sur la fin d'alerte. Qui veut alors savoir si tout fonctionne de nouveau doit vérifier lui-même.
L'alerte se fait à deux niveaux : les App, Cloud et Service Edge Connectors individuels, ainsi que le groupe auquel ils appartiennent. Pour la vue d'ensemble dans l'application, c'est le groupe qui compte ; pour la recherche d'erreur, le connecteur individuel.
Trois choses sont délibérément conçues pour que les notifications restent utiles. Une brève interruption ne déclenche rien ; seule une perturbation qui dépasse un délai de grâce le fait. Au premier démarrage de la surveillance, aucune notification n'est générée simplement parce qu'un état est observé pour la première fois. Et si la connexion au tenant est totalement coupée, la notification individuelle par connecteur est supprimée, au lieu d'envoyer cent messages en même temps.
La différence au quotidien, c'est l'ordre des événements. Vous apprenez la perturbation avant que le premier utilisateur ne la remarque, et vous apprenez la fin d'alerte sans avoir à la demander.
Questions fréquentes
Qu'est-ce qu'un App Connector ?
Un App Connector établit la connexion entre l'environnement Zscaler et une application interne, afin qu'elle soit accessible via ZPA sans être exposée ouvertement sur le réseau.
Que montre Connector Status Overview ?
L'état des App Connectors en un seul endroit : lesquels fonctionnent et lesquels non. Une panne devient ainsi observable, au lieu de n'apparaître que par un signalement d'utilisateur.
Pourquoi la redondance ne suffit-elle pas ?
Parce qu'une panne passée inaperçue dans une configuration redondante consomme la réserve sans que personne ne le remarque. La panne suivante touche alors un environnement sans marge.
Qu'est-ce que cela apporte concrètement au helpdesk ?
Face à un signalement selon lequel une application serait inaccessible, l'une des causes les plus fréquentes peut être incluse ou exclue en quelques secondes, au lieu d'être découverte à la fin de la recherche d'erreur.
Cela remplace-t-il un système de supervision ?
Non. Cela rend l'état visible là où l'exploitation Zscaler a de toute façon lieu. Une supervision transversale garde toute sa place.
Est-ce la même chose que la surveillance des tunnels Zscaler, ou autre chose ?
Autre chose. Connector Status Overview surveille les App, Cloud et Service Edge Connectors, c'est-à-dire les briques d'infrastructure qui relient l'environnement Zscaler aux applications internes. Les problèmes de connexion ou de tunnel d'utilisateurs individuels relèvent d'un autre diagnostic, couvert ailleurs dans CentaurNexus.
Où puis-je télécharger ou installer un nouvel App Connector ? CentaurNexus s'en charge-t-il ?
Non. Le téléchargement et le déploiement du logiciel App Connector sont une tâche d'administration Zscaler à effectuer directement dans votre tenant Zscaler. CentaurNexus ne distribue aucun installateur de connecteur ; dès qu'un connecteur est déployé et enregistré, Connector Status Overview indique s'il fonctionne.
À quelle vitesse suis-je informé si un connecteur tombe en panne ?
Le contrôle a lieu toutes les trois minutes. Pour que les notifications restent utiles, seule une perturbation qui dépasse un court délai de grâce déclenche une alerte ; une brève interruption à elle seule ne déclenche pas encore d'alerte.
Vais-je être submergé de notifications si de nombreux connecteurs tombent en panne en même temps, par exemple parce que toute la connexion au tenant est coupée ?
Non. Si la connexion au tenant est totalement coupée, la notification individuelle par connecteur est supprimée, au lieu d'envoyer un message pour chaque connecteur en même temps.
Sources
Voir ce workflow en contexte
Choisissez le rôle correspondant dans le lanceur de démo. La démonstration utilise des données d'exemple préparées.
Ouvrir le lanceur de démo