For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/hosted-private-cloud/opcp/how-to-diagnose-control-plane.md.

Comment diagnostiquer le plan de contrôle OPCP avec opcp-diag

Voir en Markdown

Découvrez comment diagnostiquer votre contrôleur OPCP avec opcp-diag, appliquer des corrections automatiques et générer un bundle de diagnostic pour le support OVHcloud

Objectif

Sur une plateforme OVHcloud On-Prem Cloud Platform (OPCP), l'outil opcp-diag exécute des vérifications de santé sur le plan de contrôle hébergé sur votre contrôleur : l'hôte lui-même, le cluster Kubernetes et les composants de la plateforme (FluxCD, OpenTofu, OpenStack, Keycloak, etc.).

Pour certains problèmes connus, opcp-diag peut également appliquer une correction automatique. À la fin de chaque exécution, il rassemble ses résultats, ses journaux et ses extractions dans un bundle de diagnostic que vous pouvez transmettre au support OVHcloud.

Ce guide explique comment lancer un diagnostic avec opcp-diag, lire ses résultats, appliquer des corrections automatiques et envoyer le bundle de diagnostic au support OVHcloud.

Prérequis

  • Disposer d'un service OPCP actif.
  • Disposer d'un accès SSH à votre contrôleur OPCP avec votre compte opcp-admin, le compte administrateur Linux qui vous est remis avec votre OPCP. Ce compte peut exécuter opcp-diag, que votre OPCP soit managé par OVHcloud ou non (consultez le guide « Gestion des droits IAM »). Aucun rôle particulier sur la plateforme n'est nécessaire, car opcp-diag utilise les identifiants du contrôleur lui-même.
  • Disposer de l'outil opcp-diag sur le contrôleur (/usr/local/bin/opcp-diag).

En pratique

opcp-diag regroupe ses checks en suites, chaque suite couvrant un domaine du plan de contrôle. Certains checks proposent une correction automatique, qui ne s'exécute que si le check échoue et si vous l'avez activée.

Toutes les commandes et options sont décrites dans l'aide intégrée :

opcp-diag --help
opcp-diag run --help

1. Lancer un diagnostic

Connectez-vous à votre contrôleur en SSH, puis exécutez :

sudo opcp-diag run

Cette commande exécute toutes les suites. Les corrections automatiques sont désactivées par défaut : cette exécution ne modifie pas votre plateforme.

Pour chaque check, opcp-diag affiche sa description et son résultat, puis un résumé à la fin de l'exécution :

=> [1/3] FilesystemInode
(i) Checks inode availability on the root filesystem to detect exhaustion that can prevent file creation.
[OK] SUCCESS [FilesystemInode]: Filesystem '/' has 95.21% inodes free
...
================================================================================
# DIAGNOSTIC SUMMARY
================================================================================
Total Checks: 3
Total SubChecks: 0
Total Retry Attempts: 3
[OK] Passed: 3 | [KO] Failed: 0 | [!] Warnings: 0 | [!!] Errors: 0 | [TO] Timeouts: 0

[AF] Autofix Summary:
* Checks with autofixes: 0
* Checks resolved by autofix: 0

Output bundle to ./opcp-diagnostic-controller-20261028T151816Z (id: 010cb15c-312a-4862-a2dd-06dc3a9a8f94)
MarqueurRésultatSignification
[OK]SUCCESSLe check a réussi.
[!]WARNINGLe check a relevé un point qui nécessite votre attention.
[KO]MINOR, MODERATE ou CRITICALLe check a échoué. Le libellé indique la sévérité de l'échec.
[!!]ERRORLe check n'a pas pu s'exécuter correctement (par exemple, un service était injoignable).
[TO]TIMEOUTLe check ne s'est pas terminé avant le délai imparti.

Consultez le résumé pour connaître le résultat du diagnostic : la commande se termine avec le code de sortie 0 même lorsqu'elle détecte des problèmes.

Pour une utilisation dans des scripts, ajoutez l'option --headless. opcp-diag n'affiche alors rien et ne génère aucun bundle, et son code de sortie est différent de 0 si un problème est détecté :

sudo opcp-diag run --headless

Sans --headless, la dernière ligne de la sortie indique le chemin du bundle de diagnostic, créé par défaut dans le répertoire courant. Il contient le résumé de l'exécution (summary.txt), ses métadonnées (metadata.yaml), la configuration appliquée (used-config.yaml) et un répertoire par domaine avec les journaux et les extractions collectés.

2. Sélectionner les suites et checks à exécuter

Pour lister les suites et les checks disponibles sur votre contrôleur, avec leur description :

opcp-diag list --suites
opcp-diag list --checks

Passez ensuite leurs noms, séparés par des virgules, pour restreindre ou exclure des suites et des checks :

sudo opcp-diag run --suites <suite1>,<suite2>
sudo opcp-diag run --exclude-checks <check1>,<check2>

Les options --exclude-suites et --checks fonctionnent de la même manière. Saisissez les noms exactement tels qu'opcp-diag list les affiche.

3. Appliquer des corrections automatiques

Pour lister les checks qui proposent une correction automatique, avec la description de chaque correction :

opcp-diag list --autofixes

Activez les corrections automatiques de checks précis avec --fix, ou toutes avec --fix all :

sudo opcp-diag run --fix <check1>,<check2>
sudo opcp-diag run --fix all
Warning

Les corrections automatiques modifient l'état de votre plateforme. Lancez d'abord un diagnostic sans correction automatique, analysez les résultats, puis activez uniquement les corrections dont vous avez besoin.

4. Autres options

opcp-diag run propose d'autres options, par exemple pour changer l'emplacement du bundle (--bundle-path), filtrer les résultats affichés (--filter-results) ou ajuster le délai d'expiration des suites (--timeout). Exécutez opcp-diag run --help pour en obtenir la liste complète.

Vous pouvez aussi définir ces options dans un fichier de configuration YAML, lu par défaut depuis /opt/opcp/.opcp-diag.yaml ou depuis le chemin indiqué avec --config. Le fichier used-config.yaml d'un bundle est un bon point de départ pour écrire le vôtre.

5. Envoyer le bundle de diagnostic au support OVHcloud

Le bundle de diagnostic peut contenir des informations sensibles sur votre plateforme : variables d'environnement, processus en cours d'exécution, journaux des pods, listes des utilisateurs et rôles Keycloak, listes des ressources et secrets OpenStack, fichiers système, etc.

Avant de le partager :

  1. Vérifiez son contenu. Si nécessaire, relancez le diagnostic avec --exclude-checks pour écarter les données que vous ne souhaitez pas partager.

  2. Compressez le bundle. Cette étape ne nécessite pas sudo : votre compte opcp-admin peut lire le bundle créé par opcp-diag.

    tar czf opcp-diagnostic.tar.gz opcp-diagnostic-controller-20261028T151816Z/

  3. Importez la clé publique GPG fournie par le support OVHcloud, puis vérifiez son empreinte auprès de votre contact OVHcloud par un canal distinct :

    gpg --import ovhcloud-support.asc
gpg --fingerprint

  4. Chiffrez l'archive pour cette clé :

    gpg --output opcp-diagnostic.tar.gz.gpg --encrypt --recipient <empreinte-de-la-cle> opcp-diagnostic.tar.gz

    La clé n'étant pas signée dans votre trousseau, gpg vous demande de confirmer son utilisation : répondez y, après avoir vérifié son empreinte à l'étape précédente.

  5. Envoyez le fichier chiffré opcp-diagnostic.tar.gz.gpg au support OVHcloud, en pièce jointe de votre demande d'assistance. Sur une plateforme déconnectée (air-gapped), sortez le fichier chiffré de la plateforme selon vos procédures de sécurité.

Warning

N'envoyez jamais un bundle de diagnostic non chiffré par e-mail ou par un canal non sécurisé.

Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?