افزونه مدیریت

افزونه مدیریت RabbitMQ یک API مبتنی بر HTTP را برای مدیریت و نظارت بر گره ها و خوشه های RabbitMQ ، به همراه یک UI مبتنی بر مرورگر و یک ابزار خط فرمان ، RabbitMqadmin فراهم می کند.

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

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

این راهنما پوشش می دهد:

• مدیریت UI و HTTP API
• پیکربندی افزونه عمومی
• چگونه HTTPS را برای مدیریت UI و API اساسی آن فعال کنیم
• چگونه این افزونه در خوشه های چند گره کار می کند
• نحوه غیرفعال کردن مجموعه متریک برای استفاده از پرومتئوس به طور انحصاری برای نظارت بر پشتیبانی ، سیاست امنیت محتوا ، اشتراک منابع متقاطع و سایر کنترل هدر مربوط به امنیت (میزان وفاداری) و فواصل حفظ داده ها
• نحوه تنظیم زمان ورود به سیستم مدیریت UI مدیریت
• نحوه تنظیم مجدد پایگاه داده آمار مورد استفاده این افزونه

و همچنین سایر مباحث مرتبط.

این افزونه همچنین نقاط فرمت را ارائه می دهد که سایر افزونه ها ، مانند RabbitMQ-Top یا RabbitMQ-Boel-Management ، برای گسترش UI استفاده می کنند.

مدیریت UI و سیستم های نظارت خارجی

UI مدیریت و API HTTP آن یک گزینه نظارت داخلی برای RabbitMQ است. این یک گزینه مناسب برای توسعه و در محیط هایی است که نظارت بر خارجی دشوار یا غیرممکن است.

با این حال ، UI مدیریت دارای محدودیت های زیادی است:

• سیستم نظارت با سیستم کنترل شده در هم تنیده شده است
• مقدار مشخصی از سربار
• این فقط داده های اخیر را ذخیره می کند (ساعت ها فکر می کنید ، نه روز یا ماه)
• این یک رابط کاربری اساسی دارد
• طراحی آن بر سهولت استفاده از بهترین در دسترس بودن ممکن تأکید دارد.
• مدیریت UI مدیریت از طریق سیستم برچسب اجازه RabbitMQ (یا یک کنوانسیون در مورد Scopes Token JWT) کنترل می شود

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

• جداسازی سیستم نظارت از سیستم مورد بررسی
• بالای سر
• ذخیره سازی متریک بلند مدت
• دسترسی به معیارهای مرتبط اضافی مانند موارد مربوط به زمان اجرا Erlang
• رابط کاربری قدرتمندتر و قابل تنظیم تر
• سهولت اشتراک داده های متریک: هر دو حالت متریک و داشبورد
• مجوزهای دسترسی متریک مختص RabbitMQ نیستند
• جمع آوری و تجمیع معیارهای خاص گره که نسبت به خرابی گره های فردی مقاومت می کند

RabbitMQ پشتیبانی کلاس اول را برای پرومتئوس و گرافانا از 3. 8 ارائه می دهد. برای محیط های تولید توصیه می شود.

شروع شدن

افزونه مدیریت در توزیع RabbitMQ گنجانده شده است. مانند هر افزونه دیگر ، قبل از استفاده از آن باید فعال شود. این کار با استفاده از Plugins RabbitMq انجام شده است:

راه اندازی مجدد گره پس از فعال سازی افزونه لازم نیست.

در طول استقرار خودکار ، افزونه می تواند از طریق فایل افزونه فعال شده فعال شود.

استفاده

مدیریت UI مدیریت

UI مدیریت را می توان با استفاده از یک مرورگر وب در http: //: 15672/.

به عنوان مثال ، برای گره ای که روی یک دستگاه با نام میزبان WARP10. Local در حال اجرا است ، می توانید توسط کاربران با امتیازات کافی در http: //warp10. local: 15672/یا http: // localhost: 15672/(ارائه شده ارائه شده است. آن LocalHost درست برطرف می شود).

توجه داشته باشید که پورت API UI و HTTP-به طور معمول 15672-از اتصالات AMQP 0-9-1 ، AMQP 1. 0 ، Stomp یا MQTT پشتیبانی نمی کند. درگاه های جداگانه باید توسط آن مشتری ها استفاده شود.

برای دسترسی به UI مدیریت باید به کاربران مجوز اعطا شود.

ویژگی های قابل توجه

UI مدیریت به عنوان یک برنامه صفحه واحد اجرا می شود که به API HTTP متکی است. برخی از ویژگی ها عبارتند از:

• مبادلات ، صف ها ، اتصالات ، کاربران ، میزبان های مجازی و مجوزهای کاربر را اعلام کنید ، لیست کنید و حذف کنید.
• نظارت بر طول صف ، نرخ پیام (در سطح جهانی و در هر صف ، مبادله یا کانال) ، استفاده از منابع صف ، فعالیت GC گره ، نرخ داده های اتصالات مشتری و موارد دیگر.
• نظارت بر منابع گره استفاده: سوکت ها و توصیف کننده های پرونده ، شکست استفاده از حافظه ، فضای دیسک موجود و استفاده از پهنای باند در پیوندهای ارتباطی بین گره.
• مدیریت کاربران (ارائه مجوزهای اداری کاربر فعلی).
• مدیریت خط مشی ها و پارامترهای زمان اجرا (مجوزهای کافی کاربر فعلی را ارائه می دهد).
• طرحواره صادراتی (Vhosts ، کاربران ، مجوزها ، صف ها ، صرافی ها ، اتصالات ، پارامترها ، خط مشی ها) و واردات آن را با شروع گره وارد می کند. این می تواند برای اهداف بازیابی یا اتوماسیون تنظیم گره ها و خوشه های جدید استفاده شود.
• اتصالات مشتری را ببندید ، صف های پاکسازی کنید.
• ارسال و دریافت پیام (در محیط های توسعه و برای عیب یابی مفید است).

برنامه UI از نسخه های اخیر مرورگرهای Google Chrome ، Safari ، Firefox و Microsoft Edge پشتیبانی می کند.

مدیریت UI مدیریت در خوشه ها

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

برای دسترسی به UI مدیریت ، کاربر باید مجوزهای تأیید و مجوزهای خاصی را داشته باشد (مجاز باشد). این در بخش زیر پوشش داده شده است.

دسترسی و مجوزها

UI مدیریت نیاز به احراز هویت و مجوز دارد ، دقیقاً مانند RabbitMQ به اتصال مشتری نیاز دارد. علاوه بر احراز هویت موفقیت آمیز ، مدیریت UI مدیریت توسط برچسب های کاربر کنترل می شود. برچسب ها با استفاده از RabbitMQCTL مدیریت می شوند. کاربران تازه ایجاد شده به طور پیش فرض هیچ برچسب بر روی آنها ندارند.

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

• میزبان های مجازی را که می توانند از طریق AMQP وارد سیستم شوند ، لیست کنید
• مشاهده همه صف ها ، مبادلات و اتصالات در "میزبان مجازی" آنها
• کانال ها و اتصالات خود را مشاهده و ببندید
• مشاهده آمار "جهانی" که شامل همه میزبان های مجازی آنها ، از جمله فعالیت سایر کاربران در درون آنها است

• مشاهده ، ایجاد و حذف خط مشی ها و پارامترهای میزبان مجازی که می توانند از طریق AMQP وارد سیستم شوند

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

• میزبان های مجازی را ایجاد و حذف کنید
• کاربران را مشاهده ، ایجاد و حذف کنید
• مشاهده ، ایجاد و حذف مجوزها
• اتصالات کاربران دیگر را ببندید

توجه داشته باشید که از آنجا که "سرپرست" همه چیز را "نظارت" انجام می دهد ، و "نظارت" همه کارها را انجام می دهد "مدیریت" انجام می دهد ، هر کاربر اغلب به حداکثر یک برچسب نیاز دارد.

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

همه کاربران فقط می توانند اشیاء را در میزبان مجازی که مجوز برای آنها دارند ، لیست کنند.

اگر دسترسی به UI مدیریت به دلیل عدم وجود کاربران با مجوزهای کافی یا مجوزهای فراموش شده/نادرست غیرممکن باشد ، باید از ابزارهای CLI برای مدیریت کاربران و اعتبار آنها استفاده شود. RabbitMQCTL ADD_USER باید برای ایجاد یک کاربر ، RabbitMQCTL SET_PERMISSIONS استفاده شود تا مجوزهای مورد نظر را به کاربر اعطا کند و در آخر ، RabbitMQCTL SET_USER_TAGS باید برای ارائه مجوزهای دسترسی به UI مدیریت کاربر استفاده شود.

نمونه خط فرمان

مثال زیر کاربر با دسترسی کامل به API مدیریت UI/HTTP (مانند همه میزبان های مجازی و ویژگی های مدیریتی) ایجاد می کند:

تأیید اعتبار با OAUTH 2

RabbitMQ را می توان برای استفاده از نشانه های دسترسی OAUTH 2. 0 رمزگذاری شده JWT برای تأیید اعتبار برنامه های مشتری و مدیریت کاربران UI پیکربندی کرد. هنگام انجام این کار ، UI مدیریت به طور خودکار کاربران را برای تأیید اعتبار در برابر سرور OAuth 2 هدایت نمی کند ، این باید به طور جداگانه پیکربندی شود. در حال حاضر ، RabbitMQ در برابر سرورهای مجوز زیر آزمایش شده است:

برای هدایت کاربران به سرور UAA برای تأیید اعتبار ، از پیکربندی زیر استفاده کنید:

مهم: از آنجا که RabbitMQ 3. 10 ، RabbitMQ از نوع اعطای مجوز_ کارت استفاده می کند. جریان ضمنی کاهش یافته است.

احراز هویت اساسی و OAUTH 2 را اجازه دهید

هنگام استفاده از management. enable_uaa = true ، هنوز هم می توان با تأیید هویت اساسی HTTP در برابر API HTTP تأیید کرد. این بدان معنی است که هر دو مثال زیر کار خواهند کرد:

برای تغییر تأیید اعتبار با استفاده از OAUTH 2 منحصراً برای دسترسی به UI مدیریت ، کلید تنظیمات مدیریت را تنظیم کنید.

هنگام تنظیم مدیریت. disable_basic_auth to true ، فقط روش مجوز حامل (مبتنی بر توکن) کار خواهد کرد ، به عنوان مثال:

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

حداقل دامنه مورد نیاز و چگونگی تعیین UI نام کاربری از نشانه

حداقل ، RabbitMQ به دامنه OpenID نیاز دارد زیرا از برخی ادعاها در نشانه شناسه برای تعیین نام کاربری و نمایش این نام کاربری در گوشه سمت راست بالای UI مدیریت استفاده می کند. اگر دامنه OpenID در درخواست مجوز گنجانده شده باشد ، توکن شناسه توسط سرور مجوز بازگردانده می شود.

RabbitMQ ادعای user_name را از id_token می خواند. اگر توکن حاوی user_name نباشد ، RabbitMQ از ادعای فرعی استفاده می کند.

پیکربندی کنید که درخواست های RabbitMQ را به سرور مجوز می دهد

می توان پیکربندی کرد که OAUTH 2. 0 Scopes RabbitMQ باید هنگام هدایت کاربر به سرور مجوز ادعا کند.

If management.enable_uaa = true , by default, RabbitMQ requests the following scopes to UAA: * openid * profile * resource_server_id >.* ، به عنوان مثال. RabbitMq.* اگر Resource_server_id دارای ارزش RabbitMQ بود

با این حال ، اگر management. enable_uaa = نادرست ، RabbitMQ فقط این Scopes را درخواست می کند: * نمایه OpenID *

Which means that you have to configure which scopes you want RabbitMQ requests to the authorization server. It may be resource_server_id > .* if you want to request all scopes or specific ones such as: * resource_server_id > .tag:administrator * resource_server_id >. خواندن:*/*/*

پیکربندی نقطه پایان کشف OpenID Connect

به طور پیش فرض ، RabbitMQ فرض می کند نقطه انتهایی OpenID Connect Discovery در /. well-known/openid-configuration است. اگر نقطه پایانی شما متفاوت است ، می توانید از طریق تنظیمات Management. oauth_metadata_url خود را تنظیم کنید.

RabbitMQ از این نقطه پایانی برای کشف نقاط پایانی دیگر مانند Token Endpoint ، Engout Endpoint و دیگران استفاده می کند.

گردش کار ورود به سیستم

RabbitMQ مشخصات Logout 1. 0 OpenID Connect RP را برای اجرای گردش کار Logout دنبال می کند. این بدان معنی است که هنگام کلیک کاربر بر روی دکمه ورود ، گردش کار Logout از UI مدیریت ایجاد می شود. ورود به سیستم از UI مدیریت RabbitMQ نه تنها کاربر را از خود UI مدیریت بلکه از ارائه دهنده هویت نیز خارج می کند.

دو سناریوی اضافی دیگر نیز وجود دارد که می تواند باعث از بین رفتن شود. یک سناریو هنگامی اتفاق می افتد که نشانه OAuth منقضی می شود. اگرچه RabbitMQ قبل از منقضی شدن نشانه در پس زمینه تجدید می کند ، در صورت منقضی شدن توکن ، کاربر از سیستم خارج شده است. سناریوی دوم زمانی است که جلسه UI مدیریت بیش از حداکثر زمان مجاز پیکربندی شده در زمان ورود به سیستم است.

توجه ویژه به هدر CSP Connect-SRC

برای پشتیبانی از پروتکل OAUTH 2. 0 ، RabbitMQ تماس های استراحت ناهمزمان را به نقطه پایانی Discovery OpenID Connect تبدیل می کند. اگر سرنوشت های پیش فرض CSP را نادیده می گیرید ، باید مطمئن شوید که دستورالعمل Connect-SRC CSP Whitelists The OpenID Connect Discovery Endpoint.

به عنوان مثال ، اگر عنوان CSP را با مقدار پیش فرض-SRC "خود" تنظیم کرده اید ، به طور پیش فرض ، تنظیم Connect-Src 'self' را تنظیم می کنید که به این معنی است که شما دسترسی RabbitMQ به هر نقطه پایانی خارجی را انکار می کنید. از این رو غیرفعال کردن OAUTH 2. 0.

علاوه بر هدر Conn Connect-SRC CSP ، RabbitMQ همچنین به دستورالعمل های CSP بدون خط ناامن ناآرامی نیاز دارد ، در غیر این صورت ممکن است عملکرد OAUTH 2. 0 کار نکند.

HTTP API

نقاط پایانی API

هنگام فعال شدن ، افزونه مدیریت یک API HTTP را در http: // name سرور: 15672/ API/ به طور پیش فرض ارائه می دهد. برای اطلاعات بیشتر در مورد API به آن مکان مرور کنید. برای راحتی ، همان مرجع API در GitHub در دسترس است.

HTTP API و نظارت

API در نظر گرفته شده است که برای کارهای اساسی مشاهده استفاده شود. پرومتئوس و گرافانا برای ذخیره طولانی مدت متریک ، هشدار ، تشخیص ناهنجاری و غیره توصیه می شود.

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

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

مشتری ها و ابزارهای HTTP API

RabbitMqadmin یک ابزار خط فرمان پایتون است که با API HTTP در تعامل است. می توان آن را از هر گره RabbitMQ که دارای افزونه مدیریت است در http: //: 15672/ cli/ فعال کنید.

برای مشتریان HTTP API به چند زبان ، به ابزارهای توسعه دهنده مراجعه کنید.

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

پیکربندی

چندین گزینه پیکربندی وجود دارد که بر افزونه مدیریت تأثیر می گذارد. اینها از طریق پرونده اصلی پیکربندی RabbitMQ مدیریت می شوند.

پیکربندی HTTP API و مدیریت UI برای استفاده از یک درگاه یا رابط شبکه متفاوت ، فعال کردن HTTPS و غیره امکان پذیر است.

در حالی که به ندرت مورد نیاز است ، می توان چندین شنونده (درگاه) را پیکربندی کرد ، به عنوان مثالبرای فعال کردن HTTPS و حفظ پشتیبانی از مشتریانی که فقط می توانند از HTTP (بدون TLS) استفاده کنند.

پورت با استفاده از کلید Management. tcp. port پیکربندی شده است:

می توان با استفاده از کلید Management. tcp. ip ، پیکربندی کرد که از نقطه پایانی API استفاده خواهد کرد ، به طور مشابه با شنوندگان پروتکل پیام رسانی:

برای بررسی اینکه از چه رابط و پورت توسط یک گره در حال اجرا استفاده می شود ، از RabbitMQ-Diagnostics استفاده کنید:

https

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

گزینه های بیشتر TLS را می توان برای شنونده HTTPS پیکربندی کرد.

مثال فوق در قالب کلاسیک پیکربندی:

با استفاده از http و https

استفاده از HTTP و HTTPS در درگاه های مختلف امکان پذیر است:

از همان کلیدهای پیکربندی می توان برای پیکربندی یک شنونده واحد (فقط HTTP یا HTTPS) استفاده کرد و با مواردی که توسط Web Stomp و Web MQTT استفاده می شود مطابقت داشته باشد.

گزینه های پیشرفته HTTP

Cowboy ، سرور وب جاسازی شده مورد استفاده توسط افزونه مدیریت ، تعدادی از گزینه ها را ارائه می دهد که می تواند برای سفارشی کردن رفتار سرور استفاده شود. بیشتر گزینه ها در RabbitMQ 3. 7. 9 معرفی شده اند.

فشرده سازی پاسخ

فشرده سازی پاسخ به طور پیش فرض فعال است. برای فعال کردن صریح ، از Management. tcp.compress استفاده کنید:

زمان عدم فعالیت مشتری

برخی از نقاط پایانی API HTTP به سرعت پاسخ می دهند ، برخی دیگر ممکن است نیاز به بازگشت یا پخش مجموعه داده های قابل توجهی به مشتری (به عنوان مثال هزاران اتصال) داشته باشند یا عملیاتی را انجام دهند که به طور متناسب با ورودی طول می کشد (به عنوان مثال وارد کردن یک پرونده تعاریف بزرگ). در این موارد ، مدت زمان لازم برای پردازش درخواست می تواند از زمان های خاصی در سرور وب و همچنین HTTP Client فراتر رود.

با استفاده از گزینه های Management. tcp. idle_timeout ، Management. TCP. Inactivity_Timeout ، Management. Tcp. Request_Timeout امکان پذیر است.

• Management. tcp. Inactivity_Timeout کنترل HTTP (S) زمان عدم فعالیت TCP مشتری را کنترل می کند. با رسیدن به آن ، اتصال توسط سرور HTTP بسته می شود.
• management. tcp. request_timeout پنجره زمانی را که مشتری مجبور به ارسال درخواست HTTP است ، کنترل می کند.
• management. tcp. idle_timeout پنجره زمانی را که مشتری مجبور است داده های بیشتری (در صورت وجود) را در چارچوب درخواست HTTP ارسال کند ، کنترل می کند.

اگر یک متعادل کننده بار یا پروکسی بین مشتری HTTP و سرور HTTP مدیریت استفاده شود ، مقادیر غیرفعال_ زمان و IDLE_TIMEOUT باید حداقل به اندازه بزرگ و اغلب بیشتر از مقادیر زمان بندی و عدم تحرک مورد استفاده توسط توازن بار باشد.

در اینجا چند قطعه پیکربندی مثال وجود دارد که زمان بندی را تغییر می دهند:

همه مقادیر در میلی ثانیه هستند. پیش فرض آنها متفاوت است:

• management. tcp. inactivity_timeout پیش فرض 300 ثانیه است
• management. tcp. request_timeout به طور پیش فرض 60 ثانیه است
• management. tcp. idle_timeout پیش فرض 5 ثانیه است

توصیه می شود اگر عدم تحرک یا زمان کار بیکار نیاز به تغییر داشته باشد ، Management. tcp. Inactivity_Timeout باید با مدیریت مطابقت داشته باشد یا بیشتر از آن باشد. tcp. idle_timeout.

Management. tcp. Request_Timeout به طور معمول نیازی به افزایش ندارد زیرا مشتریان اندکی پس از برقراری اتصال TCP درخواست ارسال می کنند.

ورود به سیستم HTTP

برای ایجاد موارد دسترسی ساده از درخواست ها به API HTTP ، مقدار مدیریت را تنظیم کنید. http_log_dir در مسیر یک دایرکتوری که در آن می توان سیاههها ایجاد کرد:

برای تغییر اثر ، افزونه یا گره را مجدداً راه اندازی کنید.

فاصله آمار

به طور پیش فرض سرور رویدادهای آماری را هر 5 ثانیه (5000 میلی ثانیه) منتشر می کند. مقادیر نرخ پیام نشان داده شده در افزونه مدیریت در این دوره محاسبه می شود.

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

برای انجام این کار ، مقدار کلید تنظیمات collect_statistics_interval را در فاصله مورد نظر در میلی ثانیه تنظیم کرده و گره را مجدداً راه اندازی کنید:

نرخ پیام

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

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

از طرف دیگر ، نرخ پیام می تواند به طور کلی غیرفعال شود. این می تواند به کاهش مصرف منابع CPU از افزونه کمک کند.

حالت نرخ پیام توسط کلید تنظیمات Management. Rates_Mode کنترل می شود:

مقادیر پشتیبانی شده اساسی (پیش فرض) ، مفصل و هیچ کدام نیستند.

نمونه (نقطه داده) نگهداری

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

سه سیاست وجود دارد:

• جهانی: چه مدت می تواند داده ها را برای صفحات مروری و میزبان مجازی حفظ کند
• اساسی: چه مدت برای حفظ داده ها برای اتصالات ، کانال ها ، مبادلات و صف ها
• مفصل: چه مدت برای حفظ داده ها برای نرخ پیام بین جفت اتصالات ، کانال ها ، مبادلات و صف ها (همانطور که در زیر "شکست نرخ پیام" نشان داده شده است)

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

پیکربندی در مثال بالا داده های جهانی را با وضوح 5 ثانیه (نمونه برداری هر 5 ثانیه اتفاق می افتد) به مدت یک دقیقه ، سپس در یک وضوح 1 دقیقه (60 ثانیه) به مدت 1 ساعت ، سپس با وضوح 20 دقیقه ای برای یک روز حفظ می کند. این داده های اساسی را با وضوح 5 ثانیه به مدت 1 دقیقه ، در وضوح 1 دقیقه (60 ثانیه) به مدت 1 ساعت و داده های دقیق فقط به مدت 10 ثانیه حفظ می کند.

هر سه سیاست اجباری است و باید حداقل یک تنظیم نگهدارنده (دوره) داشته باشد.

آمار و جمع آوری متریک را غیرفعال کنید

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

به منظور غیرفعال کردن کامل مجموعه معیارهای داخلی ، پرچم Disable_Metrics_Collector باید در افزونه RabbitMQ_Management_Agent تنظیم شود. افزونه پرومتئوس حتی اگر مجموعه غیرفعال باشد ، هنوز هم کار خواهد کرد.

غیرفعال کردن مجموعه Metrics در صورت استفاده از یک سیستم نظارت خارجی ، گزینه ارجح است ، زیرا این امر باعث کاهش سربار جمع آوری آمار و جمع آوری آمار در کارگزار می شود. اگر آمار فقط غیرفعال موقت باشد ، یا در برخی از نمایش داده های API HTTP مورد نیاز نیست ، می توان تجمع آمار را در افزونه RabbitMQ_Management غیرفعال کرد. پرچم غیرفعال نیز می تواند به عنوان بخشی از رشته پرس و جو در URI منتقل شود.

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

در زیر یک نمونه پیکربندی وجود دارد که آمار را غیرفعال می کند اما تعداد صف های فردی را در صفحه صف ها برمی گرداند:

خط مشی امنیت محتوا (CSP)

می توان پیکربندی کرد که مقدار هدر CSP توسط پاسخ های HTTP API استفاده می شود. مقدار پیش فرض Script-Src 'self' 'ناامن' '' 'ansafe-incline' است. Object-Src 'self':

مقدار می تواند هر رشته هدر CSP معتبر باشد:

کارتهای وحشی نیز مجاز هستند:

از یک دستورالعمل فریم و فریم های سیاست CSP می توان برای جلوگیری از تعبیه فریم UI مدیریت استفاده کرد و انواع خاصی از حملات اسکریپت های قاب را کاهش داد:

امنیت حمل و نقل سخت (HSTS)

می توان پیکربندی کرد که چه مقدار هدر امنیتی حمل و نقل حمل و نقل توسط پاسخ های API HTTP استفاده می شود:

اشتراک منابع متقاطع (CORS)

برنامه UI مدیریت به طور پیش فرض از دسترسی به وب سایت های میزبانی شده در مبدا های مختلف با استفاده از مکانیسم اشتراک منابع متقاطع ، که به عنوان COR نیز شناخته می شود ، امتناع می ورزد. منشأ لیست سفید امکان پذیر است:

این امکان وجود دارد که به هر منشاء استفاده از API با استفاده از کارت وحشی اجازه دهد. این امر برای استقرار در جایی که برنامه UI ممکن است در معرض دید عموم باشد ، بسیار دلسرد می شود.

درخواست های قبل از پرواز CORS توسط مرورگر ذخیره می شود. افزونه مدیریت به طور پیش فرض 30 دقیقه ای را تعریف می کند. مقدار قابل تغییر است. در ثانیه پیکربندی شده است:

سایر هدرهای مربوط به امنیت

می توان چند عنوان بیشتر مربوط به امنیت را برای پاسخ های مدیریت UI و HTTP API تنظیم کرد. توجه داشته باشید که برخی از آنها توسط CORS و سایر توسعه های جدیدتر در فضای امنیتی مرورگر کنار گذاشته شده اند.

هدرهای پشتیبانی شده عبارتند از:

آنها را می توان با CORS فوق الذکر ، HSTS ، هدرهای CSP ترکیب کرد:

زمان ورود به سیستم

پس از ورود کاربر ، جلسه ورود به سیستم UI کاربر پس از 8 ساعت به طور پیش فرض منقضی می شود. با استفاده از تنظیمات login_session_timeout می توان یک زمان بندی متفاوت را پیکربندی کرد.

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

مثال زیر زمان جلسه جلسه را به 1 ساعت تعیین می کند:

پیشوند مسیر

برخی از محیط ها برای استفاده از پیشوند سفارشی برای کلیه درخواست های HTTP به افزونه مدیریت نیاز دارند. تنظیمات Management. Path_Prefix اجازه می دهد تا پیشوند دلخواه برای همه دستگیرندگان درخواست HTTP در افزونه مدیریت تنظیم شود.

تنظیم مدیریت. PATH_PREFIX به/پیش نویس من تمام درخواست های API را برای استفاده از میزبان URI مشخص می کند: Port/My-PREFIX/API/[.]

صفحه ورود به سیستم مدیریت UI دارای میزبان URI خواهد بود: Port/ M y-Prefix/ - توجه داشته باشید که در این مورد برش دنباله دار لازم است.

مثال

یک فایل پیکربندی مثال برای RabbitMQ که در ورود به سیستم درخواست می شود ، فاصله آمار را به 10 ثانیه افزایش می دهد و صریحاً پارامترهای مرتبط دیگر را به مقادیر پیش فرض خود تنظیم می کند ، به این شکل است:

تعاریف بارگیری (طرحواره) در هنگام راه اندازی

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

تعاریف را می توان از طریق RabbitMQCTL یا API HTTP ارائه شده توسط این افزونه ، از جمله RabbitMqadmin صادر و وارد کرد.

مجموعه معیارها و API HTTP در خوشه ها

درخواست مشتری

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

در حال اجرا افزونه مدیریت روی زیر مجموعه گره ها

می توان افزونه مدیریت را فقط در زیر مجموعه ای از گره های خوشه ای مستقر کرد. در این حالت فقط گره هایی که افزونه را اجرا می کنند ، می توانند به درخواست های API مشتری HTTP ارائه دهند. برای اینکه هر گره خوشه ای معیارهای خود را جمع آوری کند ، هنوز هم لازم است که افزونه Agent-Agent-Management-Management در هر گره فعال شود ، در غیر این صورت معیارهای حاصل از گره در دسترس نخواهد بود.

نمایش داده های تجمع در خوشه ها

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

(معکوس HTTP) تنظیم پروکسی

می توان UI وب را از طریق هر پروکسی که با RFC 1738 مطابقت داشته باشد در دسترس قرار دهد. نمونه زیر پیکربندی Apache حداقل دستورالعمل های لازم را برای کابین آپاچی در انطباق نشان می دهد. این یک رابط کاربری وب در پورت پیش فرض 15672 را فرض می کند:

راه اندازی مجدد پایگاه داده آمار

پایگاه داده آمار کاملاً در حافظه ذخیره می شود. تمام محتویات آن گذرا است و باید به این ترتیب رفتار شود.

در نسخه های مدرن ، گره ACH دارای پایگاه داده آمار خاص خود است که حاوی کسری از آمار ثبت شده در این گره است.

با استفاده از RabbitMQCTL یا یک نقطه پایانی API HTTP می توان پایگاه داده STAT را روی یک گره معین مجدداً راه اندازی کرد:

برای تنظیم مجدد کل بانک اطلاعاتی آمار در همه گره ها ، استفاده کنید

تجزیه و تحلیل استفاده از حافظه و مدیریت حافظه

UI Management می تواند برای بازرسی از حافظه گره ، از جمله نمایش یک تجزیه و تحلیل در هر گروه استفاده شود. برای جزئیات بیشتر به راهنمای تحلیل استفاده از حافظه مراجعه کنید.

بانک اطلاعاتی مدیریت در حدود آمار ساطع شده دوره ای ، تنظیم شده توسط فاصله آماری که در بالا شرح داده شده است ، یا هنگامی که برخی از مؤلفه ها ایجاد و اعلام می شوند (به عنوان مثال یک اتصال یا کانال جدید باز می شود ، یا یک صف اعلام می شود) یا بسته/حذف می شود. نرخ پیام به طور مستقیم بر استفاده از حافظه پایگاه داده مدیریت تأثیر نمی گذارد.

مقدار کل حافظه مصرف شده توسط بانک اطلاعاتی آمار بستگی به اندازه توپولوژی (به عنوان مثال تعداد صف ها) ، تعداد اتصالات و کانال های همزمان ، فاصله انتشار رویداد ، حالت نرخ مؤثر و سیاست های حفظ دارد.

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

افزایش ارزش فاصله به 30-60s باعث کاهش ردپای CPU و اوج مصرف حافظه برای سیستم هایی با مقادیر زیادی از اتصالات ، کانال ها و صف ها می شود. این امر با روند نزولی همراه است: معیارهای موجودات مذکور هر 30-60 ثانیه را تازه می کنند. این می تواند در یک سیستم تولیدی تحت نظارت خارجی کاملاً منطقی باشد اما باعث می شود UI مدیریت برای استفاده از اپراتورها راحت تر باشد.

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

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

پایگاه داده آمار را می توان دوباره راه اندازی کرد (به بالا مراجعه کنید) و در نتیجه مجبور به انتشار تمام حافظه شد. صفحه نمای کلی مدیریت UI شامل دکمه هایی است که پایگاه داده آمار را برای گره های جداگانه و همچنین تمام گره های موجود در خوشه تنظیم می کند.

انتشار و مصرف بیش از HTTP API

انتشار و مصرف پیام با استفاده از API HTTP امکان پذیر است. این روش پیام رسانی دلسرد می شود: یکی از پروتکل های پیام رسانی باینری را که توسط RabbitMQ پشتیبانی می شود ، ترجیح دهید. انتشار و مصرف از این طریق به طور قابل توجهی کارآمدتر خواهد بود و دسترسی به ویژگی های مختلف پروتکل پیام رسانی مانند تأیید را فراهم می کند.

انتشار از طریق HTTP API می تواند در محیط هایی که اتصالات پروتکل پیام رسانی طولانی مدت گزینه ای نیست ، مفید باشد.

کمک و ارائه بازخورد

اگر در مورد محتوای این راهنما یا هر موضوع دیگری که مربوط به RabbitMQ است ، سؤالی دارید ، دریغ نکنید که از آنها در لیست پستی RabbitMQ سؤال کنید.

به ما در بهبود اسناد کمک کنید

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