Instantané des paramètres serveur

Vue d’ensemble — à quoi cela sert

Le bouton [param] de la carte d’une instance prend un instantané des paramètres serveur (les réglages) de chaque instance dans infr_instance_param. C’est différent des variables d’instance (un dictionnaire de secrets pour les assemblages Tools) : ici sont conservées des valeurs de configuration telles que nginx.conf, my.cnf, sysctl, php.ini, haproxy.cfg, sous forme d’instantané de référence qui fonde le diagnostic d’optimisation par l’IA. Ce ne sont pas des secrets ; les valeurs sensibles sont marquées (redacted) par la sonde.

Disposition

Cinq panneaux de domaine (--grid--5, responsive 5→3→1 colonnes).

Coexistence de plusieurs moteurs — engine fait partie de l’identité unique (UNIQUE(instance_id, category, engine, name)). Même si un hôte fait tourner nginx+apache ou mysql+postgres, un paramètre de même nom (par exemple max_connections) est stocké par moteur et n’est jamais mélangé. L’interface les sous-groupe par moteur à l’intérieur de chaque panneau de domaine.

Utilisation

Deux voies de mise à jour :

1. Ajout/modification manuels — le [+] dans l’en-tête de chaque panneau.
2. Import JSON — lancez la sonde sur l’hôte cible et collez son JSON :

# Sonde locale préinstallée dans Inventaire ▸ Outils (aucune information d’identification, aucun appel externe)
node infr_server_params_probe.cjs
# Collez le JSON dans [param] ▸ Import JSON pour un upsert idempotent

La sonde s’appuie sur une liste blanche à 5 axes qui ne relève que les valeurs d’optimisation essentielles (mémoire, workers, exécution, délais d’attente) : web nginx -T/conf apache · BD analyse des fichiers my.cnf/postgresql.conf (sans connexion) · noyau sysctl · application php -i/pool.d/gunicorn·tas de la JVM (ps) · divers fichiers de configuration. Les secrets sont masqués.

Sources de données

• infr_instance_param (1:N, UNIQUE(instance_id, category, engine, name), category = varchar(16))
• Sonde scripts/infr_server_params_probe.cjs

Pourquoi node est exclu — les applications pm2/Node ne correspondent pas au modèle « un hôte = une configuration canonique par moteur » (plusieurs applications par hôte ; ecosystem.config.js appartient au dépôt de l’application ; volatil à chaque déploiement) ; elles sont donc exclues de la collecte « application ». python/java sont conservés car les déploiements traditionnels convergent vers un seul serveur d’applications / une seule JVM par hôte.

Accès

Lecture niveau≥1 ; écriture (enregistrer/supprimer/importer) niveau≥2.

Voir aussi

• Registre des versions logicielles — le « ce qui est installé » qui fait pendant au « comment c’est configuré »
• Catalogue de services — sa visionneuse de configuration récupère ces paramètres par type de service
• CMDB des instances