הקמת ניטור תשתית Zabbix

הגדרת ניטור תשתית Zabbix

לעתים קרובות אנו נתקלים במצבים שבהם חברה כבר משתמשת ב-Prometheus אך אינה יכולה לכסות ציוד רשת, שרתי Windows ישנים או התקני SNMP. אנו משתמשים ב-Zabbix—מערכת קוד פתוח התומכת באופן טבעי ב-agent push, active checks, SNMP, IPMI ו-JMX. זוהי בחירה אידיאלית עבור תשתית on-premise עם ציוד הטרוגני.

בפרויקט אחד, מצאנו סוכני Zabbix בגרסה 3.0 ושרת בגרסה 6.0. שדרוג כל הסוכנים באמצעות Ansible ארך יומיים, אך לאחר המעבר ל-Zabbix 7.0, עומס מסד הנתונים ירד ב-40% וזמן התגובה לאירועים ירד ב-30%. הניסיון שלנו מאשר: הגדרת Zabbix נכונה מניבה תוצאות מדידות.

למה Zabbix, לא Prometheus?

Prometheus מצוין עבור microservices מבוססי ענן אך נופל בתרחישים עם SNMP, Windows ויישומים legacy. Zabbix מטפל בפי שלושה יותר מדדים על שרת יחיד עם אותם משאבים וקל יותר להגדרה עבור תשתית היברידית. לפי הנתונים שלנו, Zabbix מקצר את זמן פריסת ניטור הרשת ביומיים.

ארכיטקטורה: שרת, Proxy, סוכנים

הגדרת production טיפוסית מורכבת משלוש שכבות. Zabbix Server—הרכיב המרכזי, מאחסן תצורות ונתונים. Zabbix Proxy—מוריד עומס מהשרת ומנטר פלחי רשת מרוחקים. Zabbix Agent 2 (Go, החל מגרסה 5.0)—על כל מארח.

Zabbix Server תובעני לגבי מסד הנתונים—PostgreSQL עדיף על MySQL עבור התקנות גדולות (10k+ פריטים). קריטית היא הגדרת תוסף TimescaleDB עבור PostgreSQL: הוא מפחית משמעותית את עומס ה-I/O בעבודה עם היסטוריית מדדים.

הגדרת /etc/zabbix/zabbix_server.conf—פרמטרים מרכזיים:

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=secret
StartPollers=80
StartPollersUnreachable=20
StartPingers=20
StartTrappers=10
CacheSize=512M
HistoryCacheSize=256M
TrendCacheSize=128M
ValueCacheSize=512M

DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=secret StartPollers=80 StartPollersUnreachable=20 StartPingers=20 StartTrappers=10 CacheSize=512M HistoryCacheSize=256M TrendCacheSize=128M ValueCacheSize=512M ו-CacheSize הם הדברים הראשונים שיש להגדיל ככל שהתשתית גדלה. אם יומן Zabbix Server מציג ValueCacheSize, נתונים מתחילים ללכת לאיבוד.

השוואת רכיבים:

איך להגדיר Low-Level Discovery?

LLD יוצר אוטומטית פריטים וטריגרים עבור ישויות דינמיות: מערכות קבצים, ממשקי רשת, מחיצות Kafka, מופעי PostgreSQL. ה-discovery המובנה cache is full מחזיר JSON עם רשימת מערכות קבצים מותקנות, ועבור כל אחת יוצר אוטומטית פריט vfs.fs.discovery וטריגר כאשר השימוש עולה על 80%.

בעיה נפוצה: discovery יוצר פריטים עבור מערכות קבצים זמניות (tmpfs, devtmpfs), מה שגורם לרעש. זה נפתר באמצעות vfs.fs.size[{#FSNAME},pfree] בכלל ה-discovery עם חריגת regex על Filter. אנו מגדירים מסננים כאלה עבור כל לקוח כדי למנוע אזעקות שווא.

תבניות: הלב של הגדרת Zabbix

כל הכוח של Zabbix טמון במערכת התבניות. תבנית מכילה פריטים (מדדים), טריגרים (תנאי סף), גרפים, כללי discovery. תבנית אחת המחוברת לאלף מארחים—שינוי בתבנית חל על כולם בבת אחת.

תבניות מובנות מכסות 90% מהמשימות: {#FSTYPE}, Linux by Zabbix agent, Nginx by Zabbix agent, PostgreSQL by Zabbix agent. תבניות נוספות זמינות ב-Zabbix Share.

פריט מותאם אישית לניטור גודל תור RabbitMQ באמצעות UserParameter ב-Docker by Zabbix agent:

UserParameter=rabbitmq.queue.messages[*],rabbitmqadmin --host=127.0.0.1 --user=guest --password=guest list queues name messages 2>/dev/null | awk -v q="$1" '$2==q{print $4}' 

לאחר מכן מפתח זה /etc/zabbix/zabbix_agent2.conf מתווסף כפריט בתבנית עם סוג Zabbix agent וטריגר לערך > 10000.

טריגרים והתראות

ביטוי טריגר ב-Zabbix—שפת DSL ייעודית. דוגמה להתראת iowait גבוה:

avg(/Linux-server/system.cpu.util[,iowait],5m)>30 

מאז גרסה 6.0, הופיעו מאקרו ביטויים ופונקציות כמו UserParameter=rabbitmq.queue.messages[*],rabbitmqadmin --host=127.0.0.1 --user=guest --password=guest list queues name messages 2>/dev/null | awk -v q="$1" '$2==q{print $4}' , rabbitmq.queue.messages[critical_queue]. לפי תיעוד Zabbix 7.0, זה מאפשר כתיבת התראות חיזוי: טריגר מופעל לא כשהדיסק מלא, אלא כשבקצב המילוי הנוכחי נותרו פחות מ-4 שעות עד לערך הקריטי.

סוגי מדיה להתראות—Slack, Telegram, PagerDuty, דוא"ל, SMS. מוגדרים דרך Administration → Media Types עם תבניות הודעות ב-JavaScript ייעודי של Zabbix.

מדדי Zabbix מרכזיים:

איך אנו מיישמים Zabbix: תהליך עבודה

1. ביקורת תשתית נוכחית: מלאי מארחים, בדיקת גרסת סוכנים, ניתוח תבניות וטריגרים.
2. עיצוב סכמה: קבוצות מארחים, היררכיית תבניות, מדיניות שמירת היסטוריה.
3. התקנה והגדרה של שרת, proxies, סוכנים (באמצעות תפקיד Ansible).
4. ייבוא תבניות, הגדרת LLD, הגדרת טריגרים ופעולות.
5. בדיקות וניפוי באגים בהתראות.
6. אנו מאמנים את הצוות שלך בתפעול Zabbix.
7. תיעוד ארכיטקטורה ותהליכים.

---
- name: Install Zabbix Agent 2
  hosts: all
  tasks:
    - name: Add Zabbix repository
      apt_repository:
        repo: 'deb http://repo.zabbix.com/zabbix/7.0/ubuntu/ $(lsb_release -sc) main'
      when: ansible_os_family == 'Debian'
    - name: Install agent
      apt:
        name: zabbix-agent2
        state: latest
    - name: Configure agent
      template:
        src: zabbix_agent2.conf.j2
        dest: /etc/zabbix/zabbix_agent2.conf
      notify: restart agent
---

מה כלול בעבודת הגדרת Zabbix שלנו

• ביקורת תשתית נוכחית (זיהוי סוכנים מיושנים, תבניות לא בשימוש).
• עיצוב תוכנית ניטור (קבוצות מארחים, היררכיית תבניות).
• התקנה והגדרה של Zabbix Server, Proxy, Agent 2.
• הגדרת LLD לגילוי משאבים אוטומטי.
• יצירת תבניות וטריגרים מותאמים אישית למשימות שלך.
• אינטגרציה עם מערכות התראות (Telegram, Slack, דוא"ל).
• מסירת תיעוד והדרכה לצוות שלך.
• חודש אחד של תמיכה לאחר היישום.

אנו עובדים עם תשתית מ-50 עד 5000 מארחים. המהנדסים שלנו מחזיקים בהסמכות Zabbix Certified Specialist ויש להם ניסיון של 10+ שנים ב-DevOps. אנו מבטיחים פעולה יציבה של מערכת הניטור והפחתה של 30% בזמן התגובה לאירועים.

לוחות זמנים ועלות

• התקנת Greenfield לתשתית עד 50 מארחים: 2 עד 3 ימים.
• הגירה מגרסת Zabbix קודמת עם שמירת היסטוריה: 3 עד 5 ימים.
• הוספת ניטור רשת וציוד (SNMP): מוסיף 1-2 ימים.

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

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