6 מודולים נטענים

1 סקירה כללית

מודולים נטענים מציעים אפשרות מודעת ביצועים להרחבת Zabbix פונקציונליות.

יש כבר דרכים להרחיב את הפונקציונליות של Zabbix באמצעות:

• פרמטרי משתמש (מדדי סוכן)
• בדיקות חיצוניות (ניטור ללא סוכן)
• system.run[] Zabbix סוכן item.

הם עובדים טוב מאוד, אבל יש להם חיסרון גדול אחד, כלומר fork(). זאביקס צריך לחלק תהליך חדש בכל פעם שהוא מטפל במדד משתמש, כלומר לא טוב לביצועים. זה לא עניין גדול בדרך כלל, אבל זה יכולה להיות בעיה רצינית בעת ניטור מערכות משובצות, לאחר א מספר רב של פרמטרים מנוטרים או סקריפטים כבדים עם היגיון מורכב או זמן הפעלה ארוך.

תמיכה במודולים הניתנים לטעינה מציעה דרכים להרחבת סוכן Zabbix, שרת ו-proxy מבלי להקריב את הביצועים.

מודול ניתן לטעינה הוא בעצם ספרייה משותפת המשמשת את Zabbix daemon ונטען בהפעלה. הספרייה צריכה להכיל פונקציות מסוימות, אז שתהליך Zabbix עשוי לזהות שהקובץ הוא אכן מודול שהוא יכול להעמיס ולעבוד עם.

למודולים הניתנים לטעינה יש מספר יתרונות. ביצועים נהדרים ו היכולת ליישם כל היגיון חשובים מאוד, אבל אולי הכי יתרון חשוב הוא היכולת לפתח, להשתמש ולשתף את Zabbix מודולים. זה תורם לתחזוקה ללא בעיות ועוזר לספק פונקציונליות חדשה קלה יותר וללא תלות בבסיס הליבה של Zabbix.

רישוי והפצה של מודולים בצורה בינארית כפופים ל-GPL רישיון (מודולים מקשרים עם Zabbix בזמן ריצה ומשתמשים ב- Zabbix כותרות; כרגע כל קוד Zabbix מורשה תחת רישיון GPL). תאימות בינארית אינה מובטחת על ידי Zabbix.

יציבות API של מודול מובטחת במהלך Zabbix LTS אחד (לטווח ארוך תמיכה) release מחזור. היציבות של Zabbix API אינה מובטחת (טכנית כן אפשר לקרוא לפונקציות פנימיות של Zabbix ממודול, אבל יש אין ערובה שמודולים כאלה יעבדו).

2 API של מודול

על מנת שספרייה משותפת תטופל כמודול Zabbix, זה צריך ליישם ולייצא מספר פונקציות. כרגע יש שישה פונקציות ב-API של מודול Zabbix, שרק אחת מהן היא חובה ו חמשת האחרים הם אופציונליים.

2.1 ממשק חובה

הפונקציה החובה היחידה היא zbx_module_api_version():

int zbx_module_api_version(void);

פונקציה זו אמורה להחזיר את גרסת ה-API המיושמת על ידי מודול זה וכדי שהמודול ייטען גרסה זו חייבת להתאים למודול גרסת API נתמכת על ידי Zabbix. גרסה של מודול API נתמכת על ידי Zabbix הוא ZBX_MODULE_API_VERSION. אז הפונקציה הזו צריכה להחזיר את זה קָבוּעַ. קבוע ישן ZBX_MODULE_API_VERSION_ONE המשמש לכך המטרה מוגדרת כעת שווה ל-ZBX_MODULE_API_VERSION לשימור תאימות מקור, אך השימוש בו אינו מומלץ.

2.2 ממשק אופציונלי

הפונקציות האופציונליות הן zbx_module_init(), zbx_module_item_list(), zbx_module_item_timeout(), zbx_module_history_write_cbs() ו-zbx_module_uninit():

int zbx_module_init(void);

פונקציה זו צריכה לבצע את האתחול הדרוש עבור המודול (אם בכלל). אם זה מצליח, זה אמור להחזיר את ZBX_MODULE_OK. אחרת זה אמור להחזיר את ZBX_MODULE_FAIL. במקרה האחרון Zabbix לא הַתחָלָה.

ZBX_METRIC *zbx_module_item_list(void);

פונקציה זו אמורה להחזיר רשימה של פריטים הנתמכים על ידי המודול. כל פריט מוגדר במבנה ZBX_METRIC, עיין בסעיף להלן לפרטים. הרשימה מסתיימת על ידי מבנה ZBX_METRIC עם שדה "מפתח" של NULL.

void zbx_module_item_timeout(int timeout);

אם המודול מייצא את zbx_module_item_list() אז הפונקציה הזו היא בשימוש על ידי Zabbix כדי לציין את הגדרות הזמן הקצוב בתצורת Zabbix קובץ שבדיקות הפריטים המיושמות על ידי המודול צריכים לציית לו. כאן, הפרמטר "פסק זמן" הוא בשניות.

ZBX_HISTORY_WRITE_CBS zbx_module_history_write_cbs(void);

פונקציה זו אמורה להחזיר פונקציות התקשרות חוזרת אליהן ישתמש שרת Zabbix היסטוריית ייצוא של סוגי נתונים שונים. פונקציות התקשרות חוזרות מסופקות כשדות במבנה ZBX_HISTORY_WRITE_CBS, השדות יכולים להיות NULL אם המודול אינו מעוניין בהיסטוריה של סוג מסוים.

int zbx_module_uninit(void);

פונקציה זו צריכה לבצע את ביטול האתחול הדרוש (אם קיים) כמו שחרור משאבים שהוקצו, סגירת מתארי קבצים וכו'.

כל הפונקציות נקראות פעם אחת בהפעלה של Zabbix כאשר המודול נטען, למעט zbx_module_uninit(), שנקרא פעם אחת בכיבוי של Zabbix כאשר המודול פורק.

2.3 הגדרת פריטים

כל פריט מוגדר במבנה ZBX_METRIC:

מבנה typedef
       {
            char *מפתח;
            דגלים לא חתומים;
            int (*פונקציה)();
            char *test_param;
       }
       ZBX_METRIC;

כאן, מפתח הוא מפתח הפריט (למשל, "dummy.random"), דגלים הוא או CF_HAVEPARAMS או 0 (תלוי אם הפריט יקבל פרמטרים או לא), פונקציה היא פונקציית C המיישמת את פריט (לדוגמה, "zbx_module_dummy_random"), ו-test_param הוא רשימת פרמטרים לשימוש כאשר סוכן Zabbix מופעל עם ה-"-p" דגל (לדוגמה, "1,1000", יכול להיות NULL). הגדרה לדוגמה עשויה להיראות כך זֶה:

מפתחות ZBX_METRIC סטטיים[] =
       {
            { "dummy.random", CF_HAVEPARAMS, zbx_module_dummy_random, "1,1000" },
            { ריק }
       }

כל פונקציה המיישמת פריט צריכה לקבל שני מצביעים פרמטרים, הראשון מסוג AGENT_REQUEST והשני של הקלד AGENT_RESULT:

int zbx_module_dummy_random(AGENT_REQUEST *request, AGENT_RESULT *result)
       {
            ...
       
            SET_UI64_RESULT(result, from + rand() % (to - from + 1));
       
            החזר SYSINFO_RET_OK;
       }

פונקציות אלה צריכות להחזיר את SYSINFO_RET_OK, אם ערך הפריט היה הושג בהצלחה. אחרת, הם צריכים להחזיר את SYSINFO_RET_FAIL. ראה מודול "דמה" לדוגמה למטה לפרטים כיצד להשיג מידע מ-AGENT_REQUEST וכיצד להגדיר מידע סוכן_RESULT.

2.4 אספקת התקשרויות ביצוא היסטוריות

::: שימו לב חשוב ייצוא היסטוריה באמצעות מודול אינו נתמך עוד על ידי פרוקסי Zabbix מאז Zabbix 4.0.0. :::

מודול יכול לציין פונקציות לייצוא נתוני היסטוריה לפי סוג: מספרי (צף), מספרי (לא חתום), תו, טקסט ויומן:

מבנה typedef
       {
            void (*history_float_cb)(const ZBX_HISTORY_FLOAT *history, int history_num);
            void (*history_integer_cb)(const ZBX_HISTORY_INTEGER *history, int history_num);
            void (*history_string_cb)(const ZBX_HISTORY_STRING *history, int history_num);
            void (*history_text_cb)(const ZBX_HISTORY_TEXT *history, int history_num);
            void (*history_log_cb)(const ZBX_HISTORY_LOG *history, int history_num);
       }
       ZBX_HISTORY_WRITE_CBS;

כל אחד מהם צריך לקחת מערך "היסטוריה" של רכיבי "היסטוריה_num" כ טיעונים. בהתאם לסוג נתוני ההיסטוריה שיש לייצא, "היסטוריה" היא מערך של המבנים הבאים, בהתאמה:

מבנה typedef
       {
            zbx_uint64_t itemid;
            שעון int;
            int ns;
            ערך כפול;
       }
       ZBX_HISTORY_FLOAT;
       
       מבנה typedef
       {
            zbx_uint64_t itemid;
            שעון int;
            int ns;
            ערך zbx_uint64_t;
       }
       ZBX_HISTORY_INTEGER;
       
       מבנה typedef
       {
            zbx_uint64_t itemid;
            שעון int;
            int ns;
            const char *ערך;
       }
       ZBX_HISTORY_STRING;
       
       מבנה typedef
       {
            zbx_uint64_t itemid;
            שעון int;
            int ns;
            const char *ערך;
       }
       ZBX_HISTORY_TEXT;
       
       מבנה typedef
       {
            zbx_uint64_t itemid;
            שעון int;
            int ns;
            const char *ערך;
            const char *מקור;
            חותמת זמן int;
            int logeventid;
            חומרת אינט;
       }
       ZBX_HISTORY_LOG;

התקשרויות חוזרות ישמשו את תהליכי סינכרון ההיסטוריה של שרת Zabbix ב- סוף הליך סנכרון ההיסטוריה לאחר כתיבת הנתונים במסד הנתונים של Zabbix ונשמר ב-value cache.

:::הערה חשוב במקרה של שגיאה פנימית במודול ייצוא ההיסטוריה, מומלץ שהמודול ייכתב בצורה כזו שהוא לא יחסום את הניטור כולו עד שהוא מתאושש, אלא משליך נתונים במקום זאת ומאפשר לשרת Zabbix להמשיך לפעול. :::

2.5 בניית מודולים

מודולים אמורים כעת להיבנות בתוך עץ המקור של Zabbix, מכיוון שה-API של המודול תלוי במבני נתונים מסוימים המוגדרים בכותרות Zabbix.

הכותרת החשובה ביותר עבור מודולים הניתנים לטעינה היא include/module.h, אשר מגדיר את מבני הנתונים הללו. כותרות מערכת נחוצות אחרות כי עזרה include/module.h כדי לעבוד כראוי הם stdlib.h ו stdint.h.

עם מידע זה בחשבון, הכל מוכן עבור המודול בנוי. המודול צריך לכלול stdlib.h, stdint.h ו module.h, וסקריפט ה-build צריכים לוודא שהקבצים האלה בנתיב הכלול. ראה מודול "דמה" לדוגמה למטה לפרטים.

כותרת שימושית נוספת היא include/log.h, המגדירה פונקציית zabbix_log(), שניתן להשתמש בה לרישום וניפוי באגים מטרות.

3 פרמטרי תצורה

סוכן Zabbix, שרת ופרוקסי תומכים בשניים פרמטרים להתמודד איתם מודולים:

• LoadModulePath - נתיב מלא למיקום המודולים הניתנים לטעינה
• LoadModule - מודולים לטעינה בעת ההפעלה. המודולים חייבים להיות ממוקם בספריה שצוינה על ידי LoadModulePath או שהנתיב חייב לפני שם המודול. אם הנתיב הקודם הוא מוחלט (מתחיל עם '/') אז מתעלמים מ-LoadModulePath. מותר לכלול מספר פרמטרים של LoadModule.

לדוגמה, כדי להרחיב את סוכן Zabbix נוכל להוסיף את הדברים הבאים פרמטרים:

 LoadModulePath=/usr/local/lib/zabbix/agent/
        LoadModule=mariadb.so
        LoadModule=apache.so
        LoadModule=kernel.so
        LoadModule=/usr/local/lib/zabbix/dummy.so

עם הפעלת הסוכן הוא יטען את ה-mariadb.so, apache.so ו-kernel.so מודולים מהספרייה /usr/local/lib/zabbix/agent בעוד dummy.so ייטען מ-/usr/local/lib/zabbix. זה ייכשל אם מודול הוא חסר, במקרה של הרשאות שגויות או אם ספרייה משותפת אינה א מודול Zabbix.

4 תצורת Frontend

מודולים הניתנים לטעינה נתמכים על ידי סוכן Zabbix, שרת ופרוקסי. לכן, סוג הפריט בממשק הקצה של Zabbix תלוי איפה המודול נמצא עמוס. אם המודול נטען בסוכן, אז סוג הפריט צריך להיות "סוכן Zabbix" או "סוכן Zabbix (פעיל)". אם המודול הוא נטען בשרת או ב-proxy, אז סוג הפריט צריך להיות "פשוט חשבון".

ייצוא היסטוריה דרך מודולי Zabbix אינו זקוק לאף חזית תְצוּרָה. אם המודול נטען בהצלחה על ידי שרת ו מספק פונקציה zbx_module_history_write_cbs() שמחזירה לפחות פונקציית התקשרות חוזרת אחת שאינה NULL ואז ייצוא ההיסטוריה יהיה מופעל אוטומטית.

5 תצורת Frontend

מודולים הניתנים לטעינה נתמכים על ידי סוכן Zabbix, שרת ופרוקסי. לכן, סוג הפריט בממשק הקצה של Zabbix תלוי איפה המודול נמצא עמוס. אם המודול נטען בסוכן, אז סוג הפריט צריך להיות "סוכן Zabbix" או "סוכן Zabbix (פעיל)". אם המודול הוא נטען בשרת או ב-proxy, אז סוג הפריט צריך להיות "פשוט חשבון".

ייצוא היסטוריה דרך מודולי Zabbix אינו זקוק לאף חזית תְצוּרָה. אם המודול נטען בהצלחה על ידי שרת ו מספק פונקציה zbx_module_history_write_cbs() שמחזירה לפחות פונקציית התקשרות חוזרת אחת שאינה NULL ואז ייצוא ההיסטוריה יהיה מופעל אוטומטית.

6 מגבלות

תמיכה במודולים הניתנים לטעינה מיושמת עבור פלטפורמת Unix בלבד. זה אומר שזה לא עובד עבור סוכני Windows.

במקרים מסוימים ייתכן שמודול יצטרך לקרוא תצורה הקשורה למודול פרמטרים מ-zabbix_agentd.conf. זה לא נתמך כרגע. אם אתה צריך את המודול שלך כדי להשתמש בכמה פרמטרים של תצורה שאתה צריך כנראה ליישם ניתוח של קובץ תצורה ספציפי למודול.