رایگان

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

عدم وجود محدودیت در راه اندازی تعداد پراکسی

کارایی زبیکس

مزیت اصلی پروکسی ها از نظر عملکرد این است که بار از سرور زبیکس به پروکسی توزیع می شود.

قبل از بیان این مطلب بیایید  انواع پارامتر های زبیکس و تاثیر آن بر عملکرد مانیتورینگ را بصورت کلی بررسی کنیم.

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

با دستور زیر نگاهی به پراکسی های زبیکس می اندازیم.

ps -ef | grep zabbix_server

سرور زبیکس تعدادی فرایند دارد که توسط دستور بالا قابل مشاهده می باشند. این دستورات به ما این امکان را می دهند که لیستی از Timer ها ، Housekeeper ها ، poller ها ، Trapper ها History syncer ها ، Unreachable poller ها و … را مشاهده کنیم. هر کدام از این سرویس ها برای بررسی برخی خدمات در سیستم اجرا شده اند. از این رو اگر نوع یک آیتم را Zabbix Agent انتخاب کنیم Poller برای انجام عملیات های مربوط به آن آیتم خبر رسانی می کند.

و اگر نوع یک آیتم را  Zabbix Agent Active انتخاب کنیم Trapper برای انجام عملیات های مربوط به آن آیتم خبر رسانی می کند. به این دلیل است که agent زبیکس اقدام به ارسال داده می کند و trapper دریافت آن را به عهده دارد.

اگر بخواهیم مثالی هم برای Unreachable poller بزنیم، این فرایند وضعیت هاست را بررسی میکند. بررسی می کنه که آیا Agent ، SNMP ، JMX یا IPMI در دسترس هست؟ و اگر در دسترس باشد آن را (در محیط واسط کاربری وب) سبز کرده و در صورت عدم وجود آن را قرمز نمایش می دهد.

اگر از این پارامتر استفاده کنید 5000 مقدار جدید در ثانیه می توانید منتقل کنید.

5000 NVPS (New Value Per Seconds)

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

ممکن است SNMP نسخه 1 از SNMP نسخه 2 و 3 سریع تر باشد اما باعث می شود امنیت این ارتباط پایین تر باشد.

از این رو اکثر استفاده کنندگان از SNMP نسخه 3 استفاده می کنند. مشروط بر آن که دستگاه های تحت شبکه از آن این نسخه SNMP پشتیبانی کنند.

برخی انواع دیگر پارامتر های مفید که باعث کندی در ارتباط می شوند

External checks

که برای اجرای script های سفارشی استفاده می شوند.

UserParameters

که برای zabbix agent استفاده می شوند و جزئیاتی بیشتر از پارامتر های داخلی زبیکس به ما ارائه می دهند.

هر کدام از Poller های زبیکس زمانی جهت هماهنگی جمع آوری های این داده ها صرف می کنند.

حال فرض کنید هزار هاست (H1 تا H1000) داریم که هر کدام برای poller زمانی معادل 0.3 ثانیه تاخیر ایجاد کنند.

0.3 x 1000 = 300

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

پس جمع آوری پارامتر ها (از Agent ها) توسط خود زبیکس ایجاد تاخیر در سیستم می کند.

از این رو اگر از Proxy زبیکس استفاده کنیم بسیاری از این تاخیر ها و بارهای پردازشی را به سیستم پراکسی منتقل می کنیم.

از این رو سرور زبیکس کمتر بار پردازشی و بار مسیر انتقال را به دوش می کشد.

گم نشدن داده ها و دیر رسیدن آیتم ها

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

راهکار

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

امنیت و تاخیر امنیت

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

راهکار برای تاخیر امنیت

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

شگفت انگیز نیست؟!

با پراکسی زبیکس فکری به حال عدم دسترسی کنید

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

تاخیر پایگاه داده

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

راهکار تاخیر پایگاه داده

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

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

جریان داده ها در زبیکس با استفاده از پراکسی

زبیکس یک نایب یا واسط یا پراکسی در موقعیت مکانی دیگر قرار می دهد.

ویژگی های موقعیت مکانی به شرح زیر است:

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

برای محاسبه تاخیر بدست آمده توسط داده های ارسال شده از سرور زبیکس از ابزار zabbix_get استفاده می کنیم.

time zabbix_get -s  [localhost_IP] -k [name_of_the_parameter]

با دستور بالا زمان سپری شده برای پارامتر مورد نظر از طریق agent مورد نظر بدست می آید. مثلا ممکن است 0.3 ثانیه دریافت شود.

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

تا قبل از نسخه 4.2 پراکسی ها تنها داده ها را به سرور منتقل می کردند، جایی که داده ها ذخیره می شدند و اگر نیاز بود (سمت سرور) روی داده ها یک سری پیش پردازش ها، تریگر ها ، محاسبات، عملیات ها یا اطلاع رسانی ها انجام می شد.

اما از نسخه 4.2 پیش پردازش ها (preprocessing) ها را میتوان در سمت پراکسی انجام داد. آیتم های پیش فرض زیادی وجود دارند که با مراحل پیش پردازش پیکربندی می شوند.

مراحل پیش پردازش، از قبیل عبارت باقائده (regular expressions) ، جاوا اسکریپت، XML XPath، JSON Path ، تغییر ساده ، تغییر در ثانیه ، نیز به منابع و وقت و عملکرد زیادی از سرور احتیاج دارند. پس چرا باید این بار پیش پردازش را بردوش سرور قرار دهیم و آن را بر دوش پراکسی قرار ندهیم؟

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

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

ما برای آشنایی همه جوره با محتوای زبیکس سعی نموده ایم تا دوره جامع زبیکس 5 را تهیه و مانیتورینگ تمامی سیستم ها و تجهزات را درون آن بررسی کنیم. مفهوم پراکسی نیز دروه آن مورد بررسی قرار گرفته و ارائه شده است.

نتیجه

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

در محیط های این چنین بزرگ که پردازش ها بدین شکل ارتقاع می یابند. می توانید از سیستم های قدرتمند تر استفاده کنید اما این کار هزینه بر است. مثلا میزان RAM و CPU و  فضای ذخیره سازی سرور را اضافه کنید یا این که از پراکسی استفاده کنید تا میزان منابع مورد نیاز کم گردد. بر همین اساس سرور شما تنها می تواند با حداقل منابع مانند 2 هسته (core) برای CPU و 4 گیگابایت RAM مورد استفاده قرار گیرد.

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

منابع

وبلاگ زبیکس