Aller au contenu

🛠️ Alert Guard System

📚 Introduction

Ce document vous guide à travers la mise en place, l'intégration et la personnalisation de GLPI, afin d'optimiser la gestion des tickets d'incidents et l'intégration avec d'autres systèmes.

🏛️ Architecture de l'Application

Architecture Diagram

Composants Clés

GLPI

GLPI est le système central pour la gestion des tickets d'incidents. Il collecte des données de différentes sources et génère des tickets basés sur les incidents détectés.

Grafana

Grafana est utilisé pour le monitoring des ressources et des performances. Il effectue des vérifications systématiques (ping) des composants surveillés et envoie des alertes à l'Alert Manager en cas de détection d'incidents.

OCS Inventory

OCS Inventory gère l'inventaire des composants IT. Il crée et surveille les éléments qui doivent être monitorés, interagissant avec Grafana pour assurer une surveillance précise et actualisée.

Alert Manager

L'Alert Manager reçoit les alertes de Grafana et communique avec une application Flask via un webhook. Cette application Flask est ensuite responsable de la création de tickets dans GLPI.

Redmine

Redmine est utilisé pour la gestion des incidents de développement. Il reçoit des informations de GLPI via un connecteur, fournissant aux équipes de développement des données détaillées pour le dépannage.

Flux de Données

  1. Grafana surveille les systèmes et envoie des alertes à Alert Manager en cas de problème.
  2. Alert Manager utilise un webhook pour communiquer avec l'API Flask, qui crée des tickets dans GLPI.
  3. GLPI gère ces tickets et, via un connecteur, peut également en créer dans Redmine pour des incidents spécifiques au développement.
  4. OCS Inventory surveille les statuts des composants IT et interagit avec Grafana pour la mise à jour des données de surveillance.

Cette configuration assure une gestion efficace des incidents et une réponse rapide aux problèmes, tout en facilitant la collaboration entre les équipes de support technique et de développement.

💡 Fonctionnalités Principales

  • 🔧 Configuration et Initialisation
  • Gestion des variables d'environnement

  • 🎫 Création de Ticket dans GLPI

  • Génération automatique via webhook

  • 👥 Assignation de Groupe et Demandeur

  • Attribution automatique aux groupes de support

  • 💻 Assignation d'un composant matériel

  • Attribution automatique un composant matériel (ordinateur dans ce cas)

  • 📧 Envoi d'Email d'Alerte

  • Notifications avec liens vers les tickets

  • 🔄 Création de Ticket dans Redmine

  • Pour une traçabilité complète

  • 📝 Gestion des Erreurs et Logging

  • Facilite le dépannage

  • 🌐 Point de Terminaison Webhook

  • Réception des alertes JSON

💡 Intéraction avec les fonctionalités de base

schema_d'integration

Workflow de Gestion des Incidents

Le diagramme ci-dessus détaille le processus automatisé de création de tickets d'incident en réponse aux alertes de performance ou de sécurité détectées par le système de monitoring. Les interactions entre Alertmanager, GLPI et Redmine sont décrites ci-dessous :

Composants Principaux

Alertmanager

  • Envoi d'alerte : Alertmanager reçoit des alertes des systèmes de monitoring et les envoie vers GLPI via un webhook configuré.

GLPI

  • Alert Webhook : Un webhook configuré dans GLPI reçoit les alertes et initie le processus de création de ticket.
  • INIT SESSION GLPI : Une session GLPI est initialisée pour authentifier et permettre la création de tickets.
  • Filtrage des infos : Les informations pertinentes de l'alerte sont extraites et filtrées pour préparer la création du ticket.
  • Création de Ticket GLPI : Un ticket est créé dans GLPI avec les informations filtrées.
  • Assignation de Groupe et Demandeur : Le ticket est assigné à un groupe et à un demandeur spécifique selon la configuration.
  • Assignation d'un composant matériel : Si l'alerte est liée à un composant matériel spécifique, ce dernier est associé au ticket.
  • Gestion des Erreurs et Logging : Les erreurs éventuelles lors de la création du ticket sont gérées et enregistrées.
  • Envoi d'Email d'Alerte : Un email d'alerte est envoyé pour notifier les parties concernées de la création du ticket.

Redmine

  • Création de Ticket Redmine : Un processus indépendant ou lié peut créer un ticket dans Redmine pour la gestion des incidents de développement.
  • Obtention de Bugtracker ID : L'ID pour le tracker de bugs spécifique est obtenu.
  • Assignation au Tracker Bug : Le ticket est assigné au tracker de bugs dans Redmine.

Interactions

  • Les alertes générées par le système de monitoring sont traitées à travers Alertmanager qui communique avec GLPI pour la gestion des incidents.
  • GLPI gère la création, l'assignation, et la notification des tickets, tandis que Redmine est utilisé pour des aspects plus spécifiques du développement liés aux incidents.

Points Clés

  • Automatisation : Le processus est hautement automatisé pour garantir une réaction rapide aux incidents.
  • Intégration : Une intégration étroite entre les outils de monitoring, GLPI et Redmine permet une gestion complète des incidents à travers différentes équipes et départements.

Ce workflow permet une gestion efficace et rapide des incidents, réduisant le temps de résolution et augmentant la réactivité des équipes de support et de développement.