5 مورد برای ایجاد نظارت پیشرفته برای کارگزار رویداد شما

وقتی صحبت از نظارت بر کارگزار رویداد می شود ، واضح است که هیچ ابزاری برای رد همه آنها وجود ندارد. در حالی که برخی از مشتریان ما از PubSub+ Monitor برای نظارت بر کارگزاران رویداد خود استفاده می کنند ، برخی دیگر با استفاده از ابزارهایی مانند ITRS Geneos ، AppDynamics و Prometheus ، فقط برای نامگذاری چند مورد خود را می سازند. برای کسانی که راه حل شخصی شما را می سازند ، 5 ملاحظاتی که در زیر توضیح خواهم داد ، اطمینان می دهد که نظارت بر کارگزار رویداد شما تمام پایه ها را پوشش می دهد و شما را برای آرامش عملیاتی می کند.

برای شروع ، هر ابزار مانیتورینگ روش خاص خود را برای جمع آوری داده ها از سیستم ها و برنامه های مورد نظر برای نظارت دارد. سپس در بالای آن داده های جمع آوری شده قوانین ، هشدارها و داشبورد ایجاد می کنید. نمونه های موجود در این پست در زمینه استفاده از ITRS Geneos خواهد بود ، با عامل جمع کننده Solgeneos که توسط Solace ارائه شده است ، اما ایده ها به سایر ابزارهای نظارت قابل انتقال هستند.

1. با نظارت بر وضعیت کارگزار رویداد ساده شروع کنید

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

برای مشتریانی که از Solgeneos استفاده می کنند ، نمایش داده های جامع خارج از جعبه برای گزارش در مورد آنها وجود دارد ، مانند "نظارت بر وضعیت HBA".

نمونه ای در زیر از گزارش کارگزار رویداد در مورد وضعیت هر اتصال کانال فیبر زائد به لایه ذخیره سازی که به آن متکی است نشان داده شده است:

نمای داده ای که یکی از پیوندهای فیبر کانال را در حالت "Linkdown" نشان می دهد

2. نظارت بر فعالیت کارگزار رویداد به همان اندازه مهم است

این ملاحظات بعدی ممکن است یک شهودی نباشد-اگر یک کارگزار رویداد برای عملکرد مورد نظر خود استفاده می شود ، چه چیزی برای نظارت بر فعالیت وجود دارد؟دو بعد برای این استدلال وجود دارد:

1. نظارت بر فعالیت استفاده می تواند به تشخیص مسائل مربوط به برنامه ها و خدمات متصل کمک کند.
2. اگر کارگزار شما یک سرویس به صورت اجاره ای مشترک است ، فعالیت نظارت به شما کمک می کند تا متوجه شوید که "همسایگان پر سر و صدا" سرویس را به خطر می اندازند.

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

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

در زیر نمونه ای از نمایش داده ها نشان می دهد که پیام و نرخ داده ها را بر اساس پیام VPN در هر پیام نشان می دهد ، و همچنین نمای کل در کل کارگزار رویداد:

نمای داده ای که نشان می دهد معیارهایی مانند میانگین نرخ بایت و همچنین VPN Toper Talker

نمای فوق با یک افزودنی سفارشی به چارچوب قابل توسعه Solgeneos برای جمع آوری داده ها از طریق SEMP ایجاد شده است. این کد منبع باز در repo solacelabs github موجود است.

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

مثال زیر بالاترین نرخ مشاهده شده به طور خاص برای "نرخ پیام Egress" را در سراسر کارگزار رویداد ، همراه با ضبط 3 VPN برتر توسط تولید ترافیک در آن زمان نشان می دهد. نرخ "بالا" و همچنین علامت های آبی وجود دارد که به صورت روزانه ، هفتگی ، ماهانه و سالانه تنظیم می شود.

نمای داده با یک فیلتر جستجو برای نشان دادن مقادیر بالای علامت آب ضبط شده برای متریک نرخ پیام خروجی فعلی

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

3. از نزدیک به ظرفیت خود توجه کنید

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

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

یک بار دیگر ، پروتکل SEMP باعث می شود که برای استفاده از فعلی هر منبع و حداکثر ، پرس و جو را آسان کنید و نمای مانیتورینگ مانند این را ایجاد کنید:

نمای داده ای که نشان می دهد هر پیام VPN و همچنین مقدار استفاده فعلی آن

قالب "فعلی" در مقابل "حداکثر" برای هر متریک ، ساخت قوانین هدف کلی را نیز آسان می کند. این قانون می تواند به هر دو مقادیر برای محاسبه یک درصد و به صورت پویا هوشیار/محرک در انواع منابع مختلف و مقادیر حداکثر حد دسترسی پیدا کند.

برای بعد دوم اطمینان از محدودیت های کارگزار رویداد با تخصیص تجمعی در هر پیام VPN ، می توانید منظره ای مانند این را ایجاد کنید:

نمای داده ای که نشان دهنده محدودیت های گسترده ، استفاده فعلی و تخصیص فعلی است.

روش دیگر برای در نظر گرفتن این پیام خاص VPN نقطه تخصیص این است: اگر همه مسافران هواپیمایی برای پرواز حاضر شوند ، آیا صندلی های بیشتری از ظرفیت موجود هواپیما به فروش می رسید؟

4- هشدارها را معنی دار و عملی کنید

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

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

• آیا برنامه ای در حال حاضر به صف وجود دارد یا برنامه مورد انتظار پایین است؟
• اگر پر شود ، آیا صف نوع که ناشران بالادست را مسدود می کند و بنابراین به توجه فوری بیشتری نیاز دارد؟

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

یک مثال هشدار برای استفاده از صف بالا ، با اطلاعات اضافی مانند سطح آب بالا و تعداد اتصال به آنها افزایش یافته است

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

یک مانیتور Solgeneos سفارشی برای نمایش مجموعه ای غنی از اطلاعات صف نیز در مخزن GitHub که قبلاً ذکر شد گنجانده شده است.

5- نظارت بر مصنوعی را برای یک رویکرد جامع در نظر بگیرید

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

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

نمای داده ای که آزمایش موفقیت آمیز انتشار و اشتراک را در برابر کارگزار در URI نشان می دهد: london. solace.com

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

نظارت مصنوعی مانند این نه تنها تأیید می کند که پیام رسانی سرتاسر کار می کند، بلکه می تواند تأیید کند که عملکرد در حد تحمل مورد انتظار است و مسائلی مانند ازدحام شبکه یا از دست دادن بسته ها بر تجربه مشتریان پیام رسان متصل به شبکه تأثیر نمی گذارد. کارگزار رویداد

نتیجه

امیدوارم این 5 توصیه به شما آرامش دهد که اگر داشبورد مانیتورینگ سبز باشد، سرویس سالم است. لطفاً برای جزئیات بیشتر در مورد نمونه های مانیتور منبع باز، مخزن GitHub را بررسی کنید.

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