نظارت به عنوان یک سرویس: یک سیستم مدولار برای معماری میکروسرویس

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

این پست متن سخنرانی من با ماست بخش ها در RIT++. بسیاری از افراد از ما خواستند که نسخه متنی گزارش ها را از آنجا تهیه کنیم. اگر در کنفرانس بودید یا ویدیو را تماشا کردید، چیز جدیدی پیدا نخواهید کرد. و بقیه - به گربه خوش آمدید. من به شما خواهم گفت که چگونه به چنین سیستمی رسیدیم، چگونه کار می کند و چگونه قصد داریم آن را به روز کنیم.

گذشته: طرح ها و طرح ها

چگونه به سیستم نظارتی فعلی رسیدیم؟ برای پاسخ به این سوال باید به سال 2015 بروید. این چیزی است که در آن زمان به نظر می رسید:

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

ما یک ذخیره‌سازی معیار داریم: اینها گرافیت‌ها هستند که مبتنی بر درایوهای SSD سریع خواهند بود، اینها جمع‌کننده‌های خاصی برای معیارها هستند. بعدی - Grafana برای نمایش داشبورد و Moira برای هشدار. ما همچنین می خواستیم سیستمی برای جستجوی ناهنجاری ها ایجاد کنیم.

استاندارد: مانیتورینگ 2.0

این همان چیزی است که برنامه ها در سال 2015 به نظر می رسید. اما ما باید نه تنها زیرساخت ها و خود سرویس، بلکه مستندات آن را نیز آماده می کردیم. ما یک استاندارد شرکتی برای خودمان ایجاد کرده ایم که آن را نظارت 2.0 می نامیم. الزامات سیستم چه بود؟

• در دسترس بودن ثابت؛
• فاصله ذخیره سازی معیارها = 10 ثانیه.
• ذخیره سازی ساختار یافته متریک ها و داشبوردها؛
• SLA > 99,99%
• مجموعه ای از معیارهای رویداد از طریق UDP (!).

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

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

حال: نمودار تعامل اجزای نظارت

اول از همه، ما برنامه‌ها را رصد می‌کنیم: کد PHP، برنامه‌ها و میکروسرویس‌ها - به طور خلاصه، همه چیزهایی که توسعه‌دهندگان ما می‌نویسند. همه برنامه ها معیارها را از طریق UDP به جمع کننده Brubeck ارسال می کنند (statsd، بازنویسی شده در C). معلوم شد که در آزمایشات مصنوعی سریعترین است. و معیارهای جمع‌آوری‌شده را از طریق TCP به Graphite ارسال می‌کند.

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

ما همچنین برای معیارهای سخت‌افزار، نرم‌افزار، معیارهای سیستم و سیستم قدیمی مانیتورینگ Munin خود جمع‌آوری می‌کنیم (تا سال 2015 برای ما کار می‌کرد). ما همه اینها را از طریق C daemon CollectD جمع‌آوری می‌کنیم (مجموعه‌ای از پلاگین‌های مختلف در آن تعبیه شده است، می‌تواند تمام منابع سیستم میزبانی که روی آن نصب شده است را جمع‌آوری کند، فقط در پیکربندی مشخص کنید که کجا باید داده‌ها را بنویسید) و داده ها را از طریق آن به Graphite بنویسید. همچنین از افزونه‌های پایتون و اسکریپت‌های پوسته پشتیبانی می‌کند، بنابراین می‌توانید راه‌حل‌های سفارشی خود را بنویسید: CollectD این داده‌ها را از یک میزبان محلی یا راه دور (با فرض Curl) جمع‌آوری کرده و به Graphite ارسال می‌کند.

سپس تمام معیارهایی را که جمع آوری کردیم به رله کربن-c ارسال می کنیم. این راه حل Carbon Relay از Graphite است که در C تغییر یافته است. این روتری است که تمام معیارهایی را که ما از تجمیع کننده های خود ارسال می کنیم جمع آوری می کند و آنها را به گره ها هدایت می کند. همچنین در مرحله مسیریابی، اعتبار معیارها را بررسی می کند. اولا، آنها باید با طرح پیشوندی که قبلا نشان دادم مطابقت داشته باشند و ثانیاً برای گرافیت معتبر هستند. در غیر این صورت سقوط می کنند.

رله کربن-c سپس معیارها را به خوشه گرافیت می فرستد. ما از Cache کربن، بازنویسی شده در Go، به عنوان ذخیره اصلی معیارها استفاده می کنیم. Go-carbon، به دلیل چند رشته ای بودن، عملکرد بسیار بهتری از Carbon-cache دارد. داده ها را دریافت کرده و با استفاده از بسته whisper (استاندارد، نوشته شده در پایتون) روی دیسک می نویسد. برای خواندن داده ها از حافظه های خود، از Graphite API استفاده می کنیم. این بسیار سریعتر از گرافیت وب استاندارد است. بعد از آن چه اتفاقی برای داده ها می افتد؟

آنها به گرافانه می روند. ما از خوشه های گرافیتی خود به عنوان منبع اصلی داده استفاده می کنیم، به علاوه Grafana را به عنوان یک رابط وب برای نمایش معیارها و ساخت داشبورد داریم. برای هر یک از خدمات خود، توسعه دهندگان داشبورد خود را ایجاد می کنند. سپس بر اساس آنها نمودارهایی می سازند که معیارهایی را که از برنامه های خود می نویسند نشان می دهد. علاوه بر گرافانا SLAM هم داریم. این یک شیطان پایتون است که SLA را بر اساس داده های گرافیت محاسبه می کند. همانطور که قبلاً گفتم، ما چندین ده میکروسرویس داریم که هر کدام نیازهای خاص خود را دارند. با استفاده از SLAM، به سراغ مستندات می رویم و آن را با آنچه در Graphite وجود دارد مقایسه می کنیم و مقایسه می کنیم که الزامات چقدر با در دسترس بودن خدمات ما مطابقت دارند.

بیایید جلوتر برویم: هشدار. با استفاده از یک سیستم قوی - Moira سازماندهی شده است. مستقل است زیرا گرافیت مخصوص به خود را در زیر کاپوت دارد. توسعه یافته توسط بچه های SKB "Kontur"، نوشته شده در پایتون و Go، کاملا منبع باز. مویرا همان جریانی را دریافت می کند که به گرافیت می رود. اگر به دلایلی فضای ذخیره‌سازی شما از بین برود، هشدار شما همچنان کار می‌کند.

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

ما همچنین یک LDAP شرکتی را به آن ضمیمه کردیم که با کمک آن هر کاربر سیستم شرکتی می تواند بر اساس محرک های موجود (یا تازه ایجاد شده) برای خود اعلان ایجاد کند. از آنجایی که Moira حاوی Graphite است، از تمام ویژگی های آن پشتیبانی می کند. بنابراین ابتدا خط را بگیرید و آن را در Grafana کپی کنید. نحوه نمایش داده ها در نمودارها را ببینید. و سپس همان خط را می گیرید و آن را در مویرا کپی می کنید. شما آن را با محدودیت ها آویزان می کنید و در خروجی هشدار دریافت می کنید. برای انجام همه این کارها، به دانش خاصی نیاز ندارید. Moira می تواند از طریق SMS، ایمیل، Jira، Slack هشدار دهد... همچنین از اجرای اسکریپت های سفارشی پشتیبانی می کند. هنگامی که یک ماشه برای او اتفاق می افتد، و او مشترک یک اسکریپت سفارشی یا باینری می شود، آن را اجرا می کند و JSON را برای این باینری به stdin می فرستد. بر این اساس، برنامه شما باید آن را تجزیه کند. اینکه چه کاری با این JSON انجام خواهید داد به شما بستگی دارد. اگه خواستی تو تلگرام بفرست، اگه خواستی تو جیرا تسک ها رو باز کن، هر کاری کردی.

ما همچنین از توسعه خودمان برای هشدار استفاده می کنیم - Imagotag. ما پنل را که معمولاً برای برچسب‌های قیمت الکترونیکی در فروشگاه‌ها استفاده می‌شود، متناسب با نیاز خود تطبیق دادیم. ماشه هایی را از مویرا به آن آوردیم. این نشان می دهد که آنها در چه وضعیتی هستند و چه زمانی رخ داده اند. برخی از توسعه دهندگان اعلان ها را در Slack و ایمیل به نفع این پنل رها کردند.

خب، چون ما یک شرکت مترقی هستیم، کوبرنتیس را نیز در این سیستم مانیتور کردیم. ما آن را با استفاده از Heapster در سیستم قرار دادیم که در کلاستر نصب کردیم، داده ها را جمع آوری کرده و به Graphite ارسال می کند. در نتیجه، نمودار به صورت زیر است:

مولفه های نظارت

در اینجا لیستی از پیوندها به مؤلفه هایی که برای این کار استفاده کرده ایم آمده است. همه آنها متن باز هستند.

گرافیت:

• گو-کربن: github.com/lomik/go-carbon
• نجوا: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

رله کربن-c:

github.com/grobian/carbon-c-relay

بروبک:

github.com/github/brubeck

جمع آوری شده:

collectd.org

مویرا:

github.com/moira-alert

گرافانا:

grafana.com

Heapster:

github.com/kubernetes/heapster

آمار

و در اینجا اعدادی در مورد نحوه عملکرد سیستم برای ما وجود دارد.

جمع کننده (بروبک)

تعداد معیارها: ~ 300 در ثانیه
فاصله ارسال معیارها به گرافیت: 30 ثانیه
استفاده از منابع سرور: ~ 6٪ CPU (ما در مورد سرورهای تمام عیار صحبت می کنیم). ~ 1 گیگابایت رم؛ ~ 3 مگابیت بر ثانیه LAN

گرافیت (گو-کربن)

تعداد معیارها: ~ 1 / دقیقه
فاصله به روز رسانی متریک: 30 ثانیه
طرح ذخیره‌سازی معیارها: 30 ثانیه 35 روز، 5 دقیقه 90 روز، 10 دقیقه و 365 روز (به شما درک درستی از اتفاقاتی که برای سرویس در مدت زمان طولانی می‌افتد را می‌دهد)
استفاده از منابع سرور: ~ 10٪ CPU. 20 گیگ رم؛ 30 مگابیت بر ثانیه LAN

انعطاف پذیری

ما در Avito واقعاً برای انعطاف پذیری در خدمات نظارتی خود ارزش قائل هستیم. چرا او واقعاً اینگونه شد؟ اولاً، اجزای آن قابل تعویض هستند: هم خود اجزا و هم نسخه های آنها. دوم، قابلیت پشتیبانی. از آنجایی که کل پروژه منبع باز است، می توانید کد را خودتان ویرایش کنید، تغییراتی ایجاد کنید و توابعی را که خارج از جعبه در دسترس نیستند پیاده سازی کنید. از پشته های بسیار رایجی استفاده می شود، عمدتاً Go و Python، بنابراین این کار کاملاً ساده انجام می شود.

در اینجا یک مثال از یک مشکل واقعی است. متریک در گرافیت یک فایل است. اسم داره نام فایل = نام متریک. و راهی برای رسیدن به آنجا وجود دارد. نام فایل ها در لینوکس به 255 کاراکتر محدود می شود. و ما (به عنوان "مشتریان داخلی") از بخش پایگاه داده داریم. آنها به ما می گویند: "ما می خواهیم پرس و جوهای SQL خود را نظارت کنیم. و آنها 255 کاراکتر نیستند بلکه هر کدام 8 مگابایت هستند. ما می خواهیم آنها را در Grafana نمایش دهیم، پارامترهای این درخواست را ببینیم و حتی بهتر از آن، می خواهیم بالای چنین درخواست هایی را ببینیم. اگر در زمان واقعی نمایش داده شود عالی خواهد بود. واقعاً جالب است که آنها را در حالت هشدار قرار دهیم.»

پرس و جوی مثال SQL به عنوان مثال از آن گرفته شده است سایت postgrespro.ru

ما یک سرور Redis راه‌اندازی می‌کنیم و از پلاگین‌های جمع‌آوری شده خود استفاده می‌کنیم، که به Postgres می‌روند و تمام داده‌ها را از آنجا می‌گیرند و معیارها را به Graphite ارسال می‌کنند. اما نام متریک را با هش جایگزین می کنیم. ما به طور همزمان همان هش را به عنوان کلید به Redis و کل پرس و جوی SQL را به عنوان یک مقدار ارسال می کنیم. تنها کاری که باید انجام دهیم این است که مطمئن شویم گرافانا می تواند به Redis رفته و این اطلاعات را بگیرد. ما در حال باز کردن Graphite API هستیم زیرا... این رابط اصلی برای تعامل همه اجزای نظارت با گرافیت است، و ما یک تابع جدید به نام aliasByHash() را در آنجا وارد می کنیم - از Grafana نام متریک را می گیریم و از آن در درخواست Redis به عنوان یک کلید استفاده می کنیم. در پاسخ، مقدار کلید را دریافت می کنیم که همان "پرس و جوی SQL" ما است. بنابراین، ما در Grafana نمایشی از یک پرس و جوی SQL را نمایش دادیم که در تئوری نمایش آن در آنجا غیرممکن بود، همراه با آمار مربوط به آن (تماس ها، ردیف ها، total_time، ...).

نمایش نتایج: از

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

قابلیت اطمینان. همه اجزاء مقاوم در برابر خطا هستند و بارهای ما را به خوبی تحمل می کنند.

مانع ورود کم برای استفاده از این سیستم نیازی به یادگیری زبان های برنامه نویسی و پرس و جو در گرافانا نیست. فقط برنامه خود را باز کنید، سوکتی را در آن وارد کنید که معیارها را به Graphite ارسال می کند، آن را ببندید، Grafana را باز کنید، داشبوردهایی را در آنجا ایجاد کنید و به رفتار معیارهای خود نگاه کنید و اعلان ها را از طریق Moira دریافت کنید.

استقلال. شما می توانید همه این کارها را خودتان بدون کمک مهندسان DevOps انجام دهید. و این یک مزیت است، زیرا شما می توانید پروژه خود را در حال حاضر نظارت کنید، لازم نیست از کسی بخواهید - یا شروع به کار کند یا تغییراتی ایجاد کند.

ما برای چه تلاش می کنیم؟

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

1. آشکارساز ناهنجاری. ما می‌خواهیم سرویسی ایجاد کنیم که به حافظه‌های Graphite ما برود و هر متریک را با استفاده از الگوریتم‌های مختلف بررسی کند. در حال حاضر الگوریتم هایی وجود دارد که می خواهیم آنها را مشاهده کنیم، داده هایی وجود دارد، ما می دانیم که چگونه با آن کار کنیم.
2. فراداده. ما خدمات زیادی داریم، آنها در طول زمان تغییر می کنند، درست مانند افرادی که با آنها کار می کنند. نگهداری مداوم اسناد به صورت دستی یک گزینه نیست. به همین دلیل است که ما اکنون ابرداده ها را در میکروسرویس های خود جاسازی می کنیم. بیان می کند که چه کسی آن را توسعه داده است، زبان هایی که با آنها تعامل دارد، الزامات SLA، کجا و به چه کسی اعلان ها باید ارسال شوند. هنگام استقرار یک سرویس، تمام داده های موجودیت به طور مستقل ایجاد می شوند. در نتیجه، دو پیوند دریافت می کنید - یکی به محرک ها، دیگری به داشبورد در Grafana.
3. نظارت در هر خانه ما معتقدیم که همه توسعه دهندگان باید از چنین سیستمی استفاده کنند. در این صورت، شما همیشه متوجه می شوید که ترافیک شما کجاست، چه اتفاقی برای آن می افتد، کجا سقوط می کند، نقاط ضعفش کجاست. به عنوان مثال، اگر چیزی بیاید و سرویس شما را خراب کند، نه در حین تماس مدیر، بلکه از طریق یک هشدار در مورد آن مطلع خواهید شد و می توانید بلافاصله آخرین گزارش ها را باز کنید و ببینید در آنجا چه اتفاقی افتاده است.
4. عملکرد بالا. پروژه ما دائما در حال رشد است و امروزه حدود 2 مقدار متریک در دقیقه را پردازش می کند. یک سال پیش این رقم 000 بود و رشد همچنان ادامه دارد و این بدان معنی است که پس از مدتی Graphite (نجوا) شروع به بارگذاری شدید زیرسیستم دیسک خواهد کرد. همانطور که قبلاً گفتم، این سیستم نظارتی به دلیل قابلیت تعویض قطعات کاملاً جهانی است. کسی زیرساخت خود را به طور خاص برای Graphite حفظ کرده و دائماً گسترش می دهد، اما ما تصمیم گرفتیم مسیر دیگری را طی کنیم: استفاده کلیک هاوس به عنوان یک مخزن برای معیارهای ما. این انتقال تقریباً کامل شده است و به زودی جزئیات بیشتری را به شما خواهم گفت که چگونه این کار انجام شد: چه مشکلاتی وجود داشت و چگونه بر آنها غلبه شد، روند مهاجرت چگونه پیش رفت، من اجزای انتخاب شده به عنوان الزام آور و تنظیمات آنها را شرح خواهم داد.

با تشکر از توجه شما! سوالات خود را در مورد موضوع بپرسید، سعی می کنم در اینجا یا در پست های بعدی پاسخ دهم. شاید کسی تجربه ساخت یک سیستم نظارت مشابه یا تغییر به Clickhouse را در موقعیت مشابه داشته باشد - آن را در نظرات به اشتراک بگذارید.

منبع: www.habr.com