برچسب: مدیر سیستم

من همه امروز رو مشغول ترابل شوتینگ مشکل ۴ تا سرور بودم و هنوزم حل نشده. برای حل مشکلات کامپیوتری استراتژی های مختلفی هست ولی در واقع خلاصه اشون اینه که کافیه منظم فکر کنین، شواهد رو کنار هم بچنین و اگر گزاره های کافی داشته باشین مشکل دیده می شه. اگر بتونین مشکل رو تکرار کنین احتمال پیدا کردنش بسیار بیشتره و اگر گزاره های بیشتر و بیشتری کنار هم بچینین احتمالا راه حل رو دارین.

به عبارت دیگه می گن «توضیح دقیق یک مشکل در دنیای کامپیوتر برابر است با حل اون مشکل». اما مشکل آماتورها موقع رفع خطا کجاست؟ هی حدس می زنن شاید مشکل فلان جا باشه و می رن سراغ حل اون مساله و بعد که مشکل حل نمی شه یه حدس دیگه می زنن و می رن اون رو حل کنن. شبیه تک تیراندازی که به جای هدفگیری دقیق و زدن یک تیر، دائما به اطراف شلیک می کنه به امید اینکه به هدف بزنه (: گاهی هم کار می کنه ولی روش صحیحی نیست.

حالا مشکل چی بوده؟

• بعضی ها یکهو نتونستن از اپ مشهورترین سایت شطرنج یعنی چس دات کام بازی کنن

مشکل چی می تونه باشه؟ این سایت مشتری های پولی داره و باید سریع مشکل رو حل کنه. در چند قدم اول این گزاره ها اضافه شدن:

• کسانی که مشکل دارن همه سعی میکنن بازی جدید شروع کنن
• کسانی که مشکل دارن همه روی دیوایس های آی او اس هستن

بعد از چند قدم دیگه این گزاره اضافه می شه:

• کسانی که مشکل دارن همه آیپدهای قدیمی دارن

هنوز حدس خیلی سخته. ولی دو گزاره مستقل از تحقیقات مستقیم که بدم احتمالا بعضی هاتون می تونین حدس بزنین مشکل چیه:

• آیپدهای قدیمی ۳۲ بیتی بودن
• برای شروع بازی، شماره سریال یونیک بازی به دستگاه ارسال می شه و توی هر حرکت استفاده می شه

بازم گزاره لازمه؟

• تعداد بازی های سایت به ۲ میلیارد و ۱۴۷ میلیون و ۴۳۸ هزار و ۶۴۷ بازی رسیده، یعنی ۲ به توان ۳۱ منفی یک

امیدوارم تا الان حدس زده باشین، متغیری که کد بازی رو نگه می داره در آیپد ۳۲ بیتی است و حالا شماره بازی بزرگتر از ظرفیت حافظه شده و برنامه به هم می ریزه. یک کد که برنامه نویس سالها قبل پیش بینی نکرده بودش و الان باعث ۴۸ ساعت اختلال و کلی ترابل شوتینگ شده تا بشه این گزاره ها رو کنار هم گذاشت.

موقع برنامه نویسی به آینده فکر کنین و از اون مهمتر موقع ترابل شوتینگ، بیخودی به اطراف تیر نزنین. موقع عیب یابی باید مشکل رو تشخیص بدین و دقیق تعریف کنین. اینطوری مشکل خود به خود حل می شه. در واقع مشکل این بود که «حالا که بازی ها از ۲ به توان ۳۱ گذشته، روی آیپدهایی که ۳۲ بیت دارن دیگه نمی تونیم بازی جدید بسازیم». برم ببینم فردا با این ذهنیت می تونم مشکل امروز اون ۴ تا سرور رو حل کنم یا نه.

قبلا هم توی رادیو گیک در این مورد حرف زدیم که راه انداختن سرویس با سعی و خطا معمولا اصلی ترین دلیل ایجاد مشکلات امنیتی است. وقتی ما نمی دونیم داریم چیکار می کنیم هی سیستم رو بازتر و بازتر می کنیم تا بالاخره اتفاق مورد نظر بیافته و بعد دیگه نمی دونیم حالا کجا رو باید ببندیم.

این اتفاقا مثل اینه که شما تلاش کرده باشین مجوز ورود یک فرد خاص رو به خونه تون بدین. چون دقیقا نمی دونین کدوم کلیدها رو باید براش بسازین، پنجره رو باز میذارین و بهش می گین بیاد تو. اون تست می کنه و نمی تونه. بعد در پارکینگ رو باز می کنین و بهش می گین بیاد تو، نمی تونه. بعد کلا قفل در رو می کنین و بهش می گین بیاد تو، اون نمی تونه چون پلاک خونه رو درست بهش نگفتین. بعد از اینکه چند بار دیگه سعی می کنین و اجزای دیگه خونه رو خراب می کنین، بالاخره می فهمین که مشکل اشتباه بودن پلاک بوده و این رو که هماهنگ می کنین اون با موفقیت می یاد تو و شما هم می گین «ایول.. پس درست شد!». و همه خونه بازه.

این اتفاق توی دنیای کامپیوتر هم بسیار مرسومه. وب سرور ما کار نمی کنه در نتیجه همه چیز ۷۷۷ می کنیم (قابل نوشتن و خوندن و اجرا توسط همه). بعد که بازم کار نمی کنه دسترسی ها رو عوض می کنیم و بعد یکهو یادمون می افته selinux باید خاموش بشه و اون رو خاموش می کنیم و درست می‌شه.

در شکل دیگه ای از این ایجاد مشکل که قبلا بسیار مرسوم بود و به تازگی بازم دائما دیده می شه، مدیر سیستم نیاز داره در مورد چیزی اطلاعات امنیتی دقیق داشته باشه ولی چون حوصله نداره این اطلاعات رو جمع کنه، به شکل تجربی برنامه ای رو نصب می کنه و همین که راه افتاد فکر می کنه مساله تموم شده. این مساله به راحتی می تونه شما رو با سیستم های کاملا دسترسی پذیر از کل جهان تنها بذاره. قبلا به مونگو دی بی نسخه های قبلتر اشاره کردم که اینستال دیفالتش بسیار ناامنه. حالا همین مساله به شدت با HDFS اتفاق افتاده.

در یک بررسی جدید نشون داده شده که حداقل ۴۴۸۷ مورد نصب دیفالت هدوپ قابل دسترسی در اینترنت وجود داره که بیشتر از ۵۰۰۰ ترابایت دیتا روشون ذخیره شده. از این تعداد ۱۹۰۰ تا در آمریکا و۱۴۲۶ تا در چین هستن. کشورهای بعدی آلمان و کره با ۱۲۹ و ۱۱۵ نصب قراردارن.

کل ماجرا تکراری است بر اینکه اگر نمی دونین دارین چیکار می کنین، اول یاد بگیرین یا از یک متخصص کمک بگیرین. نصب دیفالت گاهی می تونه بسیار خطرناک باشه و سعی و خطا کردن برای رسیدن به نتیجه مورد نظر، تقریبا همیشه همراه با تضعیف ایمنی سیستم است.

این اصطلاح «عالیه» یک جور متلک هم هست ولی خب خشن نیست. حداقل تو گفتار من. حالا هم گیت‌لب هنر خاصی زده و از چند ساعت قبل داون است. چرا؟ توییترشون می گه:

ظاهرا یک سیستم ادمین عزیز نیمه‌همکار ما زده دایرکتوری مهمی رو پاک کرده و با اینکه کل رپوزیتوری ها سرجاشون هستن، درخواست های پول ریکوئست و غیره پاک شدن. حداقل این برداشت من بوده. بک آپ ها که لحظه ای نیستن و ظاهرا اونها هم مشکل دارن.

حالا چرا عالیه؟ چون شفاف و معقول اینها رو گفته و چون یک داکیومنت آنلاین درست کرده که هر قدم تعمیراتی رو به ما می‌گه:

GitLab.com Database Incident - 2017/01/31



This incident affected the database (including issues and merge requests)
but not the git repo's (repositories and wikis).

Timeline (all times UTC):

2017/01/31 16:00/17:00 - 21:00

YP is working on setting up pgpool and replication in staging, creates
an LVM snapshot to get up to date production data to staging, hoping he
can re-use this for bootstrapping other replicas. This was done roughly
6 hours before data loss.

Getting replication to work is proving to be problematic and time
consuming (estimated at ±20 hours just for the initial pg_basebackup
sync). The LVM snapshot is not usable on the other replicas as far as YP
could figure out. Work is interrupted due to this (as YP needs the help
of another collegue who’s not working this day), and due to spam/high
load on GitLab.com

2017/01/31 21:00 - Spike in database load due to spam users - Twitter
| Slack

Blocked users based on IP address

Removed a user for using a repository as some form of CDN, resulting in
47 000 IPs signing in using the same account (causing high DB load). This
was communicated with the infrastructure and support team.

Removed users for spamming (by creating snippets) - Slack

Database load goes back to normal, some manual PostgreSQL vacuuming is
applied here and there to catch up with a large amount of dead tuples.

2017/01/31 22:00 - Replication lag alert triggered in pagerduty Slack

Attempts to fix db2, it’s lagging behind by about 4 GB at this point

db2.cluster refuses to replicate, /var/opt/gitlab/postgresql/data is
wiped to ensure a clean replication

db2.cluster refuses to connect to db1, complaining about max_wal_senders
being too low. This setting is used to limit the number of WAL (=
replication) clients

YP adjusts max_wal_senders to 32 on db1, restarts PostgreSQL

PostgreSQL complains about too many semaphores being open, refusing
to start

YP adjusts max_connections to 2000 from 8000, PostgreSQL starts again
(despite 8000 having been used for almost a year)

db2.cluster still refuses to replicate, though it no longer complains
about connections; instead it just hangs there not doing anything

At this point frustration begins to kick in. Earlier this night YP
explicitly mentioned he was going to sign off as it was getting late
(23:00 or so local time), but didn’t due to the replication problems
popping up all of a sudden.

2017/01/31 23:00-ish

YP thinks that perhaps pg_basebackup is being super pedantic about there
being an empty data directory, decides to remove the directory. After
a second or two he notices he ran it on db1.cluster.gitlab.com, instead
of db2.cluster.gitlab.com

2017/01/31 23:27 YP - terminates the removal, but it’s too late. Of
around 310 GB only about 4.5 GB is left - Slack

و از اون بالاتر حتی لایو استریم می کنه تو یوتوب من در واقع گیت لب رو دوست دارم و به نظرم خوبه در موردش بیشتر حرف بزنیم و حتی بهش سوییچ کنیم. دلیل اصلی اش اینه که اجازه می ده ما رپوزیتوریهای خصوصی هم داشته باشیم و خب وقتی اجازه می ده من رپوزیتوریهای غیرآزادم رو روش بذارم به نظرم قشنگتر اینه که من رپوزیتوری های آزادم رو هم ببرم اونجا. این مستقل از بحث های فنی است و قابلیت هایی که برای کار داره.

همینجا تصمیم رو قطعی می کنیم که در مقابل شماره رادیو گیک در مورد گیت هاب یک شماره هم در مورد گیت لب بسازیم. بسیار شرکت جالبی است و آدم های جالبی پشتش هستن. امیدوارم این استرسشون زودتر تموم بشه.

مرتبط:
– چرا دراپ باکس می گه پسوردهاش لو رفته؟

بالاخره از هفت خان پیدا کردن یک ماشین فیزیکی یا مجازی و انواع پیچیدگی‌های پرداخت گذر کردین و قراره دیستروی مناسب برای نصب کردن روی سرور رو انتخاب کنین. انتخابتون چیه؟ خیلی ها می گن آرچ مال آدم های خفن است، بعضی ها سراغ چیزهایی می رن مثل ردهت یا حتی اوراکل. اما واقعا کدوم توزیع برای ما بهتره؟ جواب اینه که:

لینوکس تنوع داره دقیقا به این خاطر که آدم ها و نیازهاشون تنوع دارن. هر کس ممکنه از چیزی خوشش بیاد و چیزی براش بهتر باشه. جواب نهایی در این مورد وجود نداره!

خب قبول! ولی اکثریت نیازهای ما با چه چیزی جواب داده خواهد شد؟

اولین سوال: دب یا آر پی ام

اولین نکته در انتخاب یک توزیع برای سرور اینه که شما می خواین از مدیر بسته های دبیانی (فایل های deb و دستورات apt) استفاده کنین یا ردهتی (فایل های rpm و مدیر بسته های yum یا dnf). این تا حد زیادی یک سلیقه و تجربه شخصی است. اکثر ما روی دسکتاپ با توزیع‌های مبتنی بر دبیان (مثلا اوبونتو یا مینت) شروع می کنیم و در نتیجه روی سرور هم اونها برامون راحتتر هستن. در مقابل شرکت های بزرگی مثل اوراکل و ردهت و سوزه توزیع سرور خودشون رو مبتنی بر rpm عرضه می کنن و اگر وارد دنیای حرفه ای بشین، بیشترین چیزی که می بینین اینها هستن. این انتخاب بین rpm و deb قدم اول شما برای رسیدن به توزیع مورد نظر است و تفاوت عجیبی هم با هم ندارن. البته من شخصا در کارهای شخصی (مثلا وب سرور خودم) سیستم های مبتنی بر دبیان رو ترجیح می دم و در سیستم های تجاری اداری (مثلا بانک یا مخابرات) سیستم های rpm رو.

دبیانی‌ها

در این بخش همونطور که از اسم بخش پیدا است، سیستم اصلی دبیان است. البته اوبونتوی سرور هم رقیب بسیار خوب و مناسبی به حساب می‌یاد. هر دوی این توزیع ها نسخه‌هایی با پشتیبانی طولانی مدت و تمرکز روی پایداری دارن که باعث می شه در این حوزه انتخابی بسیار مناسب باشن. من اگر بخوام روی سروری که مربوط به کارهای خودم است یا کنترلش با منه حس توی خونه خودم بودن داشته باشم، روش یا دبیان استیبل نصب می کنم یا اوبونتوی سرور LTS. اولی برای کارهای جدی تر و دومی برای کارهای فان تر.

آر پی امی‌ها

مطمئنا رقیب بلامنازع دنیای rpm برای سرورها، ردهت و لینوکس rhel است ولی ردهت یک شرکت تجاری و آمریکاییه که نصب کردن و ساپورت و آپدیت صحیحش نیاز به اشتراک و غیره داره. من اگر بخوام روی یک سرور کار کنم که بعدا قراره تحویل کس دیگه ای بشه – بخصوص در حوزه صنایع و تجارت های بزرگ مثل بانک و مخابرات – حتما انتخابم نمونه آزادتر ردهت یعنی سنت او اس است. در حال حاضر سنت او اس ۷ آخرین و مرسوم‌ترین نسخه است.

بقیه لینوکس‌ها

مطمئنا توزیع های گنو/لینوکس‌ زیاد دیگه ای هم برای سرور موجود هستن و هر کدوم رو به هر دلیلی که استفاده کنین خوبه – حتی کنجکاوی! توی این نوشته کوتاه فقط به چیزهای مرسوم اشاره کردیم ولی خیلی وقت ها اتفاقات خوب با رفتن از راه های کشف نشده اتفاق می افتن! هرچند که دو نکته دیگه باید قبل از پایان متن گفته بشه.

آرچ؟!

نصب آرچ سخت نیست ولی نیاز به کمی انگلیسی دونستن، حوصله و پهنای باند داره و به همین دلیل برای بعضی ها دور از دسترس به نظر می رسه. اسمش هم جور جالبی توی دهن میچرخه و در نتیجه وقتی کسی می شنوه یکی دیگه با آرچ کار می کنه معمولا احساس رعب می کنه؛ چیزی که می تونیم اسمش رو بذاریم وهم آرچی! این وهم مثل هر ترس دیگه در انسان‌ها باعث یک کشش و علاقه هم می شه و در نتیجه گاهی آدم ها در مقال چیزی که ازش می ترسن / می ترسیدن اونقدر خاشع می شن که می گن حتی دوستش دارن و به پرستش و اظهار ارادت های های بیجا هم می رسن. مثلا در دنیای گنو/لینوکسی این داستان، آرچ رو روی سرور نصب می کنن!

یکی از بهترین نقاط قوت آرچ در دسکتاپ، یکی از اصلی ترین نقطه ضعف های اون روی سرور است: غلطان بودن. غلطان بودن؛

1. غلطان بودن باعث می شه سیستم خطرناک‌تر آپدیت بشه. نمی گم آرچ غیرپایدار است ولی اصولا از یک سیستم غلطان نمی شه انتظار پایداری صد در صد داشت چون به هرحال بسته ها با سرعت به آخرین نسخه ها آپدیت می شن و خطر همیشه در کمینه!
2. غلطان بودن باعث می شه شما مطمئن نباشین که سیستم روی چه نسخه ای از هر لایبری یا نرم افزار ایستاده. اگر من دبیان پایدار نصب می کنم می دونم که پی اچ پی من روی فلان نسخه است و تغییر هم نمی کنه ولی در یک سیستم غلطان در هر مورد باید با دست مشخص بشه که می خوایم فلان بسته در فلان نسخه باشه. این روی سرور خطرناکه چون ممکنه سازگاری نرم افزارها یا نیازهای زیرساختی اونها به نسخه های خاص رو به هم بزنه.

البته معلومه که همه اینها قابل پیشگیری هستن ولی حرف اصلی اینه که به خاطر هیجان نباید آرچ رو روی سرور نصب کرد.

بی اس دی چی؟

بی اس دی ها مطمئنا یکی از بهترین گزینه‌ها برای وب سرورها هستن. اگر می خواین اونها رو تجربه کنین یا اگر باهاشون تجربه دارین برای وب سرور به شدت پیشنهاد می شن ولی حواستون باشه که مشکل اصلی اونها در مقایسه با لینوکس اینه که کمتر مرسوم هستن و ممکنه برای پیدا کردن منابع یا برنامه های سازگار و غیره به مشکل بیشتری بربخورین. به هرحال بررسی بی اس دی ها خارج از محدوده این مقاله است.

نکته جایزه!

حالا که تا اینجا اومدین و نتیجه رو دیدین که به شکل عمومی دبیان استیبل، اوبونتو سرور LTS و سنت او اس گزینه های مرسوم برای نصب روی سرورها هستن، این رو هم اضافه کنم که بسیار از نرم افزارها و شرکت های تجاری مهم، لینوکس خودشون با تنظیمات ریز و دقیق خودشون رو به شما تحمیل می کنن. مثلا اگر برنامه انتقال اسمس رو از فلان شرکت لهستانی بخرین حتما به شما می گه که این برنامه باید روی سنت او اس ۶ و مای اسکوئل ۴ اجرا بشه چون اونجا تست و بررسی شده. معمولا در کارهای حرفه ای اینطوری نیست که شما یک سیستم عامل رو کاملا مستقل از برنامه های روش انتخاب و نگهداری کنین. من توی آفریقا با زیمنس کار می کردم و تقریبا همه سرورها، گنو/لینوکس سوزه بودن؛ چرا؟ چون آلمانی است و شریک استراتژیک شرکت زیمنس (:

ما سروری داریم که تازه تحویلش دادیم ولی هر روز حوالی ظهر با مشکل مواجه می شه. کار اصلی رو پروسه ای انجام می ده که اینجا بهش می گیم A. چندین پروسه A می تونن همزمان بالا باشن و کار کنن و ما گفتیم حداکثر این تعداد باید ۱۰۰ باشه. یعنی در صورت زیاد شدن بار، ۱۰۰ تا A بالا می یان و تقریبا صد برابر بهتر از یک A کار می کنن. یک بررسی سریع نشون می ده که در لحظه بروز مشکل دقیقا ۱۰۰ تا از پروسه A فعاله:

# ps -ef | grep A | wc -l
101

مشخصه دیگه: ps -ef پروسه ها رو نشون می ده، grep A فقط خط هایی که توشون A هست رو جدا می کنه و در نهایت wc -l تعداد خط ها رو می شمره (اگر گفتین چرا به جای ۱۰۰ تا شده صد و یکی؟).

علی الحساب تعداد Aها رو به حداکثر ۱۰۰۰ عدد افزایش می دیم و می ریم سراغ سوالی که مطرحه:

آیا ما مورد حمله هستیم؟ آیا حوالی ظهر سیستمی شروع به کار با سیستم ما می کنه که فشار رو به شکل غیرعادی بالا می بره؟ یا واقعا این شرایط عادی است و اینقدر از این سیستم استفاده می شه؟

ما لاگ هایی به این شکل داریم که حاصل کار A هستن:

127.0.0.1 -  26/Jul/2015:03:48:53 +0430 "POST /index.php?_url=xxxxx" 200 /home/adp/www/xxx/public/index.php 357.489 2048 86.72%
127.0.0.1 -  26/Jul/2015:03:48:58 +0430 "POST /index.php?_url=qqqq" 200 /home/adp/www/xxx/public/index.php 91.281 1280 98.60%
127.0.0.1 -  26/Jul/2015:03:49:32 +0430 "GET /index.php?aaa" 200 /home/adp/www/xxx/public/index.php 373.649 1792 56.20%
127.0.0.1 -  26/Jul/2015:03:50:03 +0430 "HEAD /index.php" 200 /home/adp/www/xxx/public/index.php 43.501 1280 91.95%
127.0.0.1 -  26/Jul/2015:03:55:03 +0430 "HEAD /index.php" 200 /home/adp/www/xxxx/public/index.php 63.519 1280 94.46%

من از چند روز پیش این لاگ ها رو فعال کردم تا همه درخواست ها ذخیره بشن و حالا کافیه بشمرم ببینم چه خبره! اول بذارین همه لاگ هار و به همدیگه بچسبونیم:

jadi@funlife:/tmp/dir$ ls -ltrh 
total 36M
-rw------- 1 jadi jadi 9.2M Jul 22 03:17 www.access.log-20150722
-rw------- 1 jadi jadi 6.0M Jul 23 03:10 www.access.log-20150723
-rw------- 1 jadi jadi 6.4M Jul 24 03:25 www.access.log-20150724
-rw------- 1 jadi jadi 2.5M Jul 25 03:25 www.access.log-20150725
-rw------- 1 jadi jadi 7.4M Jul 26 03:45 www.access.log-20150726
-rw------- 1 jadi jadi 4.2M Jul 26 15:17 www.access.log
jadi@funlife:/tmp/dir$ cat www.access.log-* www.access.log > all.log
jadi@funlife:/tmp/dir$ ls -ltrh 
total 72M
-rw------- 1 jadi jadi 9.2M Jul 22 03:17 www.access.log-20150722
-rw------- 1 jadi jadi 6.0M Jul 23 03:10 www.access.log-20150723
-rw------- 1 jadi jadi 6.4M Jul 24 03:25 www.access.log-20150724
-rw------- 1 jadi jadi 2.5M Jul 25 03:25 www.access.log-20150725
-rw------- 1 jadi jadi 7.4M Jul 26 03:45 www.access.log-20150726
-rw------- 1 jadi jadi 4.2M Jul 26 15:17 www.access.log
-rw-rw-r-- 1 jadi jadi  36M Jul 26 15:30 all.log

راحت و سر راست. دستور cat که محتوای فایل ها رو نشون می ده، کل فایل ها رو چسبونده به هم تا یک فایل بزرگ به اسم all.log داشته باشیم که هر خطش چنین فرمی داره:

127.0.0.1 -  26/Jul/2015:03:48:53 +0430 "POST /index.php?_url=xxxxx" 200 /home/adp/www/xxx/public/index.php 357.489 2048 86.72%

کافه من تاریخ رو جدا کنم. دستور کات همیشه دوست منه:

jadi@funlife:/tmp/dir$ cut -d' ' -f4 all.log | head
20/Jul/2015:12:03:35
20/Jul/2015:12:03:36
20/Jul/2015:12:03:39
20/Jul/2015:12:03:39

جذاب نیست؟ به سادگی گفتم کات کن با جدا کننده اسپیس و فیلد چهارم رو به من بده ولی حالا فقط چند خط اول رو نشون بده (head). عملا کار تموم شده! کافیه این خطها رو بشمرم؛ البته بعد از حذف کردن ثانیه و دقیقه. برای حذف اینها کافیه شش کاراکتر آخر هر خط رو بردارم یا با همون دستور کات دوباره بگم بر اساس :‌ جدا کنه و فیلد اول و دوم رو به من بده. این راه دوم برای من سر راست تره:

jadi@funlife:/tmp/dir$ cut -d' ' -f4 all.log | cut -d: -f1,2 | head
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12
20/Jul/2015:12

چقدر عالی. دیگه فقط کافیه سورت کنیم و بگیم بشمره. دستور uniq‌ می تونه با سوییچ های مختلف کارهای مختلف کنه. مثلا فقط خط های غیرتکراری بده، فقط خط های تکراری رو بده، از هر خط بیشتر از یکبار نده، بشمره از هر خط چند تا هست و … و البته این دستور وابسته به اینه که ورودی اش مرتب شده باشه. پس:

jadi@funlife:/tmp/dir$ cut -d' ' -f4 all.log | cut -d: -f1,2 | sort -n | uniq -c > data
jadi@funlife:/tmp/dir$ head data
   2795 20/Jul/2015:12
   2363 20/Jul/2015:13
   2383 20/Jul/2015:14
   2251 20/Jul/2015:15
   1796 20/Jul/2015:16
   1599 20/Jul/2015:17
    843 20/Jul/2015:18
    704 20/Jul/2015:20
    765 20/Jul/2015:19
   1039 20/Jul/2015:21

چه کردیم! (: فقط کافیه ترسیمش کنیم:

و هر کسی که آمار یا حداقل نمودارهای نرمال بدونه می تونه بگه اتفاق غیرعادی ای در جریان نیست – حداقل در سطح درخواست ها. از ساعت هشت درخواست ها بالا می رن و بعد به شکلی نسبتا طبیعی افزایش پیدا می کنن تا آخر وقت اداری که دوباره آروم آروم پایین بیان. این پترن برای سایتی که مردم باهاش کار می کنن طبیعی است. مطمئنا می شه برنامه ما رو بهتر کرد ولی هدف من به عنوان مدیر سیستم این هست و بود که نشون بدم اتفاقی غیر عادی (درخواست ناگهانی از یک سیستم سر یک ساعت مشخص، حمله هکرها و …) در جریان نیست که تقریبا ثابت شده. اگر نمودارهای این تیپی دوست دارین بگین که بازم نمودارهایی واقعی از کارهای واقعی یک مدیر سیستم رو با هم مرور کنیم.