- \n
- Causes<\/strong>: \u00e9carts de quartz, virtualisation, gel de sauvegarde, synchronisation incorrecte des h\u00f4tes<\/li>\n
- Suivre<\/strong>: erreurs Kerberos, jobs retard\u00e9s, logs contradictoires, fausses alertes<\/li>\n
- Diagnostic<\/strong>: v\u00e9rifier les offsets, ntpq -p, w32tm, limites d'alarme de surveillance<\/li>\n
- Solution<\/strong>NTP\/Chrony, \u00e9mulateur PDC, d\u00e9sactiver la synchronisation de l'h\u00f4te, personnaliser le polling<\/li>\n
- Cabinet m\u00e9dical<\/strong>topologie de la strate, lib\u00e9ration de l'UDP 123, contr\u00f4les r\u00e9guliers de la d\u00e9rive<\/li>\n<\/ul>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/serverzeitdrift-it-check-5912.png\")
\n<\/figure>\n\n\nQue signifie concr\u00e8tement la d\u00e9rive du temps du serveur ?<\/h2>\n\n
Horloges serveur<\/strong> ne fonctionnent jamais parfaitement, ils d\u00e9rivent en raison des variations de temp\u00e9rature, des dispersions de quartz ou des minuteries virtuelles. Dans les syst\u00e8mes r\u00e9partis, de minuscules \u00e9carts s'additionnent rapidement et g\u00e9n\u00e8rent des erreurs visibles, comme des \u00e9v\u00e9nements mal class\u00e9s ou des messages trait\u00e9s trop tard. Lors des audits, je constate souvent que quelques secondes suffisent \u00e0 faire basculer l'ordre dans les pipelines de logs et \u00e0 fausser les \u00e9valuations. Lorsque la charge augmente, les syst\u00e8mes mettent en m\u00e9moire tampon les messages avec des horodatages locaux qui se trompent ensuite de quelques minutes et g\u00e9n\u00e8rent des retards pr\u00e9sum\u00e9s. D\u00e9rive du temps du serveur<\/strong> reste perfide, car tout semble correct localement, jusqu'\u00e0 ce qu'un service effectue une comparaison transversale ou qu'une r\u00e9plication se d\u00e9clenche.<\/p>\n\n
Pourquoi quelques minutes peuvent tout briser<\/h2>\n\n
Kerberos<\/strong> ne tol\u00e8re qu'un petit d\u00e9calage temporel ; quelques minutes de d\u00e9rive suffisent pour que les tickets soient refus\u00e9s et que les connexions \u00e9chouent. J'ai vu des environnements dans lesquels 3 minutes de diff\u00e9rence suffisaient \u00e0 ralentir la r\u00e9plication et \u00e0 bloquer les changements de mot de passe. Les points de mesure de la latence se confondent : des n\u0153uds de mesure non synchrones signalent soudain des valeurs n\u00e9gatives et g\u00e9n\u00e8rent de fausses alertes. Dans les bases de donn\u00e9es, les transactions perdent leur ordre chronologique, ce qui entra\u00eene de graves erreurs lors des flux CDC ou de l'Event-Sourcing. Ceux qui ont besoin d'audits ou d'analyses m\u00e9dico-l\u00e9gales \u00e9chouent \u00e0 cause de des logs incoh\u00e9rents<\/strong>, si les timestamps sautent ou se d\u00e9doublent.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/servertimedriftmeeting2946.png\")
\n<\/figure>\n\n\nVirtualisation : Proxmox, Hyper-V et VMware<\/h2>\n\n
hyperviseur<\/strong> modifient le comportement temporel, car les VM subissent des minuteries virtuelles, des pauses et des snapshots. Pendant les sauvegardes, l'invit\u00e9 se fige, le temps de l'h\u00f4te continue \u00e0 s'\u00e9couler et l'invit\u00e9 recule parfois de plusieurs heures apr\u00e8s la reprise. Je vois souvent ces sauts dans les machines virtuelles Windows, lorsque la synchronisation de l'h\u00f4te et le NTP de l'invit\u00e9 s'opposent. Un h\u00f4te qui se trompe induit \u00e9galement un temps erron\u00e9 pour tous les invit\u00e9s via les services d'int\u00e9gration Timesync, ce qui affecte particuli\u00e8rement Active Directory. Ceux qui travaillent dans Proxmox, VMware ou Hyper-V devraient contr\u00f4ler activement Timesync dans l'invit\u00e9 et d\u00e9sactiver la double synchronisation de mani\u00e8re cibl\u00e9e, afin de Conditions de course<\/strong> d'\u00e9viter.<\/p>\n\n
Mesure et diagnostic au quotidien<\/h2>\n\n
Diagnostic<\/strong> commence par le d\u00e9calage : je v\u00e9rifie ntpq -p ou chronyc sources et je lis les d\u00e9calages en millisecondes \u00e0 secondes. Sous Windows, w32tm \/query \/status fournit des donn\u00e9es exploitables ; sous Linux, timedatectl aide \u00e0 savoir si NTP est actif. Les logs trahissent souvent des messages \u201etime went backwards\/forwards\u201c qui indiquent des sauts. Pour une vue d'ensemble continue, je mets en place un simple moniteur de d\u00e9rive qui signale les \u00e9carts par rapport au serveur de r\u00e9f\u00e9rence et donne l'alerte \u00e0 partir de 100-200 ms. Si vous souhaitez aller plus loin, vous trouverez des \u00e9tapes pratiques dans ce guide compact : Pratique du NTP et de Chrony<\/a>, J'aime l'utiliser comme liste de contr\u00f4le.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/server-time-drift-loesung-2841.png\")
\n<\/figure>\n\n\nConfiguration : param\u00e9trer proprement le service horaire Windows et Linux<\/h2>\n\n
Windows<\/strong> Les serveurs \u00e0 partir de 2016 corrigent la d\u00e9rive de mani\u00e8re beaucoup plus pr\u00e9cise si la source est correcte et si aucun service de synchronisation concurrent n'est en cours d'ex\u00e9cution. Je configure l'\u00e9mulateur PDC comme source faisant autorit\u00e9, je d\u00e9finis w32tm \/config \/manualpeerlist : \u201cpool.ntp.org,0x8\u2033 et je fixe des intervalles de polling qui correspondent au r\u00e9seau et aux besoins. Sur Hyper-V, je d\u00e9sactive la synchronisation de l'heure dans le service d'int\u00e9gration pour les contr\u00f4leurs de domaine afin que seul NTP d\u00e9cide. Je pr\u00e9f\u00e8re utiliser les h\u00f4tes Linux avec Chrony, car les corrections sont rapides et les d\u00e9calages restent de l'ordre de la milliseconde. Important : Double sync<\/strong> \u00e9viter, donc soit la synchronisation h\u00f4te, soit NTP dans l'invit\u00e9 - pas les deux en m\u00eame temps.<\/p>\n\n
Active Directory : comprendre les r\u00f4les, \u00e9viter les erreurs<\/h2>\n\n
\u00c9mulateur PDC<\/strong> d\u00e9termine le temps dans le domaine et devrait lui-m\u00eame avoir des sources fiables en amont, id\u00e9alement plusieurs. Les contr\u00f4leurs de domaine n'acceptent qu'un petit \u00e9cart ; ceux qui le d\u00e9passent risquent de voir leurs tickets rejet\u00e9s et leurs r\u00e9plications \u00e9chouer. Je garde l'\u00e9mulateur PDC physiquement proche des sources Stratum 1\/2 et je le s\u00e9pare du timesync de l'hyperviseur. Je planifie les sauvegardes et les snapshots sur les DC de mani\u00e8re \u00e0 ce qu'ils ne d\u00e9r\u00e9glent pas l'horloge, et je teste la reprise en me concentrant sur le temps. Avec des r\u00f4les propres et des do's & don'ts, on stabilise Authentification<\/strong> et de la fen\u00eatre de r\u00e9plication.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/server-time-drift-buero-2984.png\")
\n<\/figure>\n\n\nArchitecture : topologies NTP, Strata et r\u00e9seau<\/h2>\n\n
NTP<\/strong> fonctionne de mani\u00e8re hi\u00e9rarchique : Stratum-1 prend le temps de GPS\/DCF\/PTP, Stratum-2 r\u00e9f\u00e9rence Stratum-1, etc. Je pr\u00e9vois au moins trois sources ind\u00e9pendantes, afin d'\u00e9viter que des pannes isol\u00e9es ou des pairs erron\u00e9s ne dominent. Le port UDP 123 doit \u00eatre accessible de mani\u00e8re fiable ; les filtres de paquets avec des drops al\u00e9atoires faussent les offsets. Ajuster finement les intervalles de polling aide \u00e0 permettre des corrections rapides sans inonder le r\u00e9seau. Les cartes r\u00e9seau modernes avec horodatage mat\u00e9riel r\u00e9duisent la gigue et diminuent le temps de latence. D\u00e9calage<\/strong> perceptible.<\/p>\n\n
PTP et temps de haute pr\u00e9cision dans le centre de donn\u00e9es<\/h2>\n\n
Lorsque les microsecondes comptent, le NTP seul ne suffit souvent pas. PTP (protocole de temps de pr\u00e9cision)<\/strong> synchronise les h\u00f4tes via des horloges boundary et transparentes dans les commutateurs jusqu'\u00e0 la microseconde. J'utilise le PTP l\u00e0 o\u00f9 les flux commerciaux, les syst\u00e8mes de mesure ou l'automatisation industrielle exigent un temps pr\u00e9cis. En pratique, cela signifie : planifier une infrastructure r\u00e9seau compatible avec PTP, d\u00e9finir les VLAN et la QoS de mani\u00e8re \u00e0 minimiser les chemins asym\u00e9triques et, sur les h\u00f4tes, coupler le PHC de la NIC (ptp4l\/phc2sys) avec l'horloge syst\u00e8me. Chrony compl\u00e8te bien du c\u00f4t\u00e9 NTP, PTP se charge du calibrage fin. Ce qui est important, c'est une s\u00e9lection claire du ma\u00eetre<\/strong> (Grandmaster avec GPS\/PPS) et surveillance de la r\u00e9partition de l'offset par segment, sinon on fait la chasse \u00e0 la d\u00e9rive fant\u00f4me, qui est en fait l'asym\u00e9trie du r\u00e9seau.<\/p>\n\n
Containers et Kubernetes : ma\u00eetriser le temps dans le cluster<\/h2>\n\n
Les conteneurs utilisent l'horloge de l'h\u00f4te - on n\u201e\u201cinstalle\" pas de temps par pod. Je r\u00e8gle la souverainet\u00e9 temporelle sur les n\u0153uds<\/strong> s\u00e9curis\u00e9 (chronyd\/ntpd sur le worker), au lieu de lancer NTP dans des containers. Dans Kubernetes, je v\u00e9rifie que le n\u0153ud etcd, le plan de contr\u00f4le et le worker conservent le m\u00eame offset ; sinon, les s\u00e9lections de leaders (dur\u00e9es de raft\/lease) basculent et les rotations de certificats bloquent. Un DaemonSet privil\u00e9gi\u00e9<\/strong> pour NTP est rarement n\u00e9cessaire ; une image de n\u0153ud propre avec Chrony est plus stable. Pour les CronJobs dans le cluster, j'utilise UTC et je garde les startingDeadlineSeconds<\/em> de mani\u00e8re conservatrice, afin que les petits skews ne conduisent pas \u00e0 des fen\u00eatres manqu\u00e9es. Je calibre les pipelines de logs et de m\u00e9triques (Fluent Bit, Promtail, Node-Exporter) avec le temps de l'h\u00f4te et ne me fie pas aux horodatages des conteneurs.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/servertimedriftdesk8342.png\")
\n<\/figure>\n\n\nLes environnements de cloud computing : Sc\u00e9narios \"provider-time\" et hybrides<\/h2>\n\n
Dans le cloud, j'utilise de pr\u00e9f\u00e9rence les Services du fournisseur<\/strong>, car les temps de latence sont courts et les sources redondantes. AWS fournit une source interne sur 169.254.169.123, GCP offre time.google.com<\/em> avec le smearing Leap, dans Azure, le Host-Timesync et les NTP-Peers classiques fonctionnent de mani\u00e8re fiable. Important : les groupes de s\u00e9curit\u00e9\/NSG doivent autoriser UDP 123, et les DC dans le cloud continuent \u00e0 suivre le principe de l'\u00e9mulateur PDC. Dans les configurations hybrides, je pr\u00e9vois des hubs horaires r\u00e9gionaux (par exemple un relais NTP par VNet\/VPC) et j'\u00e9vite que les DC locaux ne \u201ebasculent\u201c soudainement vers une source cloud \u00e9loign\u00e9e. Pour les sc\u00e9narios DR, je connecte les syst\u00e8mes en attente aux m\u00eames pairs afin qu'un basculement n'entra\u00eene pas de d\u00e9calage temporel.<\/p>\n\n
Conception d'applications : horloges monotones, jetons et tra\u00e7age<\/h2>\n\n
De nombreux dommages dus \u00e0 la d\u00e9rive sont Erreur de conception<\/strong>. Pour les temps d'ex\u00e9cution, les timeouts et les retries, j'utilise syst\u00e9matiquement des horloges monotones (par ex. Stopwatch, System.nanoTime, time.monotonic), pas le temps syst\u00e8me. J'enregistre les horodatages en UTC et je n'enregistre le timezone que pour la repr\u00e9sentation. Les syst\u00e8mes bas\u00e9s sur des jetons (JWT, OAuth2, SAML) ont besoin d'un petit clock skew<\/em> (2-5 minutes) pour exp\/nbf<\/em>, Sinon, les utilisateurs sont expuls\u00e9s en cas de l\u00e9ger d\u00e9calage. TLS 1.3 et les tickets de session \u00e9valuent l'\u00e2ge des tickets, les CRL et la validit\u00e9 OCSP en fonction de l'horloge - la d\u00e9rive d\u00e9clenche des ren\u00e9gociations inutiles. Sur Tra\u00e7age distribu\u00e9<\/strong> synchroniser le sampler, l'ingest gateway et le worker par rapport \u00e0 la m\u00eame source, sinon les spans donnent des dur\u00e9es n\u00e9gatives. Pour les m\u00e9triques, je m'en tiens aux timestamps c\u00f4t\u00e9 serveur et j'\u00e9vite que les agents ne \u201ecorrigent\u201c c\u00f4t\u00e9 client.<\/p>\n\n
Strat\u00e9gies de correction : slew vs step, leap seconds et DST<\/h2>\n\n
Qu'une montre slewt<\/strong> (s'adapte lentement) ou fait des claquettes<\/strong> (saute), d\u00e9cide des effets secondaires. Chrony corrige beaucoup par slew et peut, \u00e0 partir d'un seuil d\u00e9fini (makestep<\/em>) une seule fois. Je planifie des \u00e9tapes difficiles dans les fen\u00eatres de maintenance, j'arr\u00eate bri\u00e8vement les charges de travail sensibles au temps (par ex. bases de donn\u00e9es, agents de messages) et je fais ensuite rattraper la r\u00e9plication et les caches. Sous Windows, je limite les grandes corrections par les valeurs maximales et je resynchronise avec w32tm \/resync \/rediscover<\/em>, Au lieu de multiples mini-\u00e9tapes. Leap Seconds<\/strong>J'opte tr\u00e8s t\u00f4t pour le smearing ou l'insertion classique. Le m\u00e9lange est dangereux - ceux qui font du smear devraient le faire partout. DST<\/strong> concerne UTC<\/em> pas ; je g\u00e8re les serveurs en UTC et r\u00e8gle la pr\u00e9sentation dans l'application. Je calibre et teste consciemment les programmateurs autour des changements d'heure.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/serverzeit-drift-9347.png\")
\n<\/figure>\n\n\nLe runbook : De la perturbation au temps stable<\/h2>\n\n
Lorsque Drift lance des alertes, je travaille un court Runbook<\/strong> \u00e0 partir de : (1) Confirmer les offsets sur l'h\u00f4te de r\u00e9f\u00e9rence. (2) V\u00e9rifier si des synchronisations doubles sont actives (synchronisation hyperviseur, agents cloud, NTP\/Chrony en parall\u00e8le). (3) Regarder la qualit\u00e9 des sources (reach, jitter, stratum). (4) V\u00e9rifier les chemins du r\u00e9seau : UDP 123, routes asym\u00e9triques, perte de paquets. (5) En cas d'offsets importants, cibler makestep<\/em> ou d\u00e9clencher la resynchronisation w32tm et \u201edrainer\u201c bri\u00e8vement les services critiques au pr\u00e9alable. (6) V\u00e9rifier le r\u00f4le DC\/PDC et consigner l'\u00e9tat de w32time. (7) Surveiller la post-stabilisation : tendance \u00e0 l'offset, changement de source, discipline du noyau. (8) Post-mortem : documenter la cause racine (gel de la sauvegarde ? d\u00e9rive de l'h\u00f4te ? mauvais pairs ?) et durcir la configuration (intervalles de poll, plus de pairs, adapter les services d'int\u00e9gration). Cette proc\u00e9dure permet d'\u00e9viter d'aggraver la situation avec des \u00e9tapes ad hoc.<\/p>\n\n
R\u00e9seau et appliances : des amplificateurs de d\u00e9rive invisibles<\/h2>\n\n
Je vois souvent des pare-feux et des \u00e9quilibreurs de charge Trafic NTP<\/strong> affecter de mani\u00e8re non intentionnelle : Les fonctions ALG, les limites de d\u00e9bit ou le routage asym\u00e9trique faussent les offsets. Les passerelles NAT avec un temps d'\u00e9tat UDP court d\u00e9truisent les conversations NTP. Mon antidote : des politiques de sortie d\u00e9di\u00e9es pour UDP 123, pas de proxy obligatoire, et des relais NTP locaux proches des charges de travail. Sur les liaisons WAN, je pr\u00e9vois des pairs r\u00e9gionaux plut\u00f4t que centraux, afin que la gigue fluctue, mais que les D\u00e9rive<\/em> reste petite. Pour le PTP, la QoS est obligatoire - sans paquets prioritaires et sans commutateurs transparents, on n'atteint pas la pr\u00e9cision vis\u00e9e.<\/p>\n\n
Mauvaises configurations fr\u00e9quentes que je trouve toujours<\/h2>\n\n
- \n
- Un seul pair<\/strong> dans la configuration : s'il tombe en panne ou signale des absurdit\u00e9s, l'ensemble du domaine suit.<\/li>\n
- Synchronisation h\u00f4te et invit\u00e9 en parall\u00e8le<\/strong>: Hyperviseur corrig\u00e9, NTP corrig\u00e9 - des sauts et des oscillations apparaissent.<\/li>\n
- Gel des sauvegardes sans crochet thaw<\/strong>: les VM se \u201er\u00e9veillent\u201c avec une vieille horloge ; il manque un forcestep en aval.<\/li>\n
- Mauvais \u00e9mulateur PDC<\/strong> apr\u00e8s des d\u00e9placements FSMO : Les clients demandent \u00e0 l'ancien DC, les tickets \u00e9chouent.<\/li>\n
- Intervalles de polling inadapt\u00e9s<\/strong>Trop long pour les r\u00e9seaux volatiles, trop court pour les pairs \u00e9loign\u00e9s - les deux augmentent la gigue.<\/li>\n
- M\u00e9lange de fuseaux horaires<\/strong> sur les serveurs : UTC m\u00e9lang\u00e9 \u00e0 des zones locales entra\u00eene des logs illisibles et des erreurs Cron.<\/li>\n<\/ul>\n\n
SLA, risques et budget : combien co\u00fbte la d\u00e9rive ?<\/h2>\n\n
Planification budg\u00e9taire<\/strong> a besoin de chiffres solides : M\u00eame de petits \u00e9carts entra\u00eenent des tickets d'assistance, des temps d'arr\u00eat ou des erreurs de donn\u00e9es. Je calcule les co\u00fbts de mani\u00e8re conservatrice par le biais des minutes d'arr\u00eat, des d\u00e9penses li\u00e9es aux incidents et des dommages cons\u00e9cutifs aux audits. Le tableau suivant r\u00e9sume des sc\u00e9narios typiques et aide \u00e0 fixer des priorit\u00e9s. Il convient bien aux d\u00e9cisions de gestion et aux demandes de changement. Les chiffres varient en fonction de la taille, mais montrent l'ordre de grandeur dans lequel D\u00e9rive<\/strong> co\u00fbte cher.<\/p>\n\n
\n \n
\n \nSc\u00e9nario<\/th>\n D\u00e9rive typique<\/th>\n impact<\/th>\n Risque pour les co\u00fbts (\u20ac)<\/th>\n <\/tr>\n <\/thead>\n \n AD\/Kerberos \u00e9choue<\/td>\n 3-5 minutes<\/td>\n Erreurs de connexion, bourrage de r\u00e9plication<\/td>\n 1.000-10.000 par incident<\/td>\n <\/tr>\n \n Sauvegarde de VM avec freeze<\/td>\n 10-240 minutes<\/td>\n Les jobs sont antidat\u00e9s, les lots sont interrompus<\/td>\n 2.000-15.000 y compris la r\u00e9cup\u00e9ration<\/td>\n <\/tr>\n \n N\u0153ud de mesure diff\u00e9rent<\/td>\n 50-500 ms<\/td>\n Fausses alertes, infractions SLO<\/td>\n 500-5.000 en p\u00e9riode de support<\/td>\n <\/tr>\n \n \u00c9chec de l'audit\/de l'expertise<\/td>\n secondes-minutes<\/td>\n Logs inutilisables, risque de non-conformit\u00e9<\/td>\n 5.000-50.000 en cas de retouches<\/td>\n <\/tr>\n <\/tbody>\n<\/table>\n\n Cas d'utilisation : N\u00e9goce financier, e-commerce, logging<\/h2>\n\n
Syst\u00e8mes financiers<\/strong> ont besoin de s\u00e9quences coh\u00e9rentes, sinon les algorithmes perdent de leur pertinence et les transactions sont mal \u00e9valu\u00e9es. Dans le commerce \u00e9lectronique, les erreurs de temps se r\u00e9percutent sur les expirations de session, les fen\u00eatres de r\u00e9duction et les flux de commande. J'y contr\u00f4le \u00e9troitement les d\u00e9calages de toutes les passerelles, des syst\u00e8mes de paiement et d'\u00e9v\u00e9nements. Dans les piles centrales de logging, une source d\u00e9rivante entra\u00eene des sauts qui rendent les tableaux de bord illisibles et retardent les analyses d'incidents. En observant ces cha\u00eenes, on se rend vite compte \u00e0 quel point D\u00e9rive du temps du serveur<\/strong> des effets sont cr\u00e9\u00e9s \u00e0 travers la plateforme.<\/p>\n\n
Temps et cronjobs : stopper les erreurs de planification \u00e0 un stade pr\u00e9coce<\/h2>\n\n
Cron<\/strong> et les planificateurs de t\u00e2ches sont sensibles aux sauts temporels, par exemple lors du gel de l'hyperviseur ou de la double synchronisation. Les fen\u00eatres de t\u00e2ches entrent en conflit, les r\u00e9p\u00e9titions se d\u00e9clenchent trop t\u00f4t ou trop tard, et les limiteurs de temps de latence s'\u00e9chauffent. Je v\u00e9rifie donc les fuseaux horaires, les d\u00e9calages et les changements d'heure d'\u00e9t\u00e9 dans l'orchestration. Pour les planifications Linux, j'\u00e9vite les d\u00e9pendances de l'horloge locale en v\u00e9rifiant le statut NTP avant le d\u00e9but du travail. Ce guide r\u00e9sume de mani\u00e8re compacte de nombreuses pierres d'achoppement : Fuseau horaire Cron<\/a>, Je l'utilise comme liste de contr\u00f4le avant de d\u00e9marrer.<\/p>\n\n
Surveillance et alerte : d\u00e9finir des seuils de mani\u00e8re judicieuse<\/h2>\n\n
Alarmes<\/strong> doivent faire la diff\u00e9rence entre la gigue et la vraie d\u00e9rive. Je d\u00e9finis des avertissements \u00e0 partir de 100 ms et des critiques \u00e0 partir de 500 ms, en fonction des exigences de latence. Je pr\u00e9l\u00e8ve des n\u0153uds de mesure dans diff\u00e9rents sous-r\u00e9seaux afin que les chemins de r\u00e9seau ne faussent pas les r\u00e9sultats de mani\u00e8re unilat\u00e9rale. Les tableaux de bord m'indiquent les d\u00e9calages par h\u00f4te, la ligne de tendance et la derni\u00e8re source utilis\u00e9e. En outre, j'enregistre les changements de source afin de pouvoir Causes<\/strong> lors de sauts.<\/p>\n\n
WordPress et les t\u00e2ches planifi\u00e9es : WP-Cron sous contr\u00f4le<\/h2>\n\n
- Synchronisation h\u00f4te et invit\u00e9 en parall\u00e8le<\/strong>: Hyperviseur corrig\u00e9, NTP corrig\u00e9 - des sauts et des oscillations apparaissent.<\/li>\n
- Suivre<\/strong>: erreurs Kerberos, jobs retard\u00e9s, logs contradictoires, fausses alertes<\/li>\n