6 מעקב אחר קובצי יומן

סקירה כללית

ניתן להשתמש ב- Zabbix לניטור וניתוח מרכזי של קבצי יומן עם/בלי תמיכה בסיבוב יומן.

ניתן להשתמש בהודעות כדי להזהיר משתמשים כאשר קובץ יומן מכיל מסוימות מיתרים או דפוסי מיתרים.

כדי לפקח על קובץ יומן אתה חייב להיות:

• סוכן Zabbix פועל על המארח
• הגדרת פריט ניטור יומן

::: שימו לב חשוב מגבלת הגודל של קובץ יומן מנוטר תלויה קובץ גדול support. :::

תצורה

אמת את פרמטרי הסוכן

ודא כי ב-תצורת סוכן file:

• פרמטר 'שם מארח' תואם את שם המארח ב-frontend
• שרתים בפרמטר 'ServerActive' מצוינים עבור עיבוד צ'קים פעילים

תצורת פריט

הגדר [פריט] ניטור יומן (/manual/config/items/item#overview).

כל שדות הקלט החובה מסומנים בכוכבית אדומה.

במיוחד עבור פריטי ניטור יומן שאתה מזין:

תצורת פריט

הגדר [פריט] ניטור יומן (/manual/config/items/item#overview).

כל שדות הקלט החובה מסומנים בכוכבית אדומה.

במיוחד עבור פריטי ניטור יומן שאתה מזין:

חילוץ חלק תואם של ביטוי רגולרי

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

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

שימוש בפרמטר 'פלט' מאפשר לציין את "קבוצת הלכידה" של ההתאמה שבה אנו עשויים להתעניין.

כך, למשל

 log[/path/to/the/file,"הקצאת מאגר תוצאה גדולה.*כניסות: ([0-9]+)",,,,\1]

אמור לאפשר החזרת ספירת הכניסות כפי שנמצא בתוכן של:

 Fr 07 בפברואר 2014 11:07:36.6690 */ מזהה שרשור 1400 (GLEWF) תוצאה גדולה
        הקצאת מאגר - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
        מזהה: 41726453/משתמש: AUser/טופס: CFG:ServiceLevelAgreement

רק המספר יוחזר כי \1 מתייחס ל-ו הראשון קבוצת לכידה בלבד: ([0-9]+).

ועם היכולת לחלץ ולהחזיר מספר, הערך יכול להיות משמש להגדרת טריגרים.

שימוש בפרמטר maxdelay

הפרמטר 'maxdelay' בפריטי יומן מאפשר התעלמות מכמה שורות ישנות יותר מקובצי יומן על מנת לקבל את השורות העדכניות ביותר מנותחות בתוך 'maxdelay' שניות.

::: הערה אזהרה ציון 'maxdelay' > 0 עלול להוביל להתעלמות רשומות קובץ יומן חשובות והתראות שהוחמצו. השתמש בזה בזהירות אצלך בסיכון עצמי רק כאשר יש צורך. :::

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

הגנה מובנית מפני עומס יתר מורכבת מתצורה פרמטר 'maxlines' (מגן על השרת מפני יותר מדי התאמה נכנסת קווי יומן) ומגבלה של 10*'maxlines' (מגן על המעבד המארח והקלט/פלט מפני עומס יתר על ידי סוכן בצ'ק אחד). ובכל זאת, יש 2 בעיות עם הגנה מובנית. ראשית, מספר רב של פוטנציאל הודעות לא כל כך אינפורמטיביות מדווחות לשרת וצורכות מקום בסיס הנתונים. שנית, בשל המספר המצומצם של שורות שנותחו לכל שנית הסוכן עלול לפגר אחרי רשומות היומן החדשות ביותר במשך שעות. דַי סביר להניח שתעדיף לקבל מידע מוקדם יותר לגבי הזרם מצב בקובצי היומן במקום לזחול ברשומות ישנות עבור שעה (ות.

הפתרון לשתי הבעיות הוא שימוש בפרמטר 'maxdelay'. אם 'maxdelay' > 0 מצוין, במהלך כל בדיקה המספר של בתים מעובדים, מספר הבתים הנותרים וזמן העיבוד הוא נמדד. ממספרים אלה הסוכן מחשב עיכוב משוער - כמה שניות ייקח לנתח את כל הרשומות שנותרו ביומן קוֹבֶץ.

אם העיכוב אינו עולה על 'maxdelay' אז הסוכן ממשיך עם מנתח את קובץ היומן כרגיל.

אם ההשהיה גדולה מ'maxdelay' אז הסוכן מתעלם מחלק של קובץ יומן על ידי "קפיצה" מעליו למיקום משוער חדש כך ניתן היה לנתח את השורות הנותרות תוך שניות 'maxdelay'.

שים לב שהסוכן אפילו לא קורא שורות שהתעלמו למאגר, אבל מחשב מיקום משוער לקפוץ אליו בקובץ.

העובדה של דילוג על שורות קובץ יומן נרשמת בקובץ היומן של הסוכן כמו זֶה:

 14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
        logfile:"/home/zabbix32/test1.log" מדלג על 679858 בתים
        (מבית 75653115 לבייט 76332973) כדי לעמוד ב-maxdelay

המספר "to byte" הוא משוער כי לאחר ה"קפיצה" הסוכן מתאים את המיקום בקובץ לתחילת שורת יומן אשר יכול להיות יותר בקובץ או מוקדם יותר.

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

הגדרת 'maxdelay' < 'מרווח עדכון' אינה מומלצת (ייתכן לגרום ל"קפיצות" קטנות תכופות.

הערות על טיפול ברוטציה של קובץ יומן 'copytruncate'

logrt עם האפשרות copytruncate מניח שקובצי יומן שונים יש רשומות שונות (לפחות חותמות הזמן שלהם שונות), לכן סכומי MD5 של בלוקים ראשוניים (עד 512 הבתים הראשונים) יהיו שונה. שני קבצים עם אותם סכומי MD5 של בלוקים ראשוניים אומר זאת אחד מהם הוא המקור, אחר - עותק.

logrt עם האפשרות copytruncate עושה מאמץ לעבד נכון עותקים של קובץ יומן ללא דיווח על כפילויות. עם זאת, דברים כמו הפקת מספר עותקים של קובצי יומן עם אותה חותמת זמן, קובץ יומן סיבוב לעתים קרובות יותר מאשר logrt[] מרווח עדכון פריט, תכוף הפעלה מחדש של הסוכן אינה מומלצת. הסוכן מנסה להתמודד עם הכל מצבים אלה טובים למדי, אך לא ניתן להבטיח תוצאות טובות בכל הנסיבות.

הערות על קבצים קבועים עבור פריטי יומן*[]

מטרת קבצים קבועים

כאשר סוכן Zabbix מופעל הוא מקבל רשימה של צ'קים פעילים מ- Zabbix שרת או פרוקסי. עבור מדדי log*[] הוא מקבל את גודל היומן המעובד ו זמן השינוי למציאת מאיפה להתחיל ניטור קבצי יומן. בהתאם לגודל קובץ היומן בפועל וזמן השינוי המדווח לפי קובץ המערכת הסוכן מחליט להמשיך בניטור קבצי יומן מה- גודל יומן מעובד או -נתח מחדש את קובץ היומן מההתחלה.

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

הפרמטר האופציונלי החדש persistent_dir מציין ספרייה עבור אחסון מצב זה של פריט log[], log.count[], logrt[] או logrt.count[] בקובץ. מצב פריט היומן משוחזר מהקובץ הקבוע לאחר ה- סוכן Zabbix מופעל מחדש.

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

פעולת סוכן עם קובץ מתמיד

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

במהלך פעולת הסוכן הקבצים הקבועים נפתחים לכתיבה (עם fopen(שם קובץ, "w")) והוחלף עם הנתונים העדכניים ביותר. הסיכוי של אובדן נתוני קבצים קבועים אם ההחלפה וראיית מערכת הקבצים מתפצלת לקרות בו זמנית הוא קטן מאוד, אין טיפול מיוחד עבורו. כְּתִיבָה לתוך קובץ מתמשך לא מלווה סנכרון כפוי לאחסון המדיה (fsync() לא נקראת).

החלפה עם הנתונים העדכניים ביותר מתבצעת לאחר דיווח מוצלח של התאמה רשומת קובץ יומן או מטא נתונים (גודל יומן מעובד וזמן שינוי) ל שרת Zabbix. זה עשוי לקרות באותה תדירות שכל פריט בודק אם קובץ היומן נשמר מִשְׁתַנֶה.

אין פעולות מיוחדות במהלך השבתת הסוכן.

לאחר קבלת רשימה של צ'קים פעילים, הסוכן מסמן מיושן כמתמיד קבצים להסרה. קובץ קבוע מתיישן אם: 1) הקובץ המתאים פריט יומן אינו מנוטר עוד, 2) פריט יומן מוגדר מחדש עם פריט אחר מיקום מתמיד_dir מבעבר.

ההסרה מתבצעת באיחור של 24 שעות מכיוון שקובצי יומן במצב NOTSUPPORTED אינם נכללים ברשימת הצ'קים הפעילים אך הם עשויים להפוך לנתמכים מאוחר יותר והקבצים הקבועים שלהם יהיו שימושיים.

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

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

שם ומיקום של קבצים קבועים

סוכן Zabbix מבדיל צ'קים פעילים לפי המפתחות שלהם. לדוגמה, logrt[/home/zabbix/test.log] ו-logrt[/home/zabbix/test.log,] הם פריטים שונים. שינוי הפריט logrt[/home/zabbix/test.log,,,10] ב frontend ל-logrt[/home/zabbix/test.log,,,20] יגרום למחיקת ה- item logrt[/home/zabbix/test.log,,,10] מרשימת הבדיקות הפעילות של הסוכן ויצירת logrt[/home/zabbix/test.log,,,20] פריט (כמה תכונות הן מועברים שינויים ב-frontend/שרת, לא ב-agent).

שם הקובץ מורכב מסכום MD5 של מפתח פריט עם אורך מפתח פריט מצורף כדי לצמצם אפשרות להתנגשות. לדוגמה, מצבו של הפריט logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] להישמר בקובץ מתמשך c963ade4008054813bbc0a650bb8e09266.

פריטי יומן מרובים יכולים להשתמש באותו ערך של persistent_dir.

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

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

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

טען ב-I/O

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

פעולות אם התקשורת נכשלת בין הסוכן לשרת

כל שורה תואמת מפריט log[] ו-logrt[] ותוצאה של כל אחד מהם בדיקת הפריטים log.count[] ו-logrt.count[] דורשת משבצת פנוי ב- אזור ייעודי של 50% במאגר השליחה של הסוכן. רכיבי החיץ הם נשלח באופן קבוע לשרת (או ל-proxy) וחריצי המאגר פנויים שוב.

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

במהלך כשלי תקשורת ארוכים יותר כל חריצי היומן נתפסים וה- הפעולות הבאות ננקטות:

• בדיקת הפריטים log[] ו-logrt[] נעצרת. כאשר התקשורת היא חריצים משוחזרים ופנויים במאגר זמינים התחדש מהעמדה הקודמת. שום קווים תואמים לא הולכים לאיבוד, הם רק מדווחים מאוחר יותר.
• בדיקות log.count[] ו-logrt.count[] מופסקות אם maxdelay = 0 (ברירת מחדל). ההתנהגות דומה ל-'log[]' ו פריטי logrt[] כמתואר למעלה. שימו לב שזה יכול להשפיע תוצאות log.count[] ו-logrt.count[]: לדוגמה, בדיקה אחת סופר 100 שורות תואמות בקובץ יומן, אך מכיוון שאין בחינם חריצים במאגר הבדיקה נעצרת. כאשר התקשורת היא משוחזר הסוכן סופר את אותן 100 שורות תואמות וגם 70 קווים תואמים חדשים. הסוכן שולח כעת ספירה = 170 כאילו היו נמצא בצ'ק אחד.
• log.count[] ו-logrt.count[] בודקים עם maxdelay > 0: if לא הייתה "קפיצה" במהלך הבדיקה, אז ההתנהגות דומה ל מתואר לעיל. אם התרחשה "קפיצה" מעל שורות קובץ יומן הרישום המיקום לאחר "קפיצה" נשמר והתוצאה שנספרה נמחקת. אז, הסוכן מנסה לשמור על קשר עם קובץ יומן הולך וגדל גם במקרה של כשל תקשורת.

Handling of regular expression compilation and runtime errors

If a regular expression used in log[], logrt[], log.count[] or logrt.count[] item cannot be compiled by PCRE or PCRE2 library then the item goes into NOTSUPPORTED state with an error message. To continue monitoring the log item, the regular expression should be fixed.

If the regular expression compiles successfully, but fails at runtime (on some or on all log records), then the log item remains supported and monitoring continues. The runtime error is logged in the Zabbix agent log file (without the log file record).

Note that the logging of regular expression runtime errors is supported since Zabbix 6.0.21.

The logging rate is limited to one runtime error per check to allow Zabbix agent to monitor its own log file. For example, if 10 records are analyzed and 3 records fail with a regexp runtime error, one record is produced in the agent log.

Exception: if MaxLinesPerSecond=1 and update interval=1 (only 1 record is allowed to analyze per check) then regexp runtime errors are not logged.

zabbix_agentd logs the item key in case of a runtime error, zabbix_agent2 logs the item ID to help identify which log item has runtime errors. It is recommended to redesign the regular expression in case of runtime errors.