W systemie rozproszonym nie ma jednego oczywistego „teraz”
Każdy komputer ma własny zegar, a zegary nie są idealne. Różnią się ustawieniem, dryfują i są okresowo korygowane. Jednocześnie wiadomości między maszynami potrzebują czasu na dotarcie. Dlatego spojrzenie na dwa znaczniki czasu nie zawsze wystarcza, aby bezpiecznie stwierdzić, które zdarzenie w systemie naprawdę było pierwsze. Leslie Lamport zwrócił uwagę, że w systemie rozproszonym bardziej fundamentalna od jednej globalnej osi czasu jest relacja przyczynowa: wysłanie wiadomości musi poprzedzać jej odebranie, ale dwa niezależne zdarzenia mogą nie mieć naturalnego porządku. To zmienia sposób myślenia o logach, transakcjach i debugowaniu.
Zegar procesora nie jest zegarem całego świata
Maszyna A może uważać, że jest 12:00:00.100, a maszyna B — że 12:00:00.097. Różnica może być mała, ale jeżeli próbujemy uporządkować dwa niemal równoczesne zdarzenia, właśnie te milisekundy stają się krytyczne. Synchronizacja czasu zmniejsza błąd, lecz nie tworzy magicznego zegara dostępnego bez opóźnienia wszystkim komputerom.
Sieć dodatkowo zaciera kolejność
Nawet gdy zegary są podobne, pakiety pokonują fizyczną drogę i mogą być kolejkowane. Zdarzenie na serwerze A może spowodować wysłanie wiadomości do B, ale log B może mieć lokalny znacznik czasu, który wygląda wcześniejszy. Jeśli analityk posortuje później wszystkie logi wyłącznie po fizycznym czasie, może uzyskać historię sprzeczną z rzeczywistą przyczynowością.
Lamport zaproponował inne pytanie
W słynnym artykule z 1978 r. Lamport zdefiniował relację „happened before”. Jeśli dwa zdarzenia występują w jednym procesie po kolei, znamy ich porządek. Jeśli jedno jest wysłaniem wiadomości, a drugie jej odbiorem, wysłanie musiało nastąpić wcześniej. Relację można też rozszerzać przechodnio. To pozwala mówić o przyczynowości bez udawania, że znamy idealny czas fizyczny.
Nie wszystko trzeba porządkować
Jeżeli zdarzenie X nie mogło wpłynąć na Y i Y nie mogło wpłynąć na X, mogą być współbieżne z punktu widzenia modelu. Próba wymuszenia jednej „prawdziwej” kolejności bywa wtedy sztuczna. Można oczywiście utworzyć porządek techniczny dla potrzeb algorytmu, ale nie należy mylić go z informacją o realnym związku przyczynowym.
To dlatego debugowanie wielu serwerów bywa tak zdradliwe
Administrator widzi logi z dziesiątek maszyn i chce zrekonstruować jedną historię. Fizyczne timestampy są niezwykle przydatne, lecz wymagają wiedzy o błędzie synchronizacji i opóźnieniach. W systemach rozproszonych „co było pierwsze?” jest czasem pytaniem z jednoznaczną odpowiedzią przyczynową, a czasem pytaniem, na które system po prostu nie posiada wystarczającej informacji.
Korekta zegara też może popsuć naiwne założenia
System operacyjny może synchronizować zegar z zewnętrznym źródłem i korygować dryf. Jeśli aplikacja zakłada, że czas ścienny zawsze rośnie idealnie monotonnie, korekta może wprowadzić zaskoczenia. Z tego powodu do mierzenia odstępów lokalnych używa się zegarów monotonicznych, a do porządkowania zdarzeń rozproszonych często dodatkowych mechanizmów logicznych. Jeden rodzaj „czasu” nie jest dobry do wszystkich zadań.
Logi wymagają korelacji, nie tylko sortowania
W observability praktycznym rozwiązaniem są identyfikatory trace'ów, spanów i requestów. Pozwalają połączyć zdarzenia przyczynowo nawet wtedy, gdy timestampy z różnych maszyn są lekko przesunięte. Dzięki temu można powiedzieć, że wywołanie B było odpowiedzią na A, zamiast wnioskować wyłącznie z kolejności godzin. Nowoczesne tracingi są więc praktycznym rozwinięciem tej samej intuicji: relacja między zdarzeniami jest często cenniejsza niż pozorna precyzja zegara.
Problemy z czasem dotyczą również wygasania lease'ów, tokenów i blokad. Jeśli serwer uzna, że jego prawo do zasobu jest ważne do określonej chwili, musi wiedzieć, jak duży błąd zegara jest dopuszczalny. Zbyt optymistyczne założenie może sprawić, że dwa węzły jednocześnie uznają swoje lease'y za ważne. Dlatego mechanizmy oparte na czasie często łączą synchronizację zegarów z marginesami bezpieczeństwa, numerami epok albo potwierdzeniami quorum.