LOG trop volumineuse pour faire une analyse : occurences de lignes à supprimer

Bonjour,

Nous rencontrons actuellement un incident bloquant sur Vision360 concernant le fichier de log, qui est devenu extrêmement volumineux et difficile à analyser.

Une très grande quantité de lignes (environ 150 000) proviennent de messages internes Simplicité liés à l’objet de traduction m_translate :

delete from m_translate where row_id=
-- dead link detected m_translate.tsl_id /

Ces messages semblent issus d’un traitement interne Simplicité (cleanup / tâches planifiées / gestion des liens orphelins sur m_translate).

Pouvez-vous svp vérifier de votre coté?

On parle de l’instance de PROD de Vision36O.

Merci pour votre support.

Cordialement,
Safae

Bonjour,

Quelle est votre version exacte ?

Car l’audit ne scanne pas la table m_translate dont le foreign-key était composite en 5.3 (tsl_type+tsl_id qui deviendra tsl_object en V6).

Désactivez la cron d’audit DesignAudit en attendant de trouver la cause de votre pb.

Bonjour François,

Merci pour votre retour.

Notre version est la suivante :

  • Simplicité : 5.3.80

Dans notre instance (Dev juste pour test avant la prod), le cron DesignAudit appartient au module System et le champ “Actif” est en lecture seule (les boutons Oui/Non sont désactivés), même avec un compte administrateur.

Merci pour votre aide.
Safae

Vous êtes sur quel SGBD ? Il faudrait systématiquement nous donner toutes les infos du /health dans vos posts.

Côté runtime vous êtes à jour, mais pourtant le test dans l’audit ne s’applique pas chez vous :

	// ignore translate with specific join (need tsl_type + tsl_id)
	if ("m_translate".equals(table))
		continue;

La table vient du nom en base obj_dbtable de l’objet Translate. Il y a peut être un pb de case sensitive, mais vue la log elle est bien en minuscule. Je ne comprends pas.
On va faire des tests.

Sinon il faut devenir “admin système” pour modifier un objet système (Cron ou autre).

  • Vous connecter en “designer”
  • ou ajouter le param systeme ADMIN_SYSTEM = yes à votre utilisateur avec la responsabilité ADMIN

Bonjour François,

Suite à votre question sur le SGBD, je vous confirme les informations exactes issues du /health :

  • PROD : PostgreSQL 14.19

→ Voici l’extrait du /health PROD :

\[Platform\]
Status=OK
Version=5.3.66
BuiltOn=2025-03-28 12:44
Git=5.3/82ec208f18035caf9976bcd38c47e140ce01aa13
Encoding=UTF-8
EndpointIP=10.10.1.2
EndpointURL=http://12da651c3932:8080
TimeZone=Europe/Paris
SystemDate=2025-11-20 17:45:04

\[Application\]
ApplicationVersion=1.4.3
ContextPath=
ContextURL=https://vision360.tdf.fr
ActiveSessions=4
TotalUsers=708
EnabledUsers=704
LastLoginDate=2025-11-20 17:44:27

\[Server\]
ServerInfo=Apache Tomcat/9.0.102
ServerType=WEB
ServerActiveSessions=4
ServerSessionTimeout=30
CronStarted=true

\[OS\]
Name=Linux
Architecture=amd64
Version=5.15.0-160-generic
DockerImageName=almalinux9
SystemEncoding=UTF-8

\[JavaVM\]
Version=17.0.14
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.14+7
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=70445
HeapSize=506816
HeapMaxSize=506816
TotalFreeSize=70445

\[Cache\]
ObjectCache=288
ObjectCacheMax=10000
ObjectCacheRatio=2
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=1
APIGrantCacheMax=1000
APIGrantRatio=0

\[Database\]
Vendor=3
VendorName=postgresql
ProductName=PostgreSQL
ProductVersion=14.19 (Ubuntu 14.19-1.pgdg22.04+1)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.7.5
DBDate=2025-11-20 17:45:04
DBDateOffset=0
DBPatchLevel=5;P03;0f83c9907328ed617ed5248ed09aab16;64
UsingBLOBs=true

\[Healthcheck\]
Date=2025-11-20 17:45:04
ElapsedTime=36

En revanche, comme nous n’intervenons pas sur PROD, l’éventuelle désactivation du cron devra être réalisée côté client TDF.

Nous restons disponibles pour tout test complémentaire et pour vous fournir d’autres éléments si besoin.

Merci encore pour votre support,
Safae

Vous n’êtes donc pas à jour. Comme déjà indiqué ce pb de log a été corrigé (pas de bol en 67).

cf release note :

5.3.67 (2025-04-11) - maintenance revision {#version-5.3.67}

  • Inhibited “dead links” design audit checks on the translation table to avoid potential false positives

Il faut donc vous mettre à jour, pour éviter de nous remonter des pb déjà corrigés.

  • Toute demande de support sur une branche en LTS nécessite forcement d’être à jour puisqu’un éventuel correctif sera fait sur la branche à jour
  • Inhiber la cron n’est qu’un contournement.

A ma connaissance, ce n’est pas non plus de notre responsabilité.
Merci de voir cela avec votre client pour qu’il se mette à jour avant de solliciter du support.