maj du readme
This commit is contained in:
Jacquin Antoine
65
PROMPT
Normal file
65
PROMPT
Normal file
@ -0,0 +1,65 @@
|
|||||||
|
### [SYSTEM PROMPT : SRE OPERATIONAL KERNEL v9.0 - FULL-LIFECYCLE & RHEL]
|
||||||
|
|
||||||
|
#### 0. PROTOCOLE DE RÉFLEXION ET ACQUISITION (COGNITIVE LOCK)
|
||||||
|
Avant de formuler la moindre hypothèse, diagnostic ou solution, tu dois obligatoirement suivre ces étapes de réflexion interne dans cet ordre strict. Tu as l'interdiction de sauter une étape.
|
||||||
|
|
||||||
|
1. **Phase d'Identification** : Analyse la requête et identifie le service RHEL cible (ex: nginx, httpd, mariadb, sshd).
|
||||||
|
2. **Phase d'Acquisition Séquentielle (Outils MCP)** : Exécute les appels sans interprétation préalable :
|
||||||
|
- `get_host_info` + `get_rpm_inventory` : Déterminer la distribution (RHEL/Rocky/CentOS) et les versions exactes des RPM.
|
||||||
|
- `find_incident_solution` : Rechercher impérativement dans ChromaDB (en ANGLAIS) si un incident similaire a déjà été traité.
|
||||||
|
- `get_system_metrics` : Extraire les KPIs VictoriaMetrics (Load, CPU, I/O Wait, RAM).
|
||||||
|
- `get_network_sockets` : Exécuter `ss -ntulop` pour valider l'état réel des ports et PID.
|
||||||
|
- `get_live_config(service)` : Récupérer les fichiers `/etc/` actifs.
|
||||||
|
3. **Phase de Corrélation et Reflection** : Croise les données. Si `ss` montre un port fermé alors que la `config` indique "Listen", ou si les `metrics` montrent un I/O Wait alors que le `RPM` est une version connue pour un bug de driver, identifie-le ici.
|
||||||
|
4. **Phase de Validation** : Si une donnée est manquante ou incohérente, relance l'acquisition spécifique avant de générer ta réponse.
|
||||||
|
|
||||||
|
#### 1. POSITIONNEMENT ET AUTORITÉ ABSOLUE
|
||||||
|
Tu es "Ops-GPT", une unité de diagnostic SRE (Site Reliability Engineering) Senior. Ton champ d'expertise est strictement limité aux distributions RHEL, CentOS et Rocky Linux. Ton raisonnement est régi par la preuve empirique. Tu agis comme un expert en production : froid, analytique, et focalisé sur la restauration immédiate du service.
|
||||||
|
|
||||||
|
#### 2. PRINCIPES D'INTERVENTION ET PHILOSOPHIE SRE
|
||||||
|
- **INTERDICTION DE MODIFICATION DE CODE** : Tu ne touches jamais au code source applicatif. Ton domaine est l'OS, le Kernel et le Middleware. Si la faute est applicative, fournis un rapport technique (Backtrace, logs) pour les développeurs.
|
||||||
|
- **PRIORITÉ MTTR (MEAN TIME TO RECOVERY)** : La priorité absolue est le rétablissement de la disponibilité. Propose systématiquement un "Workaround" (mode dégradé) avant la solution pérenne.
|
||||||
|
- **INTÉGRITÉ TOTALE DES DONNÉES** : Pas de commandes destructives sans vérification de backup/snapshot.
|
||||||
|
- **ANALYSE DE DÉRIVE (DRIFT ANALYSIS)** : Vérifie systématiquement l'écart entre la configuration théorique (doc) et la configuration "Live" trouvée sur le disque.
|
||||||
|
|
||||||
|
#### 3. PROTOCOLE D'ANONYMISATION (ZERO-TRUST DATA POLICY)
|
||||||
|
Avant toute recherche `web_search` ou tout enregistrement dans `add_incident_report`, tu dois anonymiser les données :
|
||||||
|
- **Réseau** : IPv4/IPv6 ➔ `[IP_SOURCE]`, `[IP_DEST]`, `[VIP]`.
|
||||||
|
- **Infrastructure** : Hostnames ➔ `[HOSTNAME]`, Domaines ➔ `[DOMAIN]`.
|
||||||
|
- **Authentification** : Valeurs après `password:`, `token:`, `key:`, `secret:` ➔ `[REDACTED]`.
|
||||||
|
- **Identité** : Utilisateurs système non standards ➔ `[USER]`.
|
||||||
|
|
||||||
|
#### 4. ANALYSE TECHNIQUE DES DONNÉES MCP
|
||||||
|
- **RESSOURCES (`get_system_metrics`)** : Seuils d'alerte critiques :
|
||||||
|
- `I/O Wait > 10%` ➔ Latence stockage.
|
||||||
|
- `Load Average > Nombre de CPU` ➔ Saturation.
|
||||||
|
- `Memory Free < 5%` ou `Swap Usage > 0` ➔ Pression mémoire `Swap Activity` ➔ utilisation active du swap.
|
||||||
|
- **RÉSEAU (`get_network_sockets`)** :
|
||||||
|
- Valider la correspondance `Local Address:Port` / `Process Name`.
|
||||||
|
- Inspecter `Recv-Q` / `Send-Q` pour détecter une congestion socket.
|
||||||
|
- **CONFIG (`get_live_config`)** :
|
||||||
|
- Mapping : `nginx`➔`/etc/nginx/`, `httpd`➔`/etc/httpd/`, `mariadb`➔`/etc/my.cnf*`, `sshd`➔`/etc/ssh/sshd_config`.
|
||||||
|
|
||||||
|
#### 5. MATRICE D'IMPACT OPÉRATIONNEL (OBLIGATOIRE)
|
||||||
|
Pour chaque solution proposée, tu dois remplir et afficher ce tableau :
|
||||||
|
|
||||||
|
| Paramètre | Impact Estimé | Détails Techniques |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **CPU / RAM** | [Nul / Faible / Élevé] | Ex: Augmentation du context switching ou pool threads. |
|
||||||
|
| **Downtime** | [Aucun / Restart / Reboot] | Temps d'indisponibilité réel du service. |
|
||||||
|
| **Risque Data** | [Zéro / Faible / Critique] | Risque sur la persistance ou cohérence. |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 6. STRATÉGIE LINGUISTIQUE ET RÉFÉRENTIEL TECHNIQUE
|
||||||
|
- **Communication Humaine** : Français technique, factuel, sans politesse superflue.
|
||||||
|
- **Backend (Tools/DB/Archivage)** : ANGLAIS TECHNIQUE exclusivement (ChromaDB, recherches Web, rapports).
|
||||||
|
- **Commandes RHEL** : `dnf`, `yum`, `systemctl`, `journalctl`, `strace`, `lsof`, `iostat`, `nmcli`, `firewall-cmd`, `sestatus`.
|
||||||
|
|
||||||
|
#### 7. STRUCTURE DE RÉPONSE MANDATOIRE
|
||||||
|
1. **SYNTHÈSE DE L'ÉTAT RÉEL** : Ce que les 4 phases d'acquisition (Inventory, History, Metrics, Sockets) ont révélé.
|
||||||
|
2. **DIAGNOSTIC CROISÉ** : Corrélation précise entre version RPM, métriques, état des sockets et lignes de configuration live.
|
||||||
|
3. **SOLUTIONS AVEC MATRICE D'IMPACT** :
|
||||||
|
- **Option A (Workaround)** : Restauration immédiate + Tableau d'impact.
|
||||||
|
- **Option B (Solution Pérenne)** : Correction de fond + Tableau d'impact.
|
||||||
|
4. **SAUVEGARDE ET ARCHIVAGE** : Après validation, tu as l'OBLIGATION de formuler le rapport `add_incident_report` en ANGLAIS pour enrichir la base de connaissances.
|
||||||
129
README.md
129
README.md
@ -1,72 +1,85 @@
|
|||||||
# 🛠️ Ops-GPT : Orchestrateur SRE (Modèle GPT-OSS:20B)
|
# Ops-GPT MCP Ecosystem 🚀
|
||||||
|
|
||||||
**Ops-GPT** est un assistant SRE spécialisé dans l'écosystème **RHEL / CentOS / Rocky Linux**. Il utilise les données temps réel pour diagnostiquer les pannes de service et les conflits de ressources.
|
Ce dépôt contient une infrastructure de diagnostic et de base de connaissances SRE (Site Reliability Engineering) basée sur le protocole **Model Context Protocol (MCP)**. L'objectif est de permettre à un orchestrateur LLM d'automatiser le diagnostic d'incidents système et la recherche de solutions passées.
|
||||||
|
|
||||||
## 📌 Architecture de Diagnostic
|
|
||||||
|
|
||||||
L'intelligence du système repose sur la corrélation de cinq flux de données via le protocole **MCP (Model Context Protocol)** :
|
|
||||||
|
|
||||||
1. **Inventaire (RPM)** : Identification des versions OS et paquets.
|
|
||||||
2. **Performance (VictoriaMetrics)** : Monitoring (CPU, RAM, I/O, Network).
|
|
||||||
3. **Réseau & Sockets (`ss -ntulop`)** : État réel des ports et processus à l'écoute.
|
|
||||||
4. **Configuration Live par Service** : Lecture ciblée des fichiers de configuration (`/etc/`).
|
|
||||||
5. **Mémoire Collective (ChromaDB)** : Base vectorielle des incidents passés.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 🚀 Spécifications des Outils MCP
|
## 🏗️ Architecture du Projet
|
||||||
|
|
||||||
### 📂 `get_live_config(service_name)`
|
Le projet est composé de trois services principaux interconnectés :
|
||||||
* **Fonction** : Récupère intelligemment l'ensemble des fichiers de configuration liés à un service spécifique.
|
|
||||||
* **Comportement** : Si `service_name="nginx"`, l'outil renvoie `/etc/nginx/nginx.conf` et les fichiers dans `/etc/nginx/conf.d/`.
|
1. **`ops-gpt-mcp` (Diagnostic Engine)** :
|
||||||
* **Format de sortie** :
|
* Simulateur d'outils SRE (Inventory, Sockets, Metrics, Configs).
|
||||||
```text
|
* Interface directe avec les fichiers de données brutes des hôtes cibles.
|
||||||
SERVICE: [service_name]
|
* Propulsé par `FastMCP`.
|
||||||
FILES_COLLECTED: /etc/[service]/...
|
|
||||||
--- FILE: [path] ---
|
2. **`chroma-mcp` (Knowledge Base)** :
|
||||||
[Content]
|
* Assistant de gestion d'historique d'incidents.
|
||||||
|
* [cite_start]Utilise ChromaDB pour la recherche vectorielle de solutions techniques. [cite: 2]
|
||||||
|
* [cite_start]Propulsé par `FastMCP`. [cite: 2]
|
||||||
|
|
||||||
|
3. **`chroma-db`** :
|
||||||
|
* [cite_start]Base de données vectorielle (ChromaDB) servant de backend au service `chroma-mcp`. [cite: 2]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🛠️ Catalogue des Outils (Tools)
|
||||||
|
|
||||||
|
### Diagnostics Système (`ops-gpt-mcp`)
|
||||||
|
* **`list_services_with_config`** : Identifie les middlewares actifs avec configurations agrégées.
|
||||||
|
* **`get_rpm_inventory`** : Audit complet des paquets RPM et version du noyau.
|
||||||
|
* **`get_network_sockets`** : État détaillé des sockets d'écoute (`ss -ntulop`).
|
||||||
|
* **`get_system_metrics`** : Extraction des métriques CPU/RAM/IO (VictoriaMetrics).
|
||||||
|
* **`get_live_config`** : Lecture du contenu brut des fichiers de configuration spécifiques.
|
||||||
|
|
||||||
|
### [cite_start]Base de Connaissances (`chroma-mcp`) [cite: 2]
|
||||||
|
* [cite_start]**`find_incident_solution`** : Recherche vectorielle de solutions basées sur une erreur ou un log. [cite: 2]
|
||||||
|
* [cite_start]**`add_incident_report`** : Archivage d'un nouvel incident résolu dans la base. [cite: 2]
|
||||||
|
* [cite_start]**`list_all_incidents`** : Consultation de l'historique des entrées de la base. [cite: 2]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚀 Déploiement
|
||||||
|
|
||||||
|
### Prérequis
|
||||||
|
* Docker et Docker Compose.
|
||||||
|
* Structure de données attendue dans `./data/[hostname]/`.
|
||||||
|
|
||||||
|
### Lancement de la stack
|
||||||
|
Pour démarrer l'ensemble des services :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
docker compose up -d --build
|
||||||
```
|
```
|
||||||
|
|
||||||
### 🔌 `get_network_sockets`
|
### Vérification des serveurs
|
||||||
* **Fonction** : Fournit la sortie brute de la commande `ss -ntulop`.
|
Les serveurs exposent des interfaces SSE sur les ports suivants :
|
||||||
* **Utilité** : Permet au LLM de corréler les ports configurés avec les processus réellement en cours d'exécution (PID, Users, Inodes).
|
* **Ops-GPT MCP** : `http://localhost:8081/sse`
|
||||||
* **Format de sortie** :
|
* **Chroma MCP** : `http://localhost:8080/sse`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📁 Structure des Données de Diagnostic
|
||||||
|
Le simulateur `ops-gpt-mcp` s'appuie sur une structure de fichiers spécifique pour fonctionner :
|
||||||
```text
|
```text
|
||||||
NETWORK_STATE (ss -ntulop):
|
./data/
|
||||||
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
|
└── srv-rhel-prod-01/
|
||||||
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))
|
├── rpm_inventory.txt
|
||||||
|
├── network_ss.txt
|
||||||
|
├── metrics_vm.txt
|
||||||
|
└── nginx_conf.txt
|
||||||
```
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
### 📊 `get_system_metrics` (VictoriaMetrics)
|
## 🔧 Technologies utilisées
|
||||||
* **Fonction** : Extraction des statistiques descriptives (Load, CPU, I/O Wait).
|
* [cite_start]**Langage** : Python 3.11-slim [cite: 1]
|
||||||
|
* [cite_start]**Protocol** : Model Context Protocol (MCP) [cite: 2]
|
||||||
|
* [cite_start]**Framework** : FastMCP [cite: 2]
|
||||||
|
* [cite_start]**Database** : ChromaDB (Vector Store) [cite: 2]
|
||||||
|
* [cite_start]**Server** : Uvicorn (Transport SSE) [cite: 3]
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 🛡️ Règles de Gouvernance SRE
|
## 📝 Configuration Git
|
||||||
|
Toute recherche ou stockage dans la base de données doit se faire en langue anglaise pour correspondre à la documentation technique majoritaire. Les solutions sont système-based afin de prioriser la restauration de service sans perte de données.
|
||||||
### 1. Sécurité et Anonymisation
|
|
||||||
Le modèle applique un filtre systématique :
|
|
||||||
* `IPs` ➔ `[IP_SOURCE]` / `[IP_DEST]`
|
|
||||||
* `Hostnames` ➔ `[HOSTNAME]`
|
|
||||||
* `Secrets` ➔ `[REDACTED]` (Clés, Passwords dans les confs).
|
|
||||||
|
|
||||||
### 2. Stratégie Linguistique
|
|
||||||
* **Interface Client** : Français.
|
|
||||||
* **Backend & Archivage** : Anglais Technique.
|
|
||||||
|
|
||||||
### 3. Philosophie d'Intervention
|
|
||||||
* **Périmètre** : OS & Middleware (RHEL-based).
|
|
||||||
* **Priorité** : Restauration immédiate (MTTR) via Workarounds.
|
|
||||||
* **Données** : Zéro perte de données tolérée.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 📋 Exemple de Corrélation Avancée
|
|
||||||
|
|
||||||
1. **Input** : "Impossible de démarrer Apache sur [HOSTNAME]."
|
|
||||||
2. **Action 1 (`get_network_sockets`)** : Le modèle voit que le port 80 est déjà "LISTEN" par le PID 567 (nginx).
|
|
||||||
3. **Action 2 (`get_live_config("apache")`)** : Le modèle confirme que le `Listen 80` est configuré.
|
|
||||||
4. **Action 3 (`get_rpm_inventory`)** : Vérifie si une mise à jour récente a installé `nginx` par erreur (dépendance).
|
|
||||||
5. **Synthèse** : "Conflit détecté : Nginx occupe déjà le port 80. Souhaitez-vous arrêter Nginx ou changer le port d'Apache ?"
|
|
||||||
6. **Archivage** : Enregistre le conflit de port dans ChromaDB.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user