DiagDebug, ou comment aider avec un package de diagnostique

Bonjour tout le monde,

Au détour d’une discussion entre dev de plugin, et revenu une idée que j’avais eu il y a quelques moments.
La question était, « comment faites vous pour bien diagnostiquer un souci et surtout avoir toutes les informations utiles sans faire 80 échanges ».

Lors du développement d’un précédent plugin, j’avais imaginé une solution pour cela. Avec quelques minutes de dev disponible devant moi, j’ai fais une classe et l’ai intégré à mon plugin #plugin-diagral_eone.

Que fait elle ?

Elle permet de généré une archive qui peut contenir :

  • Les logs du plugin
  • Des logs Jeedom (au choix comme par exemple http.error)
  • Le résultat de commande SHELL
  • La configuration du plugin
  • La liste et les configurations des EqLogic du plugin
  • Des fichiers

En quoi c’est utile ?

Ma vision (et libre a chacun de ne pas être d’accord :wink: ) c’est en effet qu’il est possible d’avoir tout cela, en le demandant à l’utilisateur, mais certain :

  • on du mal a se connecter en SSH
  • on du mal a lancer des commandes sans faire de fautes
  • on du mal a récupérer un fichier sur le Jeedom pour le mettre dans community
  • etc…

Ainsi, dans le plugin, est déjà défini ce qui doit être récupéré et mis dans l’archive. L’utilisateur n’a qu’un bouton a cliquer pour générer et collecter en quelques secondes l’ensemble. Il lui suffit de mettre a disposition l’archive.
Cette même archive est consultable par l’utilisateur ainsi il peut verifier que rien de sensible ne peut être dedans (par exemple un mot de passe comme Jeedom les stockes en clair - du coup j’essaye d’offusquer les mots de passe mais il y a tellement de cas que c’est possible que tout ne soit pas géré)

Je met a disposition la classe publiquement si cela peut servir à d’autre ainsi que la documentation associée.

N’héisitez pas à me faire un retour sur ce que vous pensez de l’usage, ainsi que des demandes d’évolution si vous l’utilisez :wink:

4 « J'aime »

Hello,
ça pourrait presque se décliner sous forme de plugin, comme ça on dit à la personne en difficulté d’installer le plugin et hop
dans le plugin diagDebug il coche le/les plugins qui font défauts et on a le compte rendu global :smiley:

quelques infos systèmes pourraient être intéressantes.
je vois souvent passer des problèmes d’espace disque faible, de listing de ports demandés et l’OS installé, charge systeme, uptime etc

très bonne idée pour ceux qui sont un peu pommés dès qu’on utilise « terminal » « sudo » ou autre

Hello,

Non car seul le développeur du plugin sait ce qui est vraiment utile pour diagnostiquer son plugin.

C’est déjà possible avec les commandes Shell.

Bonjour, et merci pour ce boulot :slight_smile:
ça m’intéresse je vais essayer de l’intégrer, mais par contre, que se passe-t-il si un utilisateur installe mon plugin et le tien ? Les 2 ont la même classe, même nom et pas de namespace distinctif ça risque de planter au moment de l’include…

J’avais commencé à mettre une fonction pour mettre dans un zip plusieurs fichiers de config. Ton truc est beaucoup plus complet!

J’ai intégré dans jeedom la phpdebugbar aussi - pour test - pratique pour ajouter du log php et le remonter directement dans l’interface jeedom. un mode debug pour le développeur donc mais je n’imagine pas le livrer sur un jeedom de production par contre.

Hello,

C’est une lib donc elle n’est pas liée à un plugin. Il te suffit de l’intégrer dans le tiens.
Regarde comment je l’ai intégré dans mon plugin Diagral : Intégration de la lib DiagDebug · mguyard/Jeedom-Diagral_eOne@ce296c5 · GitHub

C’est justement le problème: si je l’inclue tel quel, je devrais bien changer le path de base:

require_once (__MON_PLUGIN__.'/3rparty/DiagDebug/DiagDebug.class.php');

et donc si je garde le même nom de fichier / classe, ça fera une collision de nom: qq1 qui installerait nos 2 plugins aurait une erreur.
A moins que tu la copie directement dans le 3rdparty du core ?
Mais sinon, je vais tester, je mettrais un namespace à mon plugin.

Ça posera pas de souci tant que c’est la même version car avec le require_once il chargera uniquement un des deux