Ba chiếc đồng hồ trong một nhật ký VPN: máy khách, cổng, bộ thu thập

Dòng thời gian của một sự cố VPN thường bắt đầu bằng hai dấu thời gian lệch nhau vài phút và một màn hình hiển thị giờ khác. Cám dỗ là chọn một cái là đúng và viết lại cái kia. Cả hai đều có thể đúng, vì những đồng hồ khác nhau đã ghi chúng về những sự kiện khác nhau. Lầm tưởng là VPN chỉ có một chiếc đồng hồ; công việc là tìm ra thành phần nào đã ghi từng trường.

Lầm tưởng: VPN chỉ có một chiếc đồng hồ

Máy khách ghi một sự kiện khi nó thử kết nối. Cổng ghi một sự kiện khi nó nhận hoặc chấp nhận lần thử đó. Bộ thu thập ghi thời điểm đến khi nó nhận thông điệp của cổng. Đó là ba sự kiện, và mỗi sự kiện được đóng dấu bằng chiếc đồng hồ mà thành phần ghi tin tưởng. Ép chúng vào một dòng thời gian duy nhất là một sự tiện lợi che giấu sự không khớp mà bạn đang cố giải thích.

Các con số thường lệch từ vài giây đến vài phút, và điều đó là bình thường. Điều quan trọng là sự khác biệt đó là độ trễ phân phối, độ lệch đồng hồ hay một sự kiện thực sự khác. Để quyết định bạn đang nhìn cái nào cần nguồn gốc của từng trường, không phải một ý kiến mạnh hơn về việc máy nào đúng.

Đọc nguồn gốc trước giá trị

Trước khi so sánh các giá trị, hãy xác định ai đã tạo ra từng cái và đó là trường nào. Thông điệp syslog mang một dấu thời gian từ nguồn gốc, như RFC 5424 mô tả, và định dạng cũng có thể mang thông tin chất lượng thời gian mô tả đồng bộ hóa và độ chính xác. Cùng định dạng đó cho phép nguồn gốc không gửi dấu thời gian nào khi nó không đọc được giờ hệ thống, và điều đó tự nó là một tín hiệu hữu ích.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

Máy khách cũng có thể gửi một giá trị thời gian như siêu dữ liệu ứng dụng, và dịch vụ lưu trữ nó nên gắn nhãn là do máy khách báo cáo thay vì coi đó là đã được xác minh độc lập. Nhãn đó là sự khác biệt giữa bằng chứng và tuyên bố. Khi xuất nhật ký cho một vụ việc, hãy giữ tên trường, nguồn gốc và độ lệch cùng nhau. Rút gọn chúng thành giờ địa phương tiện dụng sẽ phá hủy đúng thông tin bạn cần.

Hãy dừng lại nếu bạn không thể nói thành phần nào đã ghi một trường. So sánh nó với bất cứ thứ gì khác là đoán.

Hiển thị múi giờ không phải một thời điểm khác

Cùng một thời điểm hiển thị là 10:00Z và là 18:00+08:00 không phải là mâu thuẫn, và coi đó là mâu thuẫn sẽ mất nửa ngày. Chuyển cả hai sang UTC trước khi so sánh, và giữ văn bản gốc bên cạnh phần chuyển đổi. Một bên là phân số thập phân và bên kia là giây nguyên cũng không phải xung đột. Độ chính xác không phải là tính đúng đắn: một giá trị có mili giây vẫn có thể đến từ chiếc đồng hồ sai vài phút.

date -u +%FT%TZ
timedatectl

Độ trễ phân phối là lời giải thích thông thường khác. Cổng ghi lại khi nó chấp nhận kết nối, và bộ thu thập ghi lại khi thông điệp đến nó, nên khoảng cách giữa hai bên là thời gian vận chuyển. Khoảng cách đó nói điều gì đó về đường ống nhật ký, không phải về phiên VPN. Gắn nhãn đó là thời điểm đến và nó không còn cạnh tranh với thời điểm sự kiện.

Tương quan mà không viết lại bằng chứng

Giữ nguyên các dấu thời gian gốc và thêm một cột dẫn xuất nếu bạn cần góc nhìn chung. Giải thích việc chuyển đổi trong ghi chú thay vì sửa các bản ghi nguồn, vì nguồn là thứ mà người đánh giá sau này sẽ kiểm tra. Bảo tồn thời điểm đến của bộ thu thập riêng ở bất cứ đâu nó tồn tại.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Thay đổi đồng hồ của thiết bị không phải là kiểm soát quyền riêng tư và không viết lại các bản ghi mà hệ thống khác đã giữ. Nó cũng làm cho việc so sánh bằng chứng hỗ trợ khó hơn, và có thể phá vỡ các kiểm tra chứng chỉ và mã phụ thuộc vào thời gian. Giữ đồng hồ được đồng bộ cho hoạt động bình thường, và coi mọi độ lệch cố ý là lỗi cần điều tra. Nếu hai bản ghi có vẻ không đúng thứ tự, hãy xem đồng bộ đồng hồ và phân phối trước khi dựng nên một lịch sử mới.

Lầm tưởng cần bỏ đi là chỉ có một thời gian VPN. Hỏi điều gì đã ghi từng trường và điều gì đã xảy ra khi nó làm vậy, và dòng thời gian trở thành một tập hợp các quan sát có nhãn thay vì một mâu thuẫn.