Disparition des logs dans l'interface

Bonjour;

Nous avons un problème avec l’affichage des logs dans l’interface web de simplicité.

Alors que les logs sont présents sur le serveur, ils disparaissent de l’interface (/ui/logs) sans qu’il y ait eu de redémarrage ou de clear cache.

Malgré cela, en utilisant les logs qui sont reproduits dans la console du navigateur nous avons pu voir qu’il n’y a eu aucune exception entre 2 disparitions.

Est-il possible de renforcer cet affichage pour que les logs soient plus persistants ? Le problème pourrait se montrer grave dans le cas d’un suivi de production et il est handicapant pendant la phase de développement.

Ce pb ne me dit rien. Pouvez vous préciser le symptôme avec des copies d’écran, le mode opératoire, vos éventuelles customisations du log4j.xml, etc. ?

Ceci dit ces logs serveur (qui correspondent aux logs par défaut stockées dans le fichier simplicite.log) sont par défaut remontés dans la console du navigateur via websockets, la page legacy de remontées des logs est donc déjà une solution de repli pour les environnements où les websockets ne sont pas utilisables.

Mais dans tous les cas l’idéal pour consulter les logs serveur de manière fiable reste d’aller à la source sur le serveur, en effet que ça soit par les websockets ou via la page de consultation legacy ce que vous voyez dépend alors du contexte de la session utilisateur de la UI et/ou de subtilités réseau (dans le cas des websockets)

Je constate bien un problème en V5 alpha

image

Uniquement si on n’a pas d’appender SIMPLICITE-FILE

Bizarre, moi, je ne reproduis pas ce pb sur une 5.1 (alpha) à jour:

[Platform]
Status=OK
Version=5.1.0-alpha
BuiltOn=2020-11-02 18:51

On parle de quelle version exactement ?

Oui ça marche sauf s’il n’y a pas d’appender SIMPLICITE-FILE
Cette (très) vieille servlet a besoin d’un fichier physique pour lire les logs.

Regardez dans votre fichier webapps\ROOT\WEB-INF\classes\log4j.xml la présence de cet appender dans le root :

...
	<!--  Daily rotating file appender -->
	<appender name="SIMPLICITE-FILE" class="org.apache.log4j.DailyRollingFileAppender">
		<param name="File" value="${catalina.base}/webapps/ROOT/WEB-INF/log/simplicite.log"/>
		<param name="Append" value="true"/>
		<param name="Threshold" value="INFO"/>
		<param name="DatePattern" value="'.'yyyy-MM-dd"/>
		<layout class="org.apache.log4j.PatternLayout">
			<param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
		</layout>
	</appender>
...
	<root>
		<!-- appender-ref ref="SIMPLICITE-CONSOLE"/ -->
		<appender-ref ref="SIMPLICITE-FILE"/>
	</root>

Quand à la question du monitoring de Simplicité, il ne faut surtout pas passer par là.

  • Il faut utiliser le health check /health
  • ou ajouter d’autres appenders sur le niveau FATAL uniquement vers vos agents de supervision

Monitorer des erreurs ou des warning n’a pas de sens car cela reste applicatif ou métier.
Seuls les FATALs sont intéressants si le /health ne répond pas 200 dans un premier temps.

(base de données inaccessible, clé de licence invalide…)

PS:

Je viens de tester sur une image Docker 5-beta (car je pense que c’est ça que vous utilisez dans votre cas) sa version exacte est :

[Platform]
Status=OK
Version=5.0.0-beta
BuiltOn=2020-11-02 19:17

Je ne constate pas de pb de remontées de logs ni via la page legacy ni via les websockets dans la console du navigateur (ni bien entendu en faisant un docker logs -f sur le container). J’ai testé un chargement de module, clear cache, etc.

Il doit donc y avoir quelque chose de particulier dans votre cas (lié à votre installation / configuration / mapping de volumes Docker, aux droits/scope de votre user, …) mais je ne vois pas quoi.

NB: si vous switchez par exemple le user designer sur un scope plus restreint (ex: demo) il n’est pas impossible qu’il n’aie pas les droits sur ce composant dans ce cas vous aurez une page qui dit “NOT_GRANTED” mais en revenant ensuite sur un scope avec les droits ad hoc la page se réaffiche correctement

Merci pour tout ces retours.

Je vais essayer d’apporter plus d’informations :

Le problème se produis au moment de l’appel à une action back qui appel du js :

    public String openChgtEtatCivilAvenantForm() {
        return javascript(
                "var b = app.getBusinessObject('NamContratAvenant', '"+ NamInstanceName.AVENANT_CHG_ETAT_CIVIL +"'); " +
                        "$ui.displayForm(null, b, app.DEFAULT_ROW_ID, { parent: { name: obj.getName(), inst: obj.getInstanceName(), field: 'namCavenantJenId', rowId: obj.getRowId(), object: " + this + " } })"
        );
    }

L’utilisateur es bien redirigé vers la page et à ce momment la page des logs est vidée sans qu’une exception n’apparaisse dans les logs de la console du navigateur.

( malheurreusement pour le moment je ne serais pas en mesure de founir plus de trace, je suis bloqué par un aurtre problème actuellement )

Pour l’utilisation de cette page, je comprends que cette page n’est pas une source “fiable” pour les logs mais je n’étais pas au courant. Avez-vous une liste des features / pages qui sont a considérer comme legacy ? ( pour éviter de remonter des annos dessus dans l’avenir )

Je ne vois à priori pas de rapport à priori entre le fait d’invoquer une action sur un objet et le fait que la page de consultation des logs se vide (sachant que cette page s’affiche dans une fenêtre à part).

Je vais essayer de reproduire ce que vous décrivez.

NB: il y a un pb dans le code que vous indiquez. Dans l’exemple que je vous ai indiqué dans Ne pas persister un objet pour afficher le formulaire avec une action je n’ai pas mis object: " + this " mais object: obj (le this correspond à l’objet java coté serveur il n’est donc pas pertinent dans du code JS client où il faut utiliser obj qui est l’objet JS). Je ne sais pas trop quels effets de bords inattendus ce code peut potentiellement générer…

Je ne reproduis pas ce que vous décrivez sur la page de consultation des logs avec l’exemple code que je vous ai fourni dans Ne pas persister un objet pour afficher le formulaire avec une action

Bref, soit c’est un effet de bord bizarre de votre code, soit la manip que vous effectuez est plus complexe que ce que vous indiquez.

Pouvez vous faire des copies d’écran ou une vidéo de votre pb ?

PS: la page historique de consultation des logs sert uniquement pour les gens qui ont des pbs avec les remontées des logs serveur via websockets dans la console du navigateur (c’est parfois le cas sur certains réseau d’entreprise où des firewall/reverse proxies filtrent ou coupent les flux websockets). Elle date de la version 3 de Simplicité, époque à laquelle les websockets n’existaient pas, on l’a conservée uniquement comme solution “de secours” mais sans faire d’effort particulier pour son look&feel ni pour l’enrichir, c’est à ce titre qu’on a la considère “legacy” mais tant qu’elle sera là (elle ou tout autre composant legacy) elle n’est pas sensée avoir de bug donc il faut bien nous remonter les pbs que vous rencontrez

Par contre, comme je le dit tout composant UI de consultation des logs serveur (que cela soit les logs remontées via websockets dans la console du navigateur ou cette page legacy) est forcément plus “contraint” que la consultation des logs serveur directement à la source (docker logs --follow <container ID> ou équivalent). En effet l’accès à ces composants est lié aux droits (éventuellement restreint pas un scope) du user connecté et parfois à des bizarreries liées à la “tuyauterie” réseau.

En tout état de cause les éventuels pbs Javascript client seront eux uniquement visibles dans la console du navigateur, c’est pour cela que la bonne approche de base pour suivre les logs au sens large = serveur et client c’est en général la console navigateur (avec les logs websockets actives pour le user connecté). Sinon gardez toujours un oeil à la fois sur la console du navigateur et les logs serveur au plus près du serveur.

Il y a un fonctionnement connu et normal :

Les logs de cette page “se vident” si vous vous relogguez car le JSESSIONID n’est plus valide, et le refresh périodique ne remonte plus rien avec un id de session invalide.

Il faut alors réouvrir la page contenant la servlet /logs avec le nouveau JSESSIONID.

Oui et/ou on peut ne plus avoir les droits en changeant de scope (auquels cas on a le message “NOT_GRANTED” qui apparait comme indiqué plus haut), là aussi rien d’anormal.

Une fois qu’on revient sur un scope avec les droits qui vont bien le reload de la page reaffiche les logs.

C’est ce que je veux dire par “contraint” s’agissant des composants UI pour les logs serveur => quand on regarde les logs à la source, on n’est pas soumis à ces subtilités de droits liés à la session et/ou au scope utilisateur dans la UI.