Architecture

NIE-SLA répartit la collecte, les sondes, le stockage, l'affichage et les extensions tierces en zones de confiance. Comprendre ces frontières évite de confondre « VPS en ligne », « joignable par Cloudflare » et « latence externe ». Nouveau sur le projet ? Commencez par la présentation.

Composants

Composant	Emplacement	Rôle
Agent Rust	VPS surveillée	échantillonnage à la seconde, sondes TCP/HTTP, envois par lots
Agent Latency	nœud Linux indépendant	sonde des cibles TCP publiques depuis d'autres réseaux
Worker	edge Cloudflare	routage, authentification, planification, agrégation, alertes, API publique
Durable Objects	Cloudflare	coordination des sondes régionales, tampon de télémétrie par Agent
D1	Cloudflare	configuration, état, agrégation, événements, index
R2	Cloudflare	historique haute fréquence, instantanés, archives, paquets de thèmes
Worker Static Assets	Cloudflare	page d'état publique, interface d'administration, API même origine

La production est un seul Worker servant l'API et les Static Assets depuis la même origine ; aucun projet Pages séparé. Le dépôt public de déploiement un clic est une source de publication désensibilisée ; conservez les frontières de sources Worker, Frontend et Agent, et ne réécrivez jamais les sources de production depuis les archives ou la copie publique.

Chemins de données

Agent Rust --jeton scoped--> Worker --> D1 / R2 --> État public
                                     |
Sonde Cloudflare --------------------+
                                     |
Agent Latency --jeton scoped---------+

L'échantillonnage, l'envoi, le ping et la vérification de mise à jour suivent des planificateurs séparés. Une VPS peut échantillonner chaque seconde pendant que le Worker ne reçoit que des lots ; un réseau lent ne bloque pas l'échantillonnage local.

Quatre états de latence et de disponibilité

Source	Initiée par	Répond à
Sondes Cloudflare	Worker / Durable Object	l'edge Cloudflare peut-il joindre la cible, à quelle latence
État de l'Agent	VPS surveillée	l'Agent de métriques rapporte-t-il toujours
Sondes réseau de l'Agent	VPS surveillée	qualité réseau de l'hôte vers une cible TCP/HTTP
Latence externe	nœuds indépendants	latence depuis d'autres régions/fournisseurs vers des cibles TCP publiques

Les clients doivent conserver les étiquettes de source. Un Agent en ligne n'implique pas un sondage Cloudflare réussi, et un port ouvert n'implique pas que l'Agent de métriques tourne.

Stratégie de stockage

Les métriques brutes par seconde ne sont pas écrites dans D1 :

• L'état courant et les index vivent dans D1.
• L'historique haute fréquence va d'abord dans R2.
• L'historique SLA est agrégé en buckets fixes dans D1.
• Le trafic s'accumule dans la ligne de la période courante ; chaque Agent scelle une ligne de registre quotidien par jour, et les changements de jour de remise à zéro se recalculent depuis le registre quotidien.
• Les endpoints d'état utilisent de courts caches.
• Le nettoyage tourne selon un planning, pas à chaque requête.

Cela garde l'état public frais tout en bornant les requêtes Worker, les écritures D1 et les opérations R2.

Données de perte brutes et export de séries temporelles optionnel

R2 conserve les points de sonde bruts rapportés par les Agents. Les courbes de latence habituelles sont sous-échantillonnées selon les limites de l'API publique ; include_loss=1 renvoie tous les événements de perte sans perte sous forme de runs compacts, afin qu'une longue panne n'exige pas d'objets à la seconde dans le navigateur.

L'export de séries temporelles externe est désactivé par défaut. Avec TIMESERIES_EXPORT_URL défini, le Worker exporte des lots depuis R2 par Agent et par heure complète ; TIMESERIES_EXPORT_FORMAT vaut victoriametrics (défaut) ou influx, avec des identifiants Bearer optionnels via TIMESERIES_EXPORT_TOKEN. L'URL doit être en HTTPS sans identifiants intégrés. Ces valeurs ne proviennent que des Worker Secrets ou de l'environnement de déploiement ; elles n'entrent jamais dans le frontend, les commandes Agent, l'API publique, les sauvegardes ou les sources.

L'export utilise un marqueur de nouvelle tentative borné. En cas d'expiration, de limitation ou d'indisponibilité distante, l'archivage R2 et l'ACK Agent restent réussis ; après la limite de nouvelles tentatives, seul cet essai d'export est abandonné, jamais les données R2. Sans export configuré, aucune requête externe n'est ajoutée et le chemin de stockage 100 VPS reste inchangé.

Interfaces et frontières de confiance

Interface	Authentification	Peut faire
/api/v1/*	aucune	lire l'état public désensibilisé et l'historique
/api/agent/*	jeton scoped du nœud	l'Agent Rust correspondant rapporte et lit la politique
/api/latency-agent/*	jeton scoped du nœud	le nœud de latence récupère les cibles, rapporte, se met à jour
API d'administration	session courte, TOTP optionnel	modifier la configuration, téléverser des thèmes, lire les données admin

Les thèmes Canvas et les frontends alternatifs ne peuvent utiliser que l'API publique v1. Ne transmettez jamais de sessions admin, mots de passe, TOTP, Token maître Agent ou jetons scoped de nœud à un thème ; le runtime de plugins n'est pas ouvert.

Les mots de passe et tickets OAuth GitHub n'existent que pour la connexion. Après connexion, l'interface utilise la session courte x-admin-session ; les mots de passe ne doivent pas être stockés comme jetons API ni relayés par des frontends alternatifs. Les Agents et nœuds de latence utilisent des jetons scoped par nœud qui cessent de fonctionner quand le nœud est désactivé.

Frontière des images NodeQuality

Les images NQ Network et Return Route sont rendues et téléversées par le Worker après l'achèvement d'une tâche authentifiée. La chaîne de téléversement est un canal S3 fixe avec dossier vide ; le frontend, l'Agent et l'API admin ne peuvent ni lire ni remplacer l'URL, le jeton, le canal ou le dossier de téléversement.

• URL, jeton et nom de canal optionnel ne sont que des Worker Secrets.
• Seules les tâches créées par un admin, réclamées par la bonne identité Agent et terminées avec succès déclenchent un téléversement.
• Il n'existe aucun réglage navigateur, aucun téléversement de test, aucun endpoint d'envoi de fichier arbitraire.
• Le JSON NQ public ne renvoie que des proxys d'images même origine ; la vraie URL amont est résolue à l'intérieur du Worker.
• Les sauvegardes normales excluent les anciennes métadonnées d'hébergeur d'images ; les sauvegardes sensibles sont chiffrées par mot de passe.
• Les déploiements auto-hébergés appellent le broker public officiel fixe sans identifiants d'hébergeur d'images ; les identifiants partagés n'existent que dans les Worker Secrets officiels et n'entrent jamais dans les sources, le build, les tutoriels ou les requêtes broker.

Le broker accepte un texte network/route borné, re-rend l'SVG côté serveur et limite en débit par source et globalement via D1. Cela donne aux auto-hébergeurs une sauvegarde d'images NQ sans configuration, sans transformer l'hébergeur partagé en API de téléversement arbitraire. Les instances non officielles ne peuvent pas remplacer la chaîne publique fixe avec leurs propres secrets.

Les quatre onglets NQ conservent le contenu ANSI d'origine. Network et Return Route utilisent le rendu segmenté historique quand le texte original existe ; les images broker ne remplissent que les vieilles données sans texte. Le mobile utilise une taille de police monospace compacte fixe, la modale ne défile que verticalement, les segments réseau larges défilent horizontalement dans leur zone, et les sauts du trajet retour utilisent une grille responsive. La page publique et l'interface admin partagent les mêmes règles.

État courant vs SLA à long terme

Le cron rafraîchit l'état courant des sondes et alertes chaque minute ; le SLA long terme et les grilles quotidiennes restent sur des buckets de 5 minutes. Avec FAST_STATUS_ENABLED désactivé, l'état actif des sondes retombe à la granularité des buckets.

« Dernier état sur la page publique » et « une nouvelle cellule de grille quotidienne » n'ont pas besoin de la même fréquence. Les intégrations doivent lire checked_at, updated_at et les champs de source plutôt que d'inférer la vivacité depuis la longueur des tableaux.

Runtime des thèmes

Les thèmes CSS ne chargent que des feuilles de style vérifiées. Les thèmes Canvas tournent dans une iframe sandbox="allow-scripts" sans accès même origine ; la CSP bloque le réseau direct, les formulaires et la navigation de niveau supérieur, et les données arrivent via le protocole de messages restreint. Les API de téléversement de plugins et les runtimes de plugins ne sont pas ouverts. Voir Système de thèmes et Sécurité et publication.