Enregistrement et justification

Pour chaque requête MCP, on consigne ce qui a été consulté, la durée de la consultation, le volume de données concernées et leur provenance. Ce journal n'est pas un simple produit dérivé. C'est ce qui permet de justifier une réponse a posteriori.

Ce qui est consigné

Par requête : l'adresse à partir de laquelle il s'est connecté, le nom de l'outil, la durée de la requête et celle de la requête vers la plateforme source séparément, le nombre de résultats, le nombre de documents récupérés, la taille en octets et l'adresse IP tronquée du demandeur.

À partir de la version 1.3.10, une adresse IP est tronquée avant d'être enregistrée. Avec IPv4, les 16 derniers bits sont supprimés ; avec IPv6, seuls les 32 premiers bits sont conservés. La partie restante identifie un réseau et non un visiteur. Une adresse e-mail qui figure dans un enregistrement, par exemple parce qu’une recherche a été effectuée à son sujet, est remplacée par une valeur irréversible issue d’une plage de 65 536 possibilités. Cela s’applique au journal, au tableau des erreurs, au fichier de trace et à la notification transmise à un service externe. Jusqu’à la version 1.3.9, l’adresse complète figurait dans ces enregistrements ; ces anciennes lignes restent telles qu’elles ont été écrites et disparaissent automatiquement à l’expiration de leur délai de conservation.

À partir de la version 1.3.54, l'organisation mentionnée par le client est également enregistrée. Un client peut inclure l'en-tête x-organisation dans chaque requête, par exemple x-organisation: Gemeente Delft. Cet en-tête est facultatif et n'est envoyé que de temps en temps. C’est le client lui-même qui choisit le nom qu’il y inscrit, et personne ne le vérifie. Cet en-tête ne confère aucun droit : les adresses MCP ne font l’objet d’aucune authentification, et une requête sans en-tête est traitée exactement de la même manière qu’une requête avec en-tête. Le nom de l’en-tête est précisément « x-organisation », avec un « s ». Un en-tête comportant un « z » n’est pas lu ; la valeur n’est alors enregistrée nulle part et l’appel se poursuit normalement. La valeur est placée sur une seule ligne et tronquée après 120 caractères ; elle apparaît ensuite dans le journal à côté de l’identifiant du navigateur. Ces deux éléments ont des significations différentes : l’identifiant du navigateur indique quel programme a effectué l’appel, tandis que l’organisation précise pour le compte de qui. Pour savoir où cette valeur est visible, consultez Opvragingen, Overzicht et Dashboard.

Deux éléments ne sont délibérément pas raccourcis. Le nom du navigateur, car il désigne un programme et non une personne. Et le nom d'utilisateur en cas d'erreur, car il s'agit d'un compte de cette installation.

Non enregistré : le contenu de la conversation entre l'utilisateur et l'assistant. Ce contenu ne parvient pas à BesluitBron. Ce que BesluitBron voit, c'est l'appel effectué par l'assistant, avec les paramètres qui y sont associés.

Où peut-on le voir ?

Les opérations de l'assistant sont consignées dans le journal des demandes :

flowchart TD
    X["ToolExecutor"] --> L["McpRequestLog"]
    L --> J[("Tableau bbn_mcp_log<br/>dans la base de données")]
    L --> RB["Tampon circulaire<br/>en mémoire"]
    J --> LOGP["Page du journal de bord<br/>par connecteur"]
    J --> ANA["Analyse<br/>par outil"]
    RB --> HUB["SignalR"] --> DASH["Tableau de bord<br/>en direct"]
    RB --> TOOL["list_platform_calls<br/>pour l'assistant"]

Quant au serveur lui-même, son fonctionnement suit un deuxième chemin :

flowchart TD
    S["Le serveur lui-même"] --> TJ[("Fichier de trace<br/>un fichier par jour")]
    TJ --> TRP["Page de suivi<br/>à lire et à télécharger"]

Quatre approches, chacune correspondant à une question différente :

• list_platform_calls répond à la question « sur quoi repose cette réponse ? ». L'assistant peut poser lui-même cette question pendant l'entretien ;
• la page du journal de la console d'administration répond à la question « Quelles requêtes ont été effectuées ces derniers jours ? », avec un filtre par connecteur ;
• Le tableau de bord répond à la question « Que se passe-t-il en ce moment ? » et affiche les appels au fur et à mesure qu'ils arrivent ;
• La page de trace répond à la question « qu'a réellement fait le serveur ? ». Cette page n'affiche pas seulement l'appel de l'assistant. Elle affiche également chaque appel vers une plateforme source sous-jacente, en temps réel ou à partir de la mémoire tampon, ainsi que chaque erreur avec sa pile.

Les trois premiers concernent le trafic de l'assistant. La trace porte sur le comportement du service. La trace constitue donc le point de départ lorsqu'un outil a donné une réponse erronée et que le journal des requêtes n'explique pas pourquoi. Le fichier de trace peut être téléchargé dans son intégralité et n'est pas filtré, car une trace modifiée en cours de route n'a plus de valeur probante.

Messages d'erreur

Les rapports portent un code de la forme bbn<gebied><nummer>, par exemple bbnsrv005 pour une configuration dans laquelle toutes les sources étaient désactivées. Ces codes sont fixes. Ils sont destinés à être mentionnés dans un rapport adressé à l'administrateur ou dans une demande adressée au fournisseur, et ne sont pas renumérotés.

Les noms des champs dans le fichier de trace et les noms des colonnes du journal des requêtes sont fixes pour la même raison. Les fichiers de trace existants, les anciens fichiers journaux et les synthèses qui s'y rapportent reposent sur ce principe.

À partir de la version 1.3.58, chaque erreur fait l'objet d'une ligne dans le fichier de trace, accompagnée du code « bbnerr005 » et de l'identifiant de la requête. Jusqu'à la version 1.3.57, une ligne n'apparaissait que si l'enregistrement de l'erreur elle-même échouait ; il n'y avait donc rien en cas de dysfonctionnement de la base de données. Le niveau dépend du type d'erreur : « Error » pour un code 5xx, « Warning » pour un code 4xx et « Debug » pour une requête considérée comme une attaque. Voir Trace.

Conservation

Le journal se trouve dans la table « bbn_mcp_log ». Une base de données est nécessaire à cet effet, et depuis la version 1.3.73, ce n'est plus une option : une installation sans base de données ne démarre pas et indique, au démarrage, ce qui manque. Jusqu’à la version 1.3.72 incluse, il était possible de s’en passer ; le journal était alors enregistré quotidiennement dans un fichier distinct situé dans le dossier de données. Ces fichiers ne sont pas perdus : ils sont lus une seule fois lors du premier démarrage avec une base de données, puis déplacés vers un sous-dossier. Tant qu’ils sont présents, ils sont également supprimés selon la même durée de conservation, et une demande relative aux données à caractère personnel les prend en compte. Le fichier de trace reste un fichier, situé dans un dossier distinct à côté, et suit la même procédure. Voir Uitrol en Beheer et, pour la procédure correspondante, Openbaarheid en Persoonsgegevens.

Le service procède lui-même au nettoyage : le journal d'activité après 90 jours, le fichier de trace après 30 jours, la table des erreurs après 90 jours et les fichiers de sortie après 7 jours. Il s'agit des délais fixés par l'administrateur et non par le visiteur. Le journal d'activité indique si la connexion est utilisée et où elle échoue ; il faut un trimestre pour dégager une tendance. Le fichier de trace sert à détecter un dysfonctionnement qui ne se manifeste qu'au bout de plusieurs semaines. Si vous souhaitez modifier ces paramètres, modifiez les valeurs de BesluitBron:Log:RetentionDays, BesluitBron:Trace:RetentionDays, BesluitBron:ErrorHandling:RetentionDays et BesluitBron:Export:RetentionDays ; une valeur égale à zéro ou inférieure conserve toutes les données.

À partir de la version 1.3.10, ce nettoyage s'effectue quotidiennement, même lorsque le serveur fonctionne pendant des mois d'affilée. Jusqu’à la version 1.3.9, le service ne procédait au nettoyage qu’au démarrage et ne supprimait pas du tout les règles de la base de données. Une installation qui n’était pas redémarrée conservait donc toutes les données. La fréquence des nettoyages est indiquée dans BesluitBron:Retention:IntervalHours ; par défaut, tous les 24 heures. À chaque cycle, le fichier de trace indique ce qui a été supprimé, avec le code « bbnret001 ».

Avec la version 1.3.10, le tableau des erreurs a également été assorti d'un délai de quatre-vingt-dix jours. Le bouton « Supprimer maintenant » sur l'écran « Erreurs » reste disponible pour ceux qui souhaitent nettoyer une période donnée plus tôt ; voir Beheerconsole.