Administration & configuration

Toute la configuration d'otwatch est gérée sous forme de code dans un système de gestion de versions et déployée via un pipeline. Les modifications sont revues, testées en QA puis déployées en production ; chaque modification est traçable avec son auteur, sa date et son contenu.

Flux d'une alerte, du contrôle à la résolution.

Contrôles et seuils

Chaque contrôle possède un ID de contrôle stable. Cet ID relie la règle d'alerte, l'alerte, le panneau du tableau de bord et le runbook, qui décrit la signification, les causes probables et les premières mesures. Le catalogue des contrôles et les runbooks sont mis à la disposition des clients dans le portail HID otwatch.

Les seuils sont définis par contrôle et peuvent varier selon l'environnement (p. ex. plus stricts en PROD qu'en TEST) et selon le client.
Une anomalie doit persister pendant une durée définie (généralement 1 à 2 minutes) avant qu'une alerte ne soit déclenchée, afin d'éviter les fausses alertes.
Les contrôles peuvent être échelonnés, p. ex. Avertissement à 80 % et Critique à 95 % d'occupation du disque.

Sévérité et priorités

Sévérité	Priorité	Signification	Notification
Critique	P1 / P2	Production dégradée ou en danger immédiat	Immédiate, astreinte (push, SMS, appel téléphonique), répétée jusqu'à la prise en charge
Avertissement	P3 / P4	Fonction dégradée, solution de contournement disponible, ou seuil bientôt atteint	Ticket et e-mail pendant les heures de service
Information	P5 / P6	Événement notable sans impact direct	Tableaux de bord et rapports

Routage des alertes et canaux

Alertmanager achemine les alertes selon la sévérité, l'environnement, le composant, l'équipe et l'heure. Canaux pris en charge :

Jira Service Management (tickets, plannings d'astreinte, escalade, prise en charge)
E-mail et Microsoft Teams
Webhooks / REST vers des plateformes ITSM et de gestion d'événements (p. ex. ServiceNow, Jira, Splunk)

Les alertes liées sont regroupées et dédoublonnées ; des règles de dépendance suppriment les alertes consécutives (p. ex. les alertes Content Server lorsque la base de données est indisponible), de sorte que la cause première est notifiée en premier. Une alerte watchdog signale une défaillance du monitoring lui-même.

Fenêtres de maintenance

Ponctuelle : une mise en silence avec heure de début et de fin, créée à l'avance ou à la volée.
Récurrente : intervalles de temps par jour de la semaine, heure et jour du mois (p. ex. chaque lundi de 06:00 à 08:00).
Périmètre : un environnement entier, un serveur, un composant ou des contrôles individuels.

Pendant une fenêtre de maintenance, les notifications sont supprimées, mais les métriques continuent d'être enregistrées. Les alertes encore actives après la fenêtre sont notifiées normalement. Chaque fenêtre est enregistrée avec son auteur, son motif et sa durée.

Utilisateurs et rôles

Rôle	Droits
Viewer	Consulter les tableaux de bord, les alertes et les rapports
Editor	Créer et modifier des tableaux de bord, explorer les métriques et les logs, gérer les fenêtres de maintenance
Admin	Utilisateurs, équipes, sources de données et configuration

Les utilisateurs se connectent par authentification unique (Microsoft Entra ID, OTDS ou Active Directory) ; les rôles sont attribués à partir des groupes de l'annuaire. L'authentification multifacteur est imposée par le fournisseur d'identité.

Tableaux de bord et rapports

Tableaux de bord prêts à l'emploi pour chaque composant OpenText, personnalisables par client et par rôle.
Analyse détaillée depuis la vue d'ensemble des services jusqu'aux composants, nœuds, processus, alertes et logs.
Rapports périodiques (disponibilité, performances, capacité, SLA) au format PDF, Excel ou CSV, diffusés par e-mail.

Conservation des données

Les métriques et les logs sont conservés pendant au moins 12 mois ; la durée de conservation est configurable par déploiement et par source de logs.

Pour aller plus loin

handel gmbh · Documentation otwatch · Dernière mise à jour : 19 octobre 2026