תמחור Azure Log Analytics: איך למנוע מהוצאות ניטור הענן של Azure לזנק

By Mirko Peters · 2026-10-23

למדו כיצד לשלוט במחירי Azure Log Analytics, לייעל תוכניות טבלאות בסביבת העבודה, לסנן רעש בקליטת הנתונים ולמנוע מהוצאות ניטור הענן לזנק.

Automatically translated with AI from the original post. Read the English original

שליטה במחירי Azure Log Analytics דורשת הבנה של נפח הקליטה, תוכניות הנתונים של הטבלאות ועלויות השמירה לטווח ארוך. על ידי סינון מוקדם של נתונים באמצעות KQL, בחירת תוכניות שכבה מתאימות כמו Basic ו-Auxiliary, והימנעות ממגבלות איסוף יומיות מסוכנות, מנהלי מערכת יכולים למנוע מחשבונות ניטור Azure לצאת משליטה.

עיקרי הדברים

• מחיר Azure Log Analytics נקבע בעיקר לפי נפח הנתונים שנקלטים ולפי משך השמירה שלהם באחסון.
• תוכניות הטבלאות משנות את ההוצאות באופן דרמטי: אחסון Basic יכול להיות זול משמעותית מ-Analytics הסטנדרטי, ותוכניות Auxiliary מציעות הנחות קיצוניות לנתוני ארכיון בנפח גדול.
• סינון שורות לוג רועשות ולא נקראות בקצה, באמצעות כללי איסוף נתונים, הוא המנוף היעיל ביותר להפחתת עלויות ניטור הענן.
• הסתמכות על מגבלות קליטה יומיות קשיחות עלולה להעמיד בסיכון את צוותי האבטחה והתפעול, כי היא עוצרת את כל איסוף הנתונים באמצע היום.
• איזון בין חלונות שמירה אינטראקטיביים לאחסון קר לטווח ארוך מבטיח עמידה בדרישות הציות בלי לשלם יתר על המידה עבור יכולות שאילתה מהירות.

גורמי העלות האמיתיים של Log Analytics

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

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

ניווט בין תוכניות טבלאות: Analytics, Basic ו-Auxiliary

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

שכבת Analytics סטנדרטית

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

שכבות Basic ו-Auxiliary

עבור נתונים שבודקים רק בתגובה לתקלה, או רשומות בנפח גבוה שנשמרות אך ורק לצורכי ביקורת, התוכניות Basic ו-Auxiliary מציעות חיסכון דרמטי. בעוד ש-Analytics הסטנדרטי עשוי לעלות בסביבות 2.30$ לגיגה-בייט, תוכניות Basic יכולות להוריד את המחיר בצורה משמעותית, ושכבות Auxiliary יכולות לדחוף את העלויות לשבר ממחירי התקן (לעיתים עד פי 46 זול יותר בתחתית הסקאלה).

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

איך לצמצם עלויות באמצעות סינון מוקדם וכללי איסוף נתונים

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

הגישה הנכונה משתמשת בכללי איסוף נתונים (DCRs) יחד עם Azure Monitor Agent. כללי DCR פועלים כסטים של הוראות שנפרסים על פני מכונות וירטואליות ואשכולות קונטיינרים. הם קובעים בדיוק אילו אירועים לאסוף, כיצד לעצב אותם ולאיזו טבלה להכניס אותם. והחשוב מכל: הם מאפשרים להשליך רעש חוזר כבר במקור.

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

הסכנה במגבלות קליטה יומיות

מול חשבונות ענן בלתי צפויים, מנהלי כספים ו-IT רבים מסתכלים על תכונת המגבלה היומית של Azure Log Analytics כעל רשת ביטחון מוחלטת. מגבלה יומית קובעת תקרה קשיחה לקליטת נתונים; לאחר שהסף מושג, סביבת העבודה מפסיקה לקבל רשומות חדשות עד סוף היום.

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

איזון בין שמירה אינטראקטיבית לארכיונים ארוכי טווח

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

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

סיכום והצעדים הבאים

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

כדי להעמיק בעקרונות הבסיסיים של אופן פעולת המערכות האלה, הקפידו להאזין לפרק המלא של M365 FM Podcast להסבר נטול ז'argon על סביבות עבודה, טבלאות ויסודות שאילתות KQL.

שאלות נפוצות

האם יצירת סביבת עבודה של Azure Log Analytics היא חינמית?

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

מה ההבדל בין תוכניות היומנים Analytics, Basic ו-Auxiliary?

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

מדוע כדאי להימנע ממגבלות קליטה יומיות?

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

כיצד ניתן לצמצם את עלויות קליטת הנתונים ב-Log Analytics?

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