زمانهای Unix در فایلهای گزارش — چگونه آنها را بخوانیم و اشکالزدایی کنیم
زمانی که چیزی در محیط تولید ساعت ۲ شب خراب شود، اولین کار شما مراجعه به گزارشها است. و اغلب اولین مانع دیواری از مهرزمانهای Unix است — اعداد صحیح ۱۰ رقمی که به دقت نشان میدهند هر رویداد چه زمانی رخ داده، اگر فقط بتوانستید آنها را بخوانید. 1744070400 دقیق، بدون ابهام، و کاملاً نامفهوم است تا زمانی که آن را تبدیل کنید.
مبدل مهرزمان Unix هر مهرزمان خام را فوری به تاریخ و ساعت قابلفهم تبدیل میکند. این مقاله نحوه ظهور مهرزمانها در گزارشها، نحوه تبدیل و هماهنگسازی آنها بهطور کارآمد، و جایی که اشکالات مرتبط با مهرزمان در اشکالزدایی پنهان میشود را پوشش میدهد.
چرا گزارشها از مهرزمانهای Unix استفاده میکنند
رشتههای تاریخ قابلفهم برای انسان — «۷ آوریل ۲۰۲۶ ساعت ۱۴:۳۲:۰۵ UTC+۲» — برای خواندن راحت هستند اما برای ماشینها بسیار بد. آنها بر حسب زبان و منطقه متفاوت هستند، نیاز به تجزیه منطقه زمانی دارند، نمیتوانند بهطور مستقیم بهعنوان اعداد صحیح مقایسه شوند، و فضای بیشتری نسبت به یک عدد ساده اشغال میکنند.
مهرزمانهای Unix تمام این مشکلات را حل میکنند. مهرزمانی مانند 1744070400:
- بدون ابهام — بدون زبان، بدون تغییر قالب
- خنثی نسبت به منطقه زمانی — همیشه بر پایه UTC
- قابل مرتبسازی — عدد بزرگتر = زمان دیرتر، پس
ORDER BY timestampبهدرستی کار میکند - دوستدار عملیات حسابی — دو مهرزمان را از هم کم کنید تا ثانیههای سپریشده را بدست آورید
بیشتر سیستمهای گزارشدهی (syslog، گزارشهای برنامه، گزارشهای پایگاه داده، گزارشهای دسترسی CDN) به همین دلایل به مهرزمانهای UTC Unix متکی هستند. هزینه خوانایی برای دقت و قابلیت انتقال معاوضه میشود.
نحوه تبدیل مهرزمان گزارش
سریعترین روش این است که مهرزمان را در مبدل مهرزمان Unix وارد کنید. آن بهطور خودکار ثانیه را مقابل میلیثانیه تشخیص میدهد و تاریخ و ساعت UTC را فوری نشان میدهد.
برای تبدیلهای سریع بدون خروج از ترمینال:
Linux/Mac (bash): `bash date -d @1744070400 # Linux date -r 1744070400 # macOS `
Python: `python import datetime datetime.datetime.fromtimestamp(1744070400, tz=datetime.timezone.utc)
datetime(2026, 4, 7, 16, 0, tzinfo=timezone.utc)
**JavaScript (کنسول مرورگر یا Node):**new Date(1744070400 * 1000).toISOString() // "2026-04-07T16:00:00.000Z" `
توجه کنید به * 1000 در JavaScript — Date بر حسب میلیثانیه کار میکند، بنابراین مهرزمانی بر حسب ثانیه باید قبل از انتقال به new Date() در ۱۰۰۰ ضرب شود. فراموش کردن این مورد یکی از منابع عام اشکالات «مهرزمان در سال ۲۵۲۷» است.
خواندن مهرزمانهای میلیثانیه در گزارشها
برخی سیستمها بهجای ثانیه به میلیثانیه گزارش میدهند. برنامههای Node.js، سیستمهای Java با استفاده از System.currentTimeMillis()، و بسیاری از بکاندهای مبتنی بر JavaScript مهرزمانهای ۱۳ رقمی مانند 1744070400000 تولید میکنند.
مبدل مهرزمان Unix قالب را بهطور خودکار بر اساس تعداد رقمها تشخیص میدهد. اما در ترمینال:
# ابتدا میلیثانیه را به ثانیه تبدیل کنید
echo $((1744070400000 / 1000)) | xargs date -d @ # Linuxیا در Python: `python datetime.datetime.fromtimestamp(1744070400000 / 1000, tz=datetime.timezone.utc) `
یک کنترل سریع: اگر مهرزمان ۱۳ رقم است، تقریباً مطمئناً میلیثانیه است. ۱۰ رقم به معنی ثانیه است. ۱۶ رقم به معنی میکروثانیه است (رایج در PostgreSQL). ۱۹ رقم به معنی نانوثانیه است (برخی سیستمهای Java و Rust).
هماهنگسازی مهرزمانها در بین منابع گزارش متعدد
یکی از سختترین بخشهای اشکالزدایی سیستمهای توزیعشده هماهنگسازی رویدادها در بین سرویسهای متعددی است که بهطور مستقل گزارش میدهند. اگر گزارش وبسرور شما خطای ۵۰۰ را در مهرزمان 1744070412 نشان دهد و گزارش پایگاه داده شما حداکثر مهلت اتصال را در 1744070410 نشان دهد، این دو رویداد ۲ ثانیه از هم فاصله دارند — به وضوح مرتبط هستند.
بدون مهرزمانهای Unix، این هماهنگسازی دردناک است. اگر وبسرور در UTC+۲ و پایگاه داده در UTC-۵ گزارش دهد، تراز دستی کردن اوقات نیاز به دانستن تفاضل و انجام حسابات ذهنی دارد. با مهرزمانهای Unix، هر دو گزارش در مقیاس یکسان هستند و شما میتوانید مستقیم کم کنید.
گردشکار عملی: 1. از گزارشهای کاربر یا هشدارهای نظارتی، دامنه زمانی تقریبی حادثه را شناسایی کنید 2. دامنه زمانی را به مهرزمانهای Unix تبدیل کنید (مبدل مهرزمان Unix یا date -d "2026-04-07 16:00:00 UTC" +%s) 3. هر فایل گزارش را به آن دامنه مهرزمان فیلتر کنید: awk '$1 >= 1744070400 && $1 <= 1744070460' access.log 4. خروجی ترکیبی را بر اساس مهرزمان مرتب کنید تا یک خط زمانی یکپارچه ایجاد شود
مرحله ۴ جایی است که مهرزمانهای Unix واقعاً جای خود را ثابت میکنند — شما میتوانید sort -n را بر روی ستون مهرزمان در بین فایلهای سیستمهای مختلف اجرا کنید و یک نمایش ادغامشده منطقی زمانی بدست آورید.
اشکالات مهرزمان عام برای جستجو در اشکالزدایی
عدم تطابق ثانیه/میلیثانیه. مهرزمانی که بهصورت میلیثانیه ذخیرهشده اما بهعنوان ثانیه خواندهشود تاریخی در سال ۲۵۲۷ یا نزدیکتر تولید میکند. مهرزمانی که بهصورت ثانیه ذخیرهشده اما بیدلیل در ۱۰۰۰ ضرب شود تاریخی در سال ۱۹۷۰ تولید میکند. هر دو وقتی که مقدار را تبدیل میکنید واضح هستند، به همین دلیل تبدیل کردن در ابتدای اشکالزدایی ارزشمند است.
زمان محلی بهجای UTC. اگر گزارش 1744077600 را نشان دهد و شما 1744070400 را برای همان رویداد انتظار داشتید، تفاضل ۷۲۰۰ ثانیه است — دقیقاً ۲ ساعت. این یک تفاضل منطقه زمانی است. برخی سیستمها بهجای UTC در زمان محلی گزارش میدهند، که هماهنگسازی سیستمهای متقاطع را خراب میکند. همیشه قبل از هماهنگسازی، تأیید کنید که یک سیستم گزارش از کدام منطقه زمانی استفاده میکند.
نوسان ساعت بین سرورها. سیستمهای توزیعشده با ساعتهای ناهماهنگ گزارشهایی تولید میکنند که مهرزمانها ترتیب واقعی رویدادها را منعکس نمیکنند. اگر سرور A رویدادی را در 1744070400 و سرور B رویدادی که علیالسبب بعدی است را در 1744070398 نشان دهد، ساعت سرور B ۲ ثانیه عقبتر است. همگامسازی NTP این را جلوگیری میکند، اما همیشه بهدرستی حفظ نمیشود. هنگام اشکالزدایی شرایط مسابقه یا مسائل علیت در سیستمهای توزیعشده، بررسی نوسان ساعت ارزشمند است.
Epoch بهعنوان رشته ذخیرهشده. برخی سیستمها مهرزمانها را بهعنوان نمایش رشتهای صحیح گزارش میدهند: "1744070400". این در بسیاری از نمایشهای گزارش یکسان بهنظر میرسد اما اگر بهدرستی تجزیه نشود میتواند باعث شکست در مرتبسازی یا مقایسه شود. گزارشهای JSON بهطور خاص بعضی اوقات اعداد را بهعنوان رشتهها سریال میکنند.
مهرزمانهای برشخورده. ورودی گزارشی که 174407040 (۹ رقم) را نشان میدهد بهجای 1744070400 (۱۰ رقم) برشخورده است — احتمالاً یک اشکال قالببندی یا overflow بافر. مقدار ۹ رقم به سپتامبر ۲۰۲۵ بهجای آوریل ۲۰۲۶ تبدیل میشود.
فیلتر کردن گزارشها بر اساس دامنه زمانی با مهرزمانهای Unix
دانستن دامنه مهرزمان برای یک پنجره زمانی فیلتر کردن گزارش را دقیق میکند:
# مهرزمان Unix را برای یک زمان خاص UTC بدست آورید
date -d "2026-04-07 16:00:00 UTC" +%s # → 1744070400
date -d "2026-04-07 16:05:00 UTC" +%s # → 1744070700
# فیلتر کردن گزارش دسترسی nginx (فیلد اول مهرزمان است)
awk '$1 >= 1744070400 && $1 <= 1744070700' /var/log/nginx/access.log
# فیلتر کردن با grep اگر مهرزمان در موقعیت شناختهشدهای است
grep -E "^174407(04|05|06|07)" /var/log/app.logبرای گزارشهای JSON، jq خوانایی بیشتری دارد: `bash cat app.log | jq 'select(.timestamp >= 1744070400 and .timestamp <= 1744070700)' `
ابزار روزهای بین تاریخها زمانی مفید است که نیاز به دانستن دامنه مهرزمان برای یک روز کامل یا دوره چند روزه دارید — تاریخهای شروع و پایان را به مهرزمان تبدیل کنید و آنها را بهعنوان حدود فیلتر استفاده کنید.
ایجاد یک مدل ذهنی برای بزرگیهای مهرزمان
بعد از اشکالزدایی چند حادثه با مهرزمانهای Unix، شروع به توسعه شهود برای بزرگیها میکنید. تا سال ۲۰۲۶:
- مهرزمانهای فعلی در دامنه ۱.۷۴–۱.۷۵ میلیارد هستند
- یک ساعت = ۳٬۶۰۰ ثانیه (۴ رقم)
- یک روز = ۸۶٬۴۰۰ ثانیه (۵ رقم)
- یک هفته = ۶۰۴٬۸۰۰ ثانیه (۶ رقم)
- یک سال ≈ ۳۱٬۵۵۷٬۶۰۰ ثانیه (۸ رقم)
بنابراین اگر دو ورودی گزارش ۸۶ ثانیه تفاوت داشته باشند، حدود ۱.۵ دقیقه از هم فاصله دارند. اگر ۳٬۶۰۰ تفاوت داشته باشند، دقیقاً یک ساعت. اگر ۶۰۴٬۸۰۰ تفاوت داشته باشند، دقیقاً یک هفته. این اعداد گرد شناختشده ارزش یادگیری دارند — آنها حسابات ذهنی بر روی مهرزمانها را در طول یک حادثه فعلی بسیار سریعتر میکنند.
برای هر تبدیلی که در ذهن شما نیست، مبدل مهرزمان Unix سریعترین مسیر از صحیح خام به تاریخ و ساعت قابلفهم و برعکس است.
