دا 2019 دی، او موږ لا تر اوسه په Kubernetes کې د لوګو راټولولو لپاره معیاري حل نه لرو. په دې مقاله کې، موږ غواړو، د حقیقي تمرین څخه د مثالونو په کارولو سره، زموږ لټونونه، ستونزې او د دوی حلونه شریک کړو.
په هرصورت، لومړی، زه به یو ریزرویشن وکړم چې مختلف پیرودونکي د لاګونو په راټولولو سره خورا مختلف شیان پوهیږي:
- یو څوک غواړي چې امنیت او د پلټنې لاګ وګوري؛
- څوک - د ټول زیربنا مرکزي ننوتل؛
- او د ځینو لپاره، دا یوازې د غوښتنلیک لاګونو راټولولو لپاره کافي دي، د بیلګې په توګه، بیلانسران.
لاندې د دې په اړه کټ مټ دی چې موږ څنګه مختلف "خواهش لیستونه" پلي کړل او له کومو ستونزو سره مخ شو.
تیوري: د ننوتلو وسیلو په اړه
د ننوتلو سیسټم د برخو په اړه پس منظر
ننوتنه خورا اوږده لاره ده، د پایلې په توګه چې د لاګونو راټولولو او تحلیل کولو میتودونه رامینځته شوي، کوم چې موږ نن ورځ کاروو. بیرته په 1950s کې ، فورټران د معیاري ان پټ / آؤټ پوټ جریانونو انالوګ معرفي کړ ، کوم چې د پروګرام کونکي سره د هغه برنامه ډیبګ کولو کې مرسته وکړه. دا د کمپیوټر لومړني لاګونه وو چې د هغه وخت پروګرام کونکو لپاره یې ژوند اسانه کړ. نن ورځ موږ په دوی کې د ننوتلو سیسټم لومړۍ برخه ګورو - د لاګونو سرچینه یا "تولید کونکی".
کمپيوټر ساينس ولاړ نه و: کمپيوټري جالونه راڅرګند شول، لومړي کلسترونه... پېچلي سيسټمونه چې له څو کمپيوټرونو څخه جوړ وو په کار پيل وکړ. اوس د سیسټم مدیران اړ شوي چې له څو ماشینونو څخه لاګونه راټول کړي، او په ځانګړو قضیو کې دوی کولی شي د OS کرنل پیغامونه اضافه کړي که چیرې دوی د سیسټم ناکامۍ تحقیق کولو ته اړتیا ولري. د مرکزي شوي لوګو راټولولو سیسټمونو تشریح کولو لپاره، د 2000 په لومړیو کې خپور شو ، کوم چې معیاري remote_syslog. دا څنګه بله مهمه برخه ښکاره شوه: د ننوتلو راټولونکی او د هغوی ذخیره.
د لاګونو حجم زیاتوالي او د ویب ټیکنالوژیو پراخه معرفي کولو سره ، دا پوښتنه راپورته شوه چې کوم لاګونه باید کاروونکو ته په اسانۍ سره وښودل شي. ساده کنسول وسیلې (awk/sed/grep) د نورو پرمختللو لخوا ځای په ځای شوي ننداره کوونکي - دریمه برخه.
د لاګونو د حجم د زیاتوالي له امله، یو څه بل روښانه شو: لوګو ته اړتیا ده، مګر ټول نه. او مختلف لاګونه د ساتنې مختلف کچې ته اړتیا لري: ځینې یې په یوه ورځ کې له لاسه ورکولی شي، پداسې حال کې چې نور باید د 5 کلونو لپاره زیرمه شي. نو، د لاګنګ سیسټم کې د ډیټا جریانونو فلټر کولو او روټینګ لپاره یوه برخه اضافه شوې - راځئ چې دا غږ کړو فلټر.
ذخیره هم یو لوی کودتا کړې: له منظم فایلونو څخه اړونده ډیټابیسونو ته، او بیا د اسنادو پر بنسټ ذخیره کولو (د مثال په توګه، Elasticsearch). نو ذخیره د راټولونکي څخه جلا شوه.
په نهایت کې، د لاګ مفهوم د پیښو یو ډول لنډیز جریان ته پراخ شوی چې موږ یې د تاریخ لپاره ساتل غواړو. یا بلکه، په هغه صورت کې چې تاسو د پلټنې ترسره کولو یا تحلیلي راپور چمتو کولو ته اړتیا لرئ ...
د پایلې په توګه، په نسبتا لنډ وخت کې، د لوګو راټولول په یو مهم فرعي سیسټم کې وده کړې، کوم چې په سمه توګه د لوی معلوماتو کې یو له فرعي برخو څخه بلل کیدی شي.
که یو وخت عادي چاپ د "لاګنګ سیسټم" لپاره کافي وي، اوس وضعیت خورا بدل شوی.
Kubernetes او logs
کله چې کوبرنیټس زیربنا ته راغی ، د لاګونو راټولولو دمخه موجود ستونزه یې هم له پامه غورځولې. په ځینو لارو کې، دا نور هم دردناک شو: د زیربنا پلیټ فارم اداره کول نه یوازې ساده شوي، بلکه په ورته وخت کې پیچلي هم. ډیری زاړه خدماتو مایکرو خدماتو ته مهاجرت پیل کړی. د لاګونو په شرایطو کې ، دا د لاګ سرچینو په ډیریدونکي شمیر کې منعکس کیږي ، د دوی ځانګړي ژوند دورې ، او د لاګ له لارې د سیسټم ټولو برخو اړیکو تعقیبولو اړتیا ...
مخکې لټولو، زه کولی شم ووایم چې اوس، له بده مرغه، د کوبرنیټس لپاره د لاګنګ کولو کوم معیاري اختیار شتون نلري چې د نورو ټولو سره په مناسبه توګه پرتله کړي. په ټولنه کې ترټولو مشهور سکیمونه په لاندې ډول دي:
- یو څوک سټیک خلاصوي EFK (Elasticsearch, Fluentd, Kibana);
- یو څوک هڅه کوي چې پدې وروستیو کې خوشې شوي یا کارول ;
- нас (او شاید یوازې موږ نه؟ ..) زه په لویه کچه له خپل پرمختګ څخه راضي یم - ...
د یوې قاعدې په توګه، موږ د K8s کلسترونو کې لاندې بنډلونه کاروو (د ځان کوربه حلونو لپاره):
- ;
- .
په هرصورت، زه به د دوی د نصب او ترتیب لپاره لارښوونو کې پاتې نه شم. پرځای یې، زه به په عمومي توګه د لاګونو سره د وضعیت په اړه د دوی نیمګړتیاو او نورو نړیوالو پایلو تمرکز وکړم.
په K8s کې د لاګونو سره تمرین وکړئ
"هره ورځ ثبتونه"، ستاسو څخه څو تنه شتون لري؟ ...
د کافي لوی زیربنا څخه د لوګو مرکزي راټولول د پام وړ سرچینو ته اړتیا لري، کوم چې به د لاګونو په راټولولو، ذخیره کولو او پروسس کولو کې مصرف شي. د مختلفو پروژو د عملي کولو په ترڅ کې، موږ د مختلفو اړتیاوو او عملیاتي ستونزو سره مخ وو چې له امله یې رامنځته کیږي.
راځئ چې د ClickHouse هڅه وکړو
راځئ چې د یو غوښتنلیک سره په پروژه کې مرکزي ذخیره وګورو چې لاګونه په فعاله توګه رامینځته کوي: په هر ثانیه کې له 5000 څخه ډیر لینونه. راځئ چې د هغه د لاګونو سره کار پیل کړو، دوی په ClickHouse کې اضافه کړئ.
هرڅومره ژر چې اعظمي ریښتیني وخت ته اړتیا وي ، د کلیک هاوس سره 4 کور سرور به دمخه د ډیسک فرعي سیسټم کې ډیر شي:
دا ډول بار کول د دې حقیقت له امله دي چې موږ هڅه کوو ژر تر ژره په کلیک هاؤس کې ولیکئ. او ډیټابیس دې ته د ډیسک زیاتوالي سره عکس العمل ښیې ، کوم چې کولی شي د لاندې غلطیو لامل شي:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
چې ده په ClickHouse کې (دوی د لاګ ډیټا لري) د لیکلو عملیاتو پرمهال خپلې ستونزې لري. هغه معلومات چې دوی ته داخل شوي یو لنډمهاله ویش رامینځته کوي، چې بیا د اصلي میز سره یوځای کیږي. د پایلې په توګه ، ثبت کول په ډیسک کې خورا غوښتنه کوي ، او دا د هغه محدودیت تابع هم دی چې موږ یې پورته په اړه خبرتیا ترلاسه کړې: په 1 ثانیه کې له 300 څخه ډیر فرعي برخې نشي یوځای کیدی (په حقیقت کې ، دا 300 داخلونه دي. په ثانیه کې).
د دې چلند څخه د مخنیوي لپاره، د امکان تر حده په لویو ټوټو کې او په هرو 1 ثانیو کې له 2 څخه ډیر نه. په هرصورت، په لویو برخو کې لیکل وړاندیز کوي چې موږ باید په ClickHouse کې لږ ځله ولیکو. دا، په بدل کې، کولی شي د بفر د ډیریدو او د لوګو له لاسه ورکولو لامل شي. د حل لاره د Fluentd بفر زیاتول دي، مګر بیا به د حافظې مصرف هم زیات شي.
تبصره: د ClickHouse سره زموږ د حل بله ستونزه د دې حقیقت سره تړاو لري چې زموږ په قضیه (لوګ هاؤس) کې ویشل د بهرني میزونو له لارې پلي کیږي. . دا د دې حقیقت لامل کیږي چې کله د لوی وخت وقفې نمونه کول ، ډیر RAM ته اړتیا ده ، ځکه چې د میټایټ ایبل د ټولو برخو له لارې تکرار کیږي - حتی هغه چې په څرګند ډول اړین معلومات نلري. په هرصورت، اوس دا طریقه د ClickHouse اوسني نسخو لپاره په خوندي توګه ناپاک اعلان کیدی شي (c ).
د پایلې په توګه، دا روښانه شوه چې هره پروژه په ClickHouse کې په ریښتیني وخت کې د لاګونو راټولولو لپاره کافي سرچینې نلري (په دقیق ډول، د دوی ویش به مناسب نه وي). سربیره پردې، تاسو به د کارولو ته اړتيا لري اکاډمیم، کوم چې موږ به وروسته بیرته راستانه شو. پورته بیان شوی قضیه ریښتیا ده. او په هغه وخت کې موږ نشو کولی د باور وړ او باثباته حل وړاندیز وکړو چې د پیرودونکي سره مناسب وي او موږ ته اجازه راکوي چې د لږترلږه ځنډ سره لاګ راټول کړو ...
د Elasticsearch په اړه څه؟
Elasticsearch د درنو کاري بارونو اداره کولو لپاره پیژندل کیږي. راځئ چې په ورته پروژه کې هڅه وکړو. اوس بار داسې ښکاري:
Elasticsearch د دې توان درلود چې د ډیټا جریان هضم کړي، په هرصورت، دې ته ورته حجم لیکل د CPU څخه ډیره ګټه پورته کوي. دا د کلستر په تنظیم کولو سره پریکړه کیږي. په تخنیکي توګه، دا کومه ستونزه نده، مګر دا معلومه شوه چې یوازې د لاګ راټولولو سیسټم چلولو لپاره موږ دمخه شاوخوا 8 کورونه کاروو او په سیسټم کې اضافي لوړ بار شوي برخې لرو ...
لاندینۍ کرښه: دا اختیار توجیه کیدی شي، مګر یوازې هغه وخت چې پروژه لویه وي او د هغې مدیریت چمتو وي چې د مرکزي ننوتلو سیسټم باندې د پام وړ سرچینې مصرف کړي.
بیا یوه طبیعي پوښتنه راپورته کیږي:
کوم لوګو واقعیا اړتیا لري؟
راځئ هڅه وکړو چې پخپله طریقه بدله کړو: لاګونه باید په ورته وخت کې معلوماتي وي او پوښ نه وي هر یو په سیسټم کې پیښه.
راځئ چې ووایو موږ یو بریالی آنلاین پلورنځی لرو. کوم لاګونه مهم دي؟ د امکان په توګه د ډیرو معلوماتو راټولول، د بیلګې په توګه، د تادیې دروازې څخه، یو ښه نظر دی. مګر د محصول په کتلاګ کې د عکس سلیزینګ خدمت څخه ټولې لاګونه زموږ لپاره مهم ندي: یوازې خطاګانې او پرمختللي څارنه کافي دي (د مثال په توګه ، د 500 غلطیو سلنه چې دا برخه رامینځته کوي).
نو موږ دې پایلې ته رسیدلي یو مرکزي ننوتل تل د توجیه وړ ندي. ډیری وختونه پیرودونکي غواړي ټول لاګونه په یو ځای کې راټول کړي، که څه هم په حقیقت کې، د ټول لاګ څخه، یوازې د مشروط 5٪ پیغامونه چې د سوداګرۍ لپاره مهم دي اړین دي:
- ځینې وختونه دا د تنظیم کولو لپاره کافي دي ، ووایه ، یوازې د کانټینر لاګ اندازه او د خطا راټولونکی (د مثال په توګه ، سینټري).
- د تېروتنې خبرتیا او یو لوی محلي لاګ پخپله ممکن د پیښو تحقیق کولو لپاره کافي وي.
- موږ داسې پروژې درلودې چې په ځانګړي ډول د فعالو ازموینو او د خطا راټولولو سیسټمونو سره ترسره شوې. پراختیا کونکي ورته لاګ ته اړتیا نلري - دوی هرڅه د غلطۍ نښو څخه ولیدل.
له ژوند څخه بیلګه
بله کیسه کولی شي د ښه مثال په توګه خدمت وکړي. موږ زموږ د یو پیرودونکي د امنیت ټیم څخه غوښتنه ترلاسه کړه چې دمخه یې د سوداګریز حل څخه کار اخیستی و چې د کبرنیټس معرفي کیدو دمخه رامینځته شوی و.
دا اړینه وه چې د کارپوریټ ستونزې کشف سینسر - QRadar سره د مرکزي شوي لاګ راټولولو سیسټم "ملګري" کړئ. دا سیسټم کولی شي د سیسلاګ پروتوکول له لارې لاګونه ترلاسه کړي او د FTP څخه یې ترلاسه کړي. په هرصورت، دا سمدستي ممکنه نه وه چې دا د fluentd لپاره د remote_syslog پلگ ان سره یوځای کړئ (لکه څنګه چې معلومه شوه، ). د QRadar په ترتیب کولو کې ستونزې د پیرودونکي د امنیت ټیم په خوا کې وې.
د پایلې په توګه، د سوداګرۍ مهم لاګ یوه برخه FTP QRadar ته اپلوډ شوې، او بله برخه په مستقیم ډول د نوډونو څخه د ریموټ سیسلوګ له لارې لیږل شوې. د دې لپاره موږ حتی لیکلي - شاید دا به د یو چا سره د ورته ستونزې حل کولو کې مرسته وکړي ... د پایلې سکیم څخه مننه، پیرودونکي پخپله مهم لاګونه ترلاسه او تحلیل کړل (د خپلې خوښې وسیلې په کارولو سره) ، او موږ وکولی شو د ننوتلو سیسټم لګښت کم کړو ، یوازې د سپما کولو لپاره. تیره میاشت.
بله بیلګه د دې لپاره خورا اشاره ده چې څه باید ونه کړو. د پروسس کولو لپاره زموږ یو پیرودونکي هر یو پیښې د کارونکي څخه راځي، څو لاین جوړ کړي غیر منظم محصول په لاګ کې معلومات. لکه څنګه چې تاسو اټکل کولی شئ، دا ډول لاګونه د لوستلو او ذخیره کولو دواړو لپاره خورا ستونزمن وو.
د لوګو لپاره معیارونه
دا ډول مثالونه دې پایلې ته رسوي چې د لاګ راټولولو سیسټم غوره کولو سربیره ، تاسو اړتیا لرئ همدا رنګه لاګونه پخپله ډیزاین کړئ! دلته اړتیاوې څه دي؟
- لاګز باید د ماشین لوستلو وړ بڼه کې وي (د مثال په توګه، JSON).
- لاګونه باید کمپیکٹ وي او د احتمالي ستونزو د مخنیوي لپاره د ننوتلو درجې بدلولو وړتیا سره. په ورته وخت کې ، د تولید چاپیریال کې تاسو باید سیسټمونه د ننوتلو کچې سره پرمخ وړئ لکه خبرداری او یا تېروتنه.
- لاګونه باید نورمال شي، دا دی، په لوګ اعتراض کې، ټولې کرښې باید د ورته ساحې ډول ولري.
غیر منظم شوي لاګونه کولی شي په ذخیره کې د لاګونو بارولو او د دوی په پروسس کې د بشپړ بندیدو سره ستونزې رامینځته کړي. د مثال په توګه، دلته د 400 غلطۍ سره یو مثال دی، کوم چې ډیری یې یقینا په روان لاګونو کې مخ شوي دي:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
تېروتنه پدې مانا ده چې تاسو داسې ساحه لیږئ چې ډول یې د چمتو شوي نقشه کولو سره شاخص ته بې ثباته وي. ترټولو ساده مثال د متغیر سره په نګینکس لاګ کې ساحه ده $upstream_status. دا کیدای شي یو شمیر یا تار ولري. د مثال په ډول:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
لاګونه ښیې چې سرور 10.100.0.10 د 404 غلطۍ سره ځواب ورکړ او غوښتنه د مینځپانګې بل ذخیره ته لیږل شوې. د پایلې په توګه، په لاګونو کې ارزښت داسې شو:
"upstream_response_time": "0.001, 0.007"
دا وضعیت دومره عام دی چې حتی د جلا کولو مستحق دی .
د اعتبار په اړه څه؟
ځینې وختونه شتون لري کله چې پرته له استثنا څخه ټولې لاګونه حیاتي وي. او له دې سره، د K8s لپاره د لوګو راټولولو ځانګړي سکیمونه چې پورته یې وړاندیز شوي / بحث شوي ستونزې لري.
د مثال په توګه، fluentd نشي کولی د لنډمهاله کانټینرونو څخه لاګونه راټول کړي. زموږ په یوه پروژه کې، د ډیټابیس مهاجرت کانټینر د 4 ثانیو څخه لږ ژوند کاوه او بیا حذف شوی و - د اړوند تشریح سره سم:
"helm.sh/hook-delete-policy": hook-succeeded
د دې له امله، د مهاجرت اجرا کولو لاګ په ذخیره کې شامل نه و. سیاست کولی شي پدې قضیه کې مرسته وکړي. before-hook-creation.
بله بیلګه د ډاکر لاګ گردش دی. راځئ چې ووایو یو غوښتنلیک شتون لري چې په فعاله توګه لاګونو ته لیکي. د نورمال شرایطو لاندې ، موږ اداره کوو چې ټولې لاګونه پروسس کړو ، مګر هرڅومره ژر چې ستونزه راڅرګنده شي - د مثال په توګه ، لکه څنګه چې پورته د غلط فارمیټ سره تشریح شوي - پروسس کول ودریږي ، او ډاکر فایل گردش کوي. پایله دا ده چې د سوداګرۍ مهمې لاګونه ممکن له لاسه ورکړل شي.
له همدې کبله دا مهمه ده چې د log جریان جلا کړئ، د خورا قیمتي توکو لیږل مستقیم غوښتنلیک ته لیږدول ترڅو د دوی خوندیتوب ډاډمن کړي. برسېره پردې، دا به بې ځایه نه وي چې ځینې یې جوړ کړي د لاګونو "جمع کوونکی"، کوم چې کولی شي د مهم پیغامونو خوندي کولو پرمهال د لنډ ذخیره کولو نشتوالي ژوندي پاتې شي.
په نهایت کې ، موږ باید دا هیر نکړو دا مهمه ده چې هر فرعي سیسټم په سمه توګه وڅارئ. که نه نو، دا اسانه ده چې یو داسې حالت ته لاړ شي چې په کوم حالت کې روان وي CrashLoopBackOff او هیڅ شی نه لیږل کیږي، او دا د مهم معلوماتو له لاسه ورکولو ژمنه کوي.
موندنو
پدې مقاله کې، موږ د SaaS حلونو لکه Datadog په لټه کې نه یو. دلته تشریح شوي ډیری ستونزې لا دمخه د سوداګریزو شرکتونو لخوا په یوه یا بل ډول حل شوي چې د لاګونو راټولولو کې تخصص لري ، مګر هرڅوک نشي کولی د مختلف دلایلو لپاره SaaS وکاروي. (اصلي یې لګښت او د 152-FZ سره موافقت دي).
د مرکزي شوي لاګ راټولول په لومړي سر کې د یو ساده کار په څیر ښکاري، مګر دا په هیڅ ډول ندي. دا مهمه ده چې په یاد ولرئ چې:
- یوازې مهمې برخې باید په تفصیل سره ننوتل شي، پداسې حال کې چې څارنه او د تېروتنې راټولول د نورو سیسټمونو لپاره تنظیم کیدی شي.
- په تولید کې ننوتل باید لږترلږه وساتل شي ترڅو غیر ضروري بار اضافه نشي.
- لاګونه باید د ماشین لوستلو وړ وي، نورمال شوي، او یو سخت شکل ولري.
- واقعیا مهمې لاګونه باید په جلا جریان کې ولیږدول شي ، کوم چې باید له اصلي څخه جلا شي.
- دا د لاګ جمع کونکي په پام کې نیولو سره ارزښت لري ، کوم چې کولی شي تاسو د لوړ بار له مینځه وړلو څخه وژغوري او په ذخیره کې بار ډیر یونیفورم کړي.
دا ساده قواعد، که چیرې په هر ځای کې پلي شي، نو پورته بیان شوي سرکیټونو ته به اجازه ورکړي چې کار وکړي - حتی که دوی مهمې برخې (بیټرۍ) له لاسه ورکړي. که تاسو داسې اصولو ته غاړه نه ږدئ، دا کار به تاسو او زیربنا په اسانۍ سره د سیسټم بل خورا ډیر بار شوي (او په ورته وخت کې غیر اغیزمن) برخې ته ورسوي.
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
سرچینه: www.habr.com