یوری بوشملف "نقشه چنگک در زمینه جمع آوری و تحویل سیاهههای مربوط" - متن گزارش

گزارش‌ها بخش مهمی از سیستم هستند و به شما این امکان را می‌دهند که بفهمید همانطور که انتظار می‌رود کار می‌کند (یا کار نمی‌کند). در شرایط معماری میکروسرویس، کار با لاگ به یک رشته جداگانه از المپیاد ویژه تبدیل می شود. مسائل زیادی وجود دارد که باید مورد توجه قرار گیرد:

• نحوه نوشتن گزارش از برنامه؛
• کجا برای نوشتن سیاهههای مربوط؛
• نحوه تحویل سیاههها برای ذخیره سازی و پردازش؛
• نحوه پردازش و ذخیره لاگ ها

استفاده از فناوری‌های کانتینری‌سازی محبوب در حال حاضر، شن و ماسه را در زمینه گزینه‌های حل مشکل به چنگک اضافه می‌کند.

دقیقاً همین رونوشت گزارش یوری بوشملف "نقشه چنگک در زمینه جمع آوری و تحویل کنده ها" است.

چه کسی اهمیت می دهد، لطفا زیر گربه.

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

ما اهل کجا هستیم؟ ما که هستیم؟ Lazada خرده فروش آنلاین شماره 1 در شش کشور در آسیای جنوب شرقی است. همه این کشورها بین مراکز داده توزیع شده اند. در حال حاضر در مجموع 4 مرکز داده وجود دارد، چرا این مهم است؟ زیرا برخی تصمیمات به این دلیل بود که پیوند بسیار ضعیفی بین مراکز وجود دارد. ما یک معماری میکروسرویس داریم. با تعجب متوجه شدم که ما در حال حاضر 80 میکروسرویس داریم. وقتی کار را با لاگ شروع کردم، تنها 20 مورد از آنها وجود داشت.به علاوه، یک قطعه نسبتاً بزرگ از میراث PHP وجود دارد که من نیز باید با آن زندگی کنم و تحمل کنم. همه اینها در حال حاضر بیش از 6 میلیون پیام در دقیقه برای کل سیستم برای ما ایجاد می کند. در ادامه نشان خواهم داد که چگونه سعی می کنیم با این زندگی کنیم و چرا اینطور است.

باید به نوعی با این 6 میلیون پیام زندگی کرد. با آنها چه کنیم؟ 6 میلیون پیام مورد نیاز:

• ارسال از برنامه
• برای تحویل قبول کنید
• تحویل برای تجزیه و تحلیل و ذخیره سازی
• تجزیه و تحلیل
• به نحوی ذخیره کنید

وقتی سه میلیون پیام وجود داشت، من تقریباً همان نگاه را داشتم. چون با چند سکه شروع کردیم. واضح است که لاگ های برنامه در آنجا نوشته شده است. به عنوان مثال، نمی تواند به پایگاه داده متصل شود، می تواند به پایگاه داده متصل شود، اما نمی تواند چیزی را بخواند. اما علاوه بر این، هر یک از میکروسرویس های ما یک گزارش دسترسی نیز می نویسد. هر درخواستی که به میکروسرویس می رسد در لاگ می افتد. چرا ما داریم این کار را می کنیم؟ توسعه دهندگان می خواهند بتوانند ردیابی کنند. هر گزارش دسترسی حاوی فیلد traceid است که بر اساس آن یک رابط ویژه کل زنجیره را باز می کند و ردیابی را به زیبایی نمایش می دهد. ردیابی نحوه انجام درخواست را نشان می دهد و این به توسعه دهندگان ما کمک می کند تا با هر گونه زباله ناشناخته سریعتر برخورد کنند.

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

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

با جمع آوری سیاههها، وضعیت تقریباً یکسان است. گزینه های زیادی برای حل این بخش خاص وجود ندارد. تعداد آنها بیشتر است، اما هنوز تعداد آنها زیاد نیست.

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

من به شما نشان خواهم داد که چگونه این کار را در Lazada انجام دادیم و چگونه همه چیز شروع شد.

یک سال پیش به لازاده آمدم و به پروژه لاگ فرستادم. اونجا اینجوری بود گزارش از برنامه در stdout و stderr نوشته شد. همه چیز به روش شیک انجام شد. اما سپس توسعه دهندگان آن را از جریان های استاندارد خارج کردند و سپس متخصصان زیرساخت به نحوی آن را کشف خواهند کرد. بین متخصصان زیرساخت و توسعه‌دهندگان، منتشرکنندگانی نیز وجود دارند که می‌گویند: «اوه... خب، بیایید آنها را در یک فایل با یک پوسته بپیچیم و تمام». و از آنجایی که همه اینها در یک ظرف است، آنها آن را دقیقاً در خود ظرف پیچیده کردند، دایرکتوری داخل آن را نقشه برداری کردند و آن را در آنجا قرار دادند. من فکر می کنم برای همه کاملاً واضح است که چه اتفاقی افتاده است.

بیایید کمی بیشتر نگاه کنیم. چگونه این سیاههها را تحویل دادیم. شخصی td-agent را انتخاب کرد که در واقع روان است اما کاملاً روان نیست. من هنوز رابطه این دو پروژه را درک نمی کنم، اما به نظر می رسد که آنها در مورد یک چیز هستند. و این نرم‌افزار، که به زبان روبی نوشته شده است، فایل‌های گزارش را می‌خواند، آنها را با استفاده از عبارات منظم به JSON تجزیه می‌کند. سپس آنها را نزد کافکا فرستادند. علاوه بر این، در کافکا، ما 4 موضوع جداگانه برای هر API داشتیم. چرا 4؟ از آنجا که زنده وجود دارد، مرحله بندی وجود دارد، و چون stdout و stderr وجود دارد. توسعه دهندگان آنها را تولید می کنند و کارگران زیرساخت باید آنها را در کافکا ایجاد کنند. علاوه بر این، کافکا توسط بخش دیگری کنترل می شد. بنابراین لازم بود یک تیکت ایجاد شود تا برای هر api 4 موضوع در آنجا ایجاد کنند. همه آن را فراموش کردند. در کل زباله و زباله بود.

بعدش چیکار کردیم؟ برای کافکا فرستادیم. دورتر از کافکا، نیمی از کنده ها به لاگستاش پرواز کردند. نیمی دیگر از سیاهههای مربوط به اشتراک گذاشته شد. برخی به یک گریلاگ پرواز کردند، برخی به گریلاگ دیگر. در نتیجه، همه اینها به یک خوشه Elasticsearch تبدیل شدند. یعنی این همه آشفتگی در نهایت به آنجا افتاد. شما مجبور نیستید این کار را انجام دهید!

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

در اینجا (1,2,3،XNUMX،XNUMX) ما فایل ها را می نویسیم و بر این اساس، سه رنک به طور همزمان در اینجا وجود دارد.

اولین (1) این است که باید آنها را در جایی بنویسیم. همیشه مطلوب نیست که یک API توانایی نوشتن مستقیم روی یک فایل را داشته باشد. مطلوب است که API در یک کانتینر ایزوله شود و حتی بهتر است فقط خواندنی باشد. من یک مدیر سیستم هستم، بنابراین دیدگاه کمی نسبت به این موارد دارم.

نکته دوم (2,3) این است که ما درخواست های زیادی به API داریم. API داده های زیادی را روی یک فایل می نویسد. فایل ها در حال رشد هستند. ما باید آنها را بچرخانیم. زیرا در غیر این صورت نمی توانید هیچ دیسکی را در آنجا ذخیره کنید. چرخاندن آنها بد است زیرا آنها از طریق پوسته به یک فهرست هدایت می شوند. هیچ راهی وجود ندارد که بتوانیم آن را بچرخانیم. نمی توانید به برنامه بگویید دسته ها را دوباره باز کند. زیرا توسعه دهندگان به شما مانند یک احمق نگاه می کنند: «چه توصیف کننده؟ ما معمولاً به stdout می نویسیم. فریم‌ورک‌ها copytruncate را به logrotate تبدیل می‌کنند، که فقط یک کپی از فایل می‌سازد و فایل اصلی را ترانک می‌کند. بر این اساس، بین این فرآیندهای کپی، فضای دیسک معمولا تمام می شود.

(4) ما فرمت های مختلفی در API های مختلف داشتیم. آنها کمی متفاوت بودند، اما regexp باید متفاوت نوشته می شد. از آنجایی که همه اینها توسط Puppet مدیریت می شد، یک دسته بزرگ از کلاس ها با سوسک های خودشان وجود داشت. به علاوه، td-agent بیشتر اوقات می‌توانست حافظه را بخورد، احمق باشد، فقط می‌توانست وانمود کند که دارد کار می‌کند و هیچ کاری انجام نمی‌دهد. از نظر ظاهری، غیرممکن بود که بفهمیم او هیچ کاری انجام نمی دهد. در بهترین حالت، او سقوط می کند و کسی بعداً او را خواهد برد. به طور دقیق تر، یک هشدار به داخل پرواز می کند و یک نفر می رود و آن را با دستان خود بلند می کند.

(6) و بیشترین زباله و ضایعات - الاستیک جستجو بود. چون نسخه قدیمی بود. چون در آن زمان اساتید فداکاری نداشتیم. ما گزارش‌های ناهمگنی داشتیم که فیلدهای آنها می‌توانستند همپوشانی داشته باشند. گزارش‌های مختلف برنامه‌های مختلف را می‌توان با نام فیلدهای یکسان نوشت، اما در همان زمان ممکن است داده‌های متفاوتی در داخل وجود داشته باشد. یعنی یک log با یک عدد صحیح در یک فیلد، به عنوان مثال، سطح می آید. گزارش دیگری با یک رشته در فیلد سطح ارائه می شود. در غیاب نقشه برداری ایستا، چنین چیز شگفت انگیزی معلوم می شود. اگر پس از چرخش ایندکس، ابتدا پیامی با یک رشته در elasticsearch رسید، پس ما به طور عادی زندگی می کنیم. و اگر اولین مورد با عدد صحیح رسید، تمام پیام‌های بعدی که با String رسیدند به سادگی کنار گذاشته می‌شوند. چون نوع فیلد مطابقت ندارد.

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

اما باید کاری کرد! نکته بدیهی این است که ما باید استانداردهایی را ایجاد کنیم. ما قبلاً استانداردهایی داشتیم. برخی را کمی بعد آوردیم. خوشبختانه، یک فرمت گزارش واحد برای همه APIها قبلاً در آن زمان تأیید شده بود. مستقیماً در استانداردهای تعامل سرویس نوشته شده است. بر این اساس کسانی که می خواهند لاگ ها را دریافت کنند باید آنها را در این قالب بنویسند. اگر کسی گزارش‌هایی را در این قالب نمی‌نویسد، ما چیزی را تضمین نمی‌کنیم.

علاوه بر این، من می خواهم یک استاندارد واحد برای روش های ثبت، تحویل و جمع آوری سیاهه ها داشته باشم. در واقع، کجا آنها را بنویسیم، و چگونه آنها را تحویل دهیم. وضعیت ایده آل زمانی است که پروژه ها از یک کتابخانه استفاده می کنند. یک کتابخانه لاگ جداگانه برای Go وجود دارد، یک کتابخانه جداگانه برای PHP وجود دارد. هر کس را داریم، همه باید از آنها استفاده کنند. در حال حاضر می گویم 80 درصد موفق هستیم. اما برخی به خوردن کاکتوس ها ادامه می دهند.

و در آنجا (در اسلاید) "SLA برای تحویل گزارش" به سختی ظاهر می شود. هنوز وجود ندارد، اما ما در حال کار روی آن هستیم. چون خیلی راحت است که infra بگوید اگر با فلان فرمت به فلان مکان بنویسید و بیشتر از N پیام در ثانیه نباشد، به احتمال زیاد ما آن را آنجا تحویل خواهیم داد. بسیاری از سردردها را از بین می برد. اگر SLA وجود داشته باشد، پس عالی است!

چگونه شروع به حل مشکل کردیم؟ چنگک اصلی با td-agent بود. معلوم نبود سیاهه های ما کجا می روند. آیا آنها تحویل داده می شوند؟ آیا آنها می روند؟ اصلا کجا هستند؟ بنابراین تصمیم بر این شد که اولین مورد جایگزین td-agent شود. در اینجا به طور خلاصه به گزینه هایی برای جایگزینی آن اشاره کردم.

روان. اولاً در یک کار قبلی با او برخورد کردم و او نیز به طور دوره ای آنجا می افتاد. ثانیاً فقط در پروفایل همین است.

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

راه حل واضح برای sysadmin همه نوع syslog در این مقدار است (syslog-ng/rsyslog/nxlog).

یا چیزی از خودتان بنویسید، اما ما آن را کنار گذاشتیم، همچنین filebeat. اگر چیزی می نویسید، پس بهتر است چیز مفیدی برای تجارت بنویسید. برای تحویل سیاههها بهتر است چیزی آماده بردارید.

بنابراین، انتخاب در واقع به انتخاب بین syslog-ng و rsyslog خلاصه شد. من به rsyslog متمایل شدم فقط به این دلیل که قبلاً کلاس هایی برای rsyslog در Puppet داشتیم و تفاوت آشکاری بین آنها پیدا نکردم. syslog چیست، syslog چیست. بله، برخی از اسناد بدتر هستند، برخی بهتر. او این راه را می داند و آن را به گونه ای دیگر انجام می دهد.

و کمی در مورد rsyslog. اول اینکه خیلی خوبه چون ماژول های زیادی داره. این یک RainerScript (زبان پیکربندی مدرن) قابل خواندن توسط انسان دارد. یک امتیاز عالی این است که می‌توانیم رفتار td-agent را با ابزارهای استاندارد آن تقلید کنیم و هیچ چیز برای برنامه‌ها تغییر نکرده است. یعنی ما td-agent را به rsyslog تغییر می دهیم و هنوز همه چیز را لمس نمی کنیم. و بلافاصله یک تحویل کاری دریافت می کنیم. بعد، mmnormalize چیز جالبی در مورد rsyslog است. این به شما اجازه می دهد تا لاگ ها را تجزیه کنید، اما نه با Grok و regexp. این یک درخت نحو انتزاعی می سازد. گزارش‌ها را تقریباً به همان روشی که یک کامپایلر کد منبع را تجزیه می‌کند، تجزیه می‌کند. این به شما امکان می دهد خیلی سریع کار کنید، CPU کمی بخورید، و به طور کلی، چیز بسیار جالبی است. یک دسته از پاداش های دیگر وجود دارد. من به آنها نمی پردازم.

rsyslog معایب بسیار بیشتری دارد. آنها تقریباً مشابه پاداش هستند. مشکلات اصلی این است که شما باید بتوانید آن را بپزید و باید یک نسخه را انتخاب کنید.

ما تصمیم گرفتیم که لاگ ها را در یک سوکت یونیکس بنویسیم. و نه در /dev/log، زیرا در آنجا ما یک ظروف گزارش سیستم را داریم، ژورنال در این خط لوله وجود دارد. پس بیایید به یک سوکت سفارشی بنویسیم. ما آن را به یک مجموعه قوانین جداگانه متصل می کنیم. در هیچ چیزی دخالت نکنیم. همه چیز شفاف و قابل درک خواهد بود. بنابراین ما در واقع انجام دادیم. دایرکتوری با این سوکت ها استاندارد شده و به همه کانتینرها ارسال می شود. کانتینرها می توانند سوکت مورد نیاز خود را ببینند، باز کنند و روی آن بنویسند.

چرا فایل نیست؟ چون همه خوانده اند مقاله در مورد Badushechka، که سعی کرد فایل را به docker فوروارد کند و متوجه شد که پس از راه اندازی مجدد rsyslog، توصیفگر فایل تغییر می کند و داکر این فایل را از دست می دهد. او چیز دیگری را باز نگه می دارد، اما نه همان سوکتی که در آن می نویسند. ما تصمیم گرفتیم که این مشکل را دور بزنیم، و در عین حال، مشکل مسدود کردن را دور بزنیم.

Rsyslog اقدامات نشان داده شده در اسلاید را انجام می دهد و لاگ ها را به رله یا کافکا ارسال می کند. کافکا از روش قدیمی پیروی می کند. Rayleigh - من سعی کردم از rsyslog خالص برای ارائه لاگ ها استفاده کنم. بدون صف پیام، با استفاده از ابزار استاندارد rsyslog. اساساً کار می کند.

اما نکات ظریفی وجود دارد که چگونه آنها را بعداً در این قسمت قرار دهید (Logstash/Graylog/ES). این قسمت (rsyslog-rsyslog) بین دیتاسنترها استفاده می شود. در اینجا یک پیوند tcp فشرده وجود دارد که به شما امکان می دهد پهنای باند را ذخیره کنید و بر این اساس، به نحوی احتمال دریافت برخی گزارش ها را از مرکز داده دیگری در هنگام پر شدن کانال افزایش دهید. چون ما اندونزی داریم که همه چیز بد است. مشکل همیشگی اینجاست.

ما به این فکر کردیم که واقعاً چگونه نظارت می کنیم، با چه احتمالی لاگ هایی که از برنامه ضبط کرده ایم به آن پایان می رسند؟ تصمیم گرفتیم متریک را شروع کنیم. Rsyslog ماژول جمع آوری آمار خود را دارد که دارای نوعی شمارنده است. به عنوان مثال، می تواند اندازه صف یا تعداد پیام هایی که برای فلان عمل وارد شده است را به شما نشان دهد. شما قبلاً می توانید چیزی از آنها بگیرید. به‌علاوه، شمارنده‌های سفارشی دارد که می‌توانید پیکربندی کنید، و مثلاً تعداد پیام‌هایی را که برخی API ضبط کرده‌اند به شما نشان می‌دهد. بعد، من rsyslog_exporter را در پایتون نوشتم و همه را برای Prometheus فرستادیم و نمودار کردیم. ما واقعاً معیارهای Graylog را می‌خواستیم، اما تا کنون فرصتی برای تنظیم آنها نداشته‌ایم.

مشکلات چیست؟ مشکل از این واقعیت به وجود آمد که ما (ناگهان!) متوجه شدیم که API های زنده ما 50 هزار پیام در ثانیه می نویسند. این فقط Live API بدون مرحله بندی است. و Graylog تنها 12 هزار پیام در ثانیه را به ما نشان می دهد. و یک سوال منطقی مطرح شد که بقایای آن کجاست؟ از آن نتیجه گرفتیم که Graylog به سادگی نمی تواند کنار بیاید. ما نگاه کردیم، و در واقع، Graylog با Elasticsearch بر این جریان تسلط نداشت.

در مرحله بعد، اکتشافات دیگری که در این راه انجام داده ایم.

نوشتن به سوکت مسدود شده است. چگونه اتفاق افتاد؟ زمانی که از rsyslog برای تحویل استفاده کردم، در مقطعی کانال بین مراکز داده را شکستیم. تحویل در یک مکان بالا رفت، تحویل در جای دیگر بالا رفت. همه اینها به ماشینی با APIهایی رسیده است که در سوکت rsyslog می نویسند. صف بود. سپس صف نوشتن در سوکت یونیکس پر شد که به طور پیش فرض 128 بسته است. و نوشتن () بعدی در بلوک های برنامه. وقتی به کتابخانه ای که در برنامه های Go استفاده می کنیم نگاه کردیم، در آنجا نوشته شده بود که نوشتن در سوکت در حالت غیر مسدود کننده رخ می دهد. مطمئن بودیم که هیچ چیز مسدود نشده است. چون خوانده ایم مقاله در مورد Badushechkaکه در مورد آن نوشت اما یک لحظه وجود دارد. همچنین یک حلقه بی نهایت در اطراف این تماس وجود داشت که در آن تلاش دائمی برای فشار دادن یک پیام به سوکت وجود داشت. ما متوجه او نشدیم. مجبور شدم کتابخانه را بازنویسی کنم. از آن زمان، چندین بار تغییر کرده است، اما اکنون ما از قفل در تمام زیرسیستم ها خلاص شده ایم. بنابراین، می توانید rsyslog را متوقف کنید و چیزی سقوط نخواهد کرد.

نظارت بر اندازه صف ها ضروری است که به پا نکردن این چنگک کمک می کند. اول، ما می توانیم زمان شروع به از دست دادن پیام ها را نظارت کنیم. ثانیاً ما می توانیم نظارت کنیم که اساساً در تحویل مشکل داریم.

و یک لحظه ناخوشایند دیگر - تقویت 10 برابری در معماری میکروسرویس بسیار آسان است. ما درخواست‌های دریافتی زیادی نداریم، اما به دلیل نموداری که این پیام‌ها در طول آن بیشتر اجرا می‌شوند، به دلیل گزارش‌های دسترسی، در واقع بار روی گزارش‌ها را حدود ده برابر افزایش می‌دهیم. متأسفانه وقت نکردم اعداد دقیق را محاسبه کنم، اما میکروسرویس ها همان چیزی هستند که هستند. این را باید در نظر داشت. به نظر می رسد که در حال حاضر زیرسیستم جمع آوری گزارش بیشترین بارگذاری را در Lazada دارد.

چگونه مشکل elasticsearch را حل کنیم؟ اگر می‌خواهید به سرعت لاگ‌ها را در یک مکان دریافت کنید تا در همه ماشین‌ها اجرا نشود و آنها را در آنجا جمع کنید، از ذخیره‌سازی فایل استفاده کنید. این کار تضمینی است. از هر سروری انجام می شود. فقط باید دیسک ها را در آنجا بچسبانید و syslog را قرار دهید. پس از آن، شما تضمین می‌کنید که همه لاگ‌ها را در یک مکان داشته باشید. سپس پیکربندی آهسته elasticsearch، graylog یا چیز دیگری امکان پذیر خواهد بود. اما شما از قبل همه گزارش‌ها را خواهید داشت، و علاوه بر این، می‌توانید تا آنجا که آرایه‌های دیسک کافی وجود دارد، آنها را ذخیره کنید.

در زمان گزارش من، این طرح به این شکل شروع شد. ما عملاً نوشتن در پرونده را متوقف کردیم. اکنون، به احتمال زیاد، ما باقیمانده ها را خاموش خواهیم کرد. در ماشین‌های محلی که API را اجرا می‌کنند، نوشتن روی فایل‌ها را متوقف می‌کنیم. اول، ذخیره سازی فایل وجود دارد که بسیار خوب کار می کند. ثانیاً، این ماشین‌ها دائماً فضای خالی دارند، شما باید دائماً آن را نظارت کنید.

این بخش با Logstash و Graylog، واقعاً اوج می گیرد. بنابراین، شما باید از شر آن خلاص شوید. شما باید یکی را انتخاب کنید.

تصمیم گرفتیم Logstash و Kibana را کنار بگذاریم. چون ما یک بخش امنیتی داریم. ارتباط چیست؟ ارتباط این است که Kibana بدون X-Pack و بدون Shield به شما اجازه نمی دهد حقوق دسترسی به لاگ ها را متمایز کنید. بنابراین، آنها Graylog را گرفتند. همه اش را دارد. من آن را دوست ندارم، اما کار می کند. ما سخت‌افزار جدیدی خریدیم، یک Graylog تازه در آنجا نصب کردیم و همه لاگ‌ها را با فرمت‌های سخت‌گیرانه به یک Graylog جداگانه منتقل کردیم. ما مشکل انواع رشته های مشابه را به صورت سازمانی حل کرده ایم.

دقیقاً چه چیزی در Graylog جدید گنجانده شده است. ما فقط همه چیز را در بارانداز نوشتیم. ما یکسری سرور گرفتیم، سه نمونه کافکا، 7 سرور Graylog نسخه 2.3 (چون من Elasticsearch نسخه 5 را می‌خواستم) عرضه کردیم. همه اینها در مورد حملات HDD مطرح شد. ما شاهد نرخ نمایه سازی تا 100 هزار پیام در ثانیه بودیم. این رقم را دیدیم که 140 ترابایت داده در هفته.

و دوباره یک چنگک جمع کردن! دو فروش در پیش داریم. ما از 6 میلیون پست فراتر رفته ایم. ما Graylog وقت جویدن نداریم. یه جورایی باید دوباره زنده بمونی

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

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

معیارها را از Graylog جمع آوری کنید.

یک محدودیت نرخ ایجاد کنید تا یک API دیوانه داشته باشیم که پهنای باند و هر چیز دیگری را از بین نبرد.

و در نهایت، نوعی SLA را با توسعه دهندگان امضا کنید تا بتوانیم به این میزان خدمت کنیم. اگر بیشتر می نویسید، متاسفم.

و مستندات را بنویسید.

به طور خلاصه، نتایج همه چیزهایی که ما تجربه کرده ایم. اول، استانداردها. دوم، syslog کیک است. ثالثاً rsyslog دقیقاً همانطور که در اسلاید نوشته شده است کار می کند. و برسیم به سوالات

پرسش.

سوال: چرا تصمیم گرفتند که ... (فایل بیت؟)

پاسخ: نیاز به نوشتن در یک فایل. من واقعا نمی خواستم. هنگامی که API شما هزاران پیام در ثانیه می نویسد، حتی اگر یک بار در ساعت بچرخانید، این گزینه هنوز یک گزینه نیست. می توانید به لوله بنویسید. که توسعه دهندگان از من پرسیدند: "اگر فرآیندی که در آن می نویسیم سقوط کند چه اتفاقی خواهد افتاد"؟ من فقط پیدا نکردم که به آنها چه جوابی بدهم و گفتم: "خب، باشه، این کار را نکنیم."

سوال: چرا فقط لاگ ها را در HDFS نمی نویسید؟

پاسخپاسخ: این مرحله بعدی است. ما در همان ابتدا به آن فکر کردیم، اما از آنجایی که در حال حاضر هیچ منبعی برای مقابله با آن وجود ندارد، در راه حل بلندمدت ما معلق است.

سوال: قالب ستونی مناسب تر است.

پاسخ: من میفهمم. ما با هر دو دست "برای" هستیم.

سوال: شما به rsyslog می نویسید. هر دو TCP و UDP در آنجا موجود هستند. اما اگر UDP، پس چگونه تحویل را تضمین می کنید؟

پاسخج: دو نکته وجود دارد. اول، بلافاصله به همه می گویم که ما تحویل سیاهه ها را تضمین نمی کنیم. چون وقتی توسعه‌دهندگان می‌آیند و می‌گویند: «بیایید شروع به نوشتن داده‌های مالی در آنجا کنیم و اگر اتفاقی بیفتد آن‌ها را در جایی برای ما قرار می‌دهید»، ما به آنها پاسخ می‌دهیم: «عالی! بیایید شروع به مسدود کردن نوشتن در سوکت کنیم و در تراکنش ها این کار را انجام دهیم تا تضمین شود که آن را برای ما در سوکت قرار دهید و مطمئن شوید که آن را از طرف دیگر دریافت کرده ایم. و در این لحظه، همه بلافاصله غیر ضروری می شوند. و اگر نه، پس چه سؤالاتی داریم؟ اگر نمی‌خواهید ضمانت نامه در سوکت را تضمین کنید، پس چرا ما تحویل را تضمین می‌کنیم؟ ما بهترین تلاش را می کنیم. ما واقعاً سعی می کنیم تا جایی که ممکن است و به بهترین شکل ممکن تحویل دهیم، اما ضمانت 100٪ نمی دهیم. بنابراین، نیازی به نوشتن اطلاعات مالی در آنجا ندارید. پایگاه های داده تراکنشی برای این کار وجود دارد.

سوال: هنگامی که API پیامی را به گزارش تولید می کند و کنترل را به میکروسرویس ها منتقل می کند، آیا با این مشکل مواجه شده اید که پیام های میکروسرویس های مختلف به ترتیب اشتباه می رسند؟ به همین دلیل، سردرگمی ایجاد می شود.

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

سوال: مهر زمانی ممکن است با میلی ثانیه متفاوت باشد.

پاسخ: مهر زمانی توسط خود API ایجاد می شود. این، در واقع، کل موضوع است. ما NTP داریم. API از قبل در خود پیام یک مهر زمانی ایجاد می کند. توسط rsyslog اضافه نشده است.

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

پاسخ: تقریبا. ما هر کشوری را در یک مرکز داده قرار داریم. ما در حال حاضر گسترش نداریم، به طوری که یک کشور در مراکز داده مختلف قرار می گیرد. بنابراین، نیازی به ترکیب آنها نیست. در داخل هر مرکز یک Log Relay وجود دارد. این یک سرور Rsyslog است. در واقع دو ماشین مدیریت. آنها به همین ترتیب تنظیم شده اند. اما در حال حاضر، ترافیک فقط از یکی از آنها عبور می کند. او همه چیز را جمع آوری می کند. برای هر موردی یک صف دیسک دارد. او لاگ ها را فشار می دهد و آنها را به مرکز داده مرکزی (سنگاپور) می فرستد، جایی که آنها قبلاً در Graylog مسموم شده اند. و هر مرکز داده دارای حافظه فایل مخصوص به خود است. در صورت قطع ارتباط، همه گزارش‌ها را در آنجا داریم. آنجا خواهند ماند. در آنجا ذخیره خواهند شد.

سوال: آیا در مواقع غیرعادی از آنجا لاگ می گیرید؟

پاسخ: می توانید به آنجا بروید (به ذخیره سازی فایل) و نگاه کنید.

سوال: چگونه نظارت می کنید که لاگ ها را گم نکنید؟

پاسخ: ما در واقع داریم آنها را از دست می دهیم و آن را زیر نظر داریم. نظارت از یک ماه پیش آغاز شد. کتابخانه ای که Go API از آن استفاده می کند دارای معیارهایی است. او می تواند شمارش کند که چند بار نتوانسته است در سوکت بنویسد. در حال حاضر یک اکتشافی پیچیده وجود دارد. یک بافر در آنجا وجود دارد. سعی می کند از آن به سوکت پیام بنویسد. اگر بافر سرریز شود، شروع به انداختن آنها می کند. و شمارش می کند که چند آنها را رها کرده است. اگر شمارنده ها شروع به سرریز شدن در آنجا کنند، ما از آن مطلع خواهیم شد. آنها اکنون به پرومتئوس نیز می آیند، و شما می توانید نمودارها را در Grafana ببینید. می توانید هشدارها را تنظیم کنید. اما هنوز مشخص نیست که آنها را برای چه کسی بفرستند.

سوال: در elasticsearch، لاگ‌ها را با افزونگی ذخیره می‌کنید. چند تا ماکت دارید؟

پاسخ: یک ماکت

سوال: فقط یک خط است؟

پاسخ: این استاد و ماکت است. داده ها در دو نسخه ذخیره می شوند.

سوال: آیا اندازه بافر rsyslog را به نحوی تغییر دادید؟

پاسخ: ما دیتاگرام ها را در یک سوکت یونیکس سفارشی می نویسیم. این بلافاصله محدودیت 128 کیلوبایتی را بر ما تحمیل می کند. ما نمی توانیم بیشتر در مورد آن بنویسیم. ما این را در استاندارد نوشته ایم. کسانی که می خواهند وارد فضای ذخیره سازی شوند، 128 کیلوبایت می نویسند. علاوه بر این، کتابخانه ها را قطع می کنند و پرچمی می گذارند که پیام قطع شده است. فیلد خاصی در استاندارد خود پیام داریم که نشان می دهد در هنگام ضبط قطع شده است یا خیر. بنابراین ما این فرصت را داریم که این لحظه را دنبال کنیم.

سوال: آیا شما JSON شکسته می نویسید؟

پاسخ: JSON شکسته در حین رله حذف می شود زیرا بسته بسیار بزرگ است. یا Graylog حذف خواهد شد، زیرا قادر به تجزیه JSON نخواهد بود. اما تفاوت‌های ظریفی در اینجا وجود دارد که باید اصلاح شوند و بیشتر به rsyslog گره خورده‌اند. من قبلاً چند شماره را در آنجا پر کرده ام که هنوز باید روی آنها کار شود.

سوال: چرا کافکا؟ آیا RabbitMQ را امتحان کرده اید؟ Graylog تحت چنین بارهایی جمع نمی شود؟

پاسخ: با Graylog درست نمی شود. و گریلوگ در حال شکل گیری است. واقعا برای او مشکل ساز است. اون یه جورایی و در واقع نیازی به آن نیست. من ترجیح می دهم از rsyslog مستقیماً در elasticsearch بنویسم و ​​سپس Kibana را تماشا کنم. اما ما باید موضوع را با نیروهای امنیتی حل کنیم. هنگامی که Graylog را بیرون می اندازیم و از Kibana استفاده می کنیم، یک نوع احتمالی توسعه ما است. Logstash منطقی نخواهد بود. چون من می توانم همین کار را با rsyslog انجام دهم. و یک ماژول برای نوشتن در elasticsearch دارد. با Graylog ما سعی می کنیم به نحوی زندگی کنیم. حتی کمی آن را اصلاح کردیم. اما هنوز جای پیشرفت وجود دارد.

درباره کافکا از نظر تاریخی هم اینطور بود. وقتی رسیدم، قبلاً آنجا بود و گزارش‌هایی از قبل روی آن نوشته می‌شد. ما فقط خوشه خود را بالا بردیم و لاگ ها را به آن منتقل کردیم. ما او را مدیریت می کنیم، می دانیم که او چه احساسی دارد. در مورد RabbitMQ... ما با RabbitMQ مشکل داریم. و RabbitMQ برای ما در حال توسعه است. ما آن را در حال تولید داریم و مشکلاتی در آن وجود داشت. حالا قبل از فروش، او را شمن می‌کردند و به طور معمول شروع به کار می‌کرد. اما قبل از آن، آمادگی عرضه آن را به مرحله تولید نداشتم. یه چیز دیگه هم هست Graylog می تواند نسخه AMQP 0.9 را بخواند و rsyslog می تواند نسخه AMQP 1.0 را بنویسد. و راه حل واحدی وجود ندارد که بتواند هر دو را در این وسط انجام دهد. یا یکی هست یا دیگری. پس فعلا فقط کافکا. اما تفاوت های ظریف نیز وجود دارد. زیرا omkafka نسخه rsyslog که ما استفاده می کنیم می تواند کل بافر پیامی را که از rsyslog برداشته است از دست بدهد. به شرطی که تحملش کنیم.

سوال: آیا از کافکا به خاطر داشتن آن استفاده می کنید؟ برای هیچ هدف دیگری استفاده نمی شود؟

پاسخ: کافکا که توسط تیم Data Science استفاده شد. این یک پروژه کاملاً مجزا است که متأسفانه نمی توانم در مورد آن چیزی بگویم. نمی دانم. او توسط تیم علم داده اداره می شد. هنگامی که سیاهههای مربوط شروع شد، آنها تصمیم گرفتند از آن استفاده کنند تا خود را قرار ندهند. اکنون Graylog را به روز کرده ایم و سازگاری را از دست داده ایم، زیرا نسخه قدیمی کافکا وجود دارد. باید خودمان را می ساختیم. در همان زمان، ما از شر این چهار موضوع برای هر API خلاص شدیم. ما یک تاپ عریض برای همه زنده‌ها، یک تاپ عریض برای همه صحنه‌ها درست کردیم و فقط همه چیز را آنجا فیلمبرداری کردیم. Graylog همه اینها را به صورت موازی بیان می کند.

سوال: چرا به این شمنیسم با سوکت نیاز داریم؟ آیا سعی کرده اید از درایور گزارش ثبت سیستم برای کانتینرها استفاده کنید.

پاسخ: آن زمان که این سوال را پرسیدیم، روابط پرتنشی با بارانداز داشتیم. docker 1.0 یا 0.9 بود. خود داکر عجیب بود. ثانیاً، اگر لاگ‌ها را نیز به آن وارد کنید... من یک ظن تأیید نشده دارم که همه لاگ‌ها را از طریق خود، از طریق داکر دیمون عبور می‌دهد. اگر یک API داریم که دیوانه می شود، بقیه API ها با این واقعیت مواجه می شوند که نمی توانند stdout و stderr را ارسال کنند. من نمی دانم این به کجا منجر خواهد شد. من در سطح احساس مشکوک هستم که لازم نیست از درایور docker syslog در این مکان استفاده کنید. بخش تست عملکردی ما خوشه Graylog خود را با گزارش‌ها دارد. آنها از درایورهای Docker log استفاده می کنند و به نظر می رسد همه چیز در آنجا خوب است. اما بلافاصله به Graylog GELF می نویسند. در لحظه ای که همه اینها را شروع کردیم، به آن نیاز داشتیم تا فقط کار کنیم. شاید بعداً وقتی یکی بیاید و بگوید صد سال است که به طور معمول کار می کند، ما تلاش کنیم.

سوال: شما بین مراکز داده با استفاده از rsyslog تحویل می دهید. چرا روی کافکا نه؟

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

منبع: www.habr.com