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

קבצי Trace, בשונה מקבצי Log מיועדים לספק מידע מאד מפורט על אופן פעילות התוכנה, איזו פונקציה/מתודה הופעלה, על ידי מי, מאיפה, עם אילו פרמטרים, אילו שלבים בוצעו בכל פונקציה/מתודה, אילו שגיאות אירעו, מה היו הערכים החוזרים בכל שלב וכו'. מנגנוני Tracing בדרך כלל מספקים אפשרות לכיבוי מנגנון ה-Tracing ושליטה ברמת הפירוט של נתוני ה-Trace. נתוני ה-Trace בדרך כלל נכתבים לקובץ או ל-Windows Event Log אם כי בהחלט ישנן אפשרויות אחרות כמו כתיבתם למסד נתונים, דפי HTML ועוד.

אם אתה מנהל רשת מנוסה, הדבר הראשון שבוודאי קופץ לך לראש עכשיו זה דיסקים קשיחים – והרבה כאלו… (-;
אל חשש – נושא גודלם של קבצי ה-Trace מוכר וידוע וגם לו נמצא פתרון, במקרים כאלו בדרך כלל מגדירים מנגנונים האחראים לשמור מספר מסויים של קבצי Trace כאשר כל אחד מוגבל למשך זמן מסויים (למשל יום) או לגודל מסויים (למשל 10 מ"ב) ולאחר שמכסת הקבצים התמלאה קובץ ה-Trace הישן ביותר נדרס עם נתוני Trace חדשים.

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

סביבת Net. כוללת 2 מרחבי שמות (Namespaces) רלוונטיים לנושא:

1. System.Diagnostics namespace – אפשרות זו מיועדת בעיקר עבור אפליקציות Win32 (לא Web) ומאפשרת שליחת מסרי Trace למגוון רחב של Trace Listeners וע"י כך ניתן לשמור את הודעות ה-Trace בכל מקום שהוא (בברירת מחדל קיימים Trace Listeners עבור שמירה לקובץ, שמירה ל-DB, שמירה ל-Event Viewer, הצגה ב-Console, הצגה ב-Trace Console בסביבת הפיתוח ושמירה ל-Trace Class מתוך ה-System.Web namespace. עם זאת ניתן לבנות Trace Listeners חדשים על ידי בניית מחלקה היורשת מ-TraceListener)

2. System.Web namespace – אפשרות זו מיועדת רק לאפליקציות מבוססות Web (לא Win32) ומאפשרת שמירה זמנית (ב-RAM לא בדיסק הקשיח)של מסרי ה-Trace. בעת שימוש במרחב שמות זה ייכתבו באופן אוטומטי נתונים שונים אשר רלוונטיים בעיקר לאפליקציות מבוססות Web ול-Web Services כגון: תוכנם של אובייקטי ה-Request וה-Response, משך הזמן בין מסר למסר ועוד.

שני מרחבי השמות הנ"ל מכילים מחלקה (Class) בשם Trace אשר דרכה מתבצעת כתיבת מסרי ה-Trace. בשני המקרים ניתן לקבוע את תצורת ה-Tracing בעזרת קובץ ה-config של התוכנה ללא כל צורך בביצוע הידור (Compilation) מחדש. מדהים, לא?.

אז כך זה מתבצע: במערכת מבוססת Web ניתן בקובץ ה-web.config להוסיף את השורות הבאות:

<configuration>
<system.web>
<trace localonly="false" requestlimit="40" enabled="true" />
</system.web>
</configuration>

באופן זה, לאחר גלישה לאתר המערכת הרלוונטית (או פניה ל-Web Service הרלוונטי) נוכל לצפות בהודעות ה-Trace שנכתבו באמצעות הפקודה Context.Trace.Write או Context.Trace.Warn (בנוסף לנתונים שנכתבו אוטומטית) ע"י גלישה לדף בשם trace.axd בנתיב האפליקציה שלנו, למשל – אם האפליקציה שלנו נמצאת במסלול הבא:

http://server_name/portal

אזי, על מנת לצפות בנתוני ה-Trace שלה יהיה עלי לגלוש ל:

http://server_name/portal/trace.axd

חשוב שתדע כי אין טעם לחפש את הקובץ הזה שכן הוא לא קיים, הוא קובץ וירטואלי בלבד אשר מציג את נתוני ה-Trace של אותה אפליקציה. קצת לגבי הגדרות:
localonly – היות ונתוני Trace בדרך כלל כוללים נתונים מהותיים לגבי אופן פעולת המערכת שעבורה מתבצע המעקב לא יהיה ממש נבון לאפשר לכל מאן דיכפין להציג אותם, על אחת כמה וכמה אם מדובר בשרת של אתר אינטרנט. לכן, בברירת מחדל, אפשרות זו מוגדרת כ-true כך בעצם ניתן לגלוש אל דף ה-trace.axd אך ורק מהשרת עצמו, האפשרות החלופית היא להגדיר אותה כ-false ובכך לאפשר לכל אחד לגלוש לדף ה-trace.axd לצורך צפייה בנתוני ה-Trace.
requestlimit – אפשרות זו מגדירה כמה סה"כ בקשות יישמרו בדף ה-Trace. יש לשים לב לכך שהיות ודף ה-Trace לא יודע לחלק את הנתונים המוצגים לדפי משנה, ככל שתגדיר יותר בקשות, דף ה-Trace יעלה לאט יותר.
enabled – נו באמת…. אני מניח שאתה מבין מה זה אומר…. (-;

ומה לגבי אפליקציות שאינן מבוססות Web? אפליקציות מסוג זה לא מסוגלות להשתמש במנגנון ה-Tracing של System.Web, לצורך רישום נתוני Trace קיים עבורן מרחב השמות של System.Diagnostics, על מנת להגדיר מערכת חלונאית לעבודה עם Tracing כל שדרוש הוא בעצם להוסיף בקובץ ה-config של התוכנית (ללא קומפילציה, כמו קודם) את ההגדרות הבאות:

<system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="some_name" type="System.Diagnostics.TextWriterTraceListener" initializeData="TextWriterOutput.log" />
</listeners>
</trace>
</system.diagnostics>
לרשימת ה-Listeners ניתן להוסיף כל סוג של Trace Listener בו מעוניינים (למעשה, אפילו ניתן בקלות לבנות לבד אחד חדש, אני אדגים במאמרים הבאים כיצד ניתן לעשות זאת). יחד עם Dot Net מגיעים מספר Trace Listeners מובנים, ביניהם ניתן למצוא: Trace Listener הרושם את הודעות ה-Trace ל-Windows Event Log, כמו גם Trace Listener הרושם את הודעות ה-Trace למסד נתונים (מכל סוג), וכמובן גם Trace Listener הרושם את הודעות ה-Trace לקובץ. רשימה מפורטת יותר ניתן למצוא בקישורים בתחתית ה-Post.
למרות כל הקלות המדהימה של מנגנוני ה-Tracing הקיימים ב-Net. חשוב לשים לב ל-2 דברים:
1. אם אתם לא תוסיפו לקוד את הודעות ה-Trace במיקום המתאים ותכללו בהן את המידע הדרוש (חשוב מאד שמידע הנשלח אל ה-Trace יכלול נתונים המתארים את התהליך המתבצע כעת באופן מפורט ככל האפשא כגון: תאריך ושעה, שם המודול המתבצע כעת, שם המשתמש המבצע, תיאור קצר ומדוייק של התהליך המתבצע, שם המתודה המבצעת כעת ועוד)
2. אם אתם משרשרים למחרוזת הנשלחת אל ה-Trace משתנים כלשהם (למשל בכדי לכלול את הארגומנטים הנשלחים אל המתודה או אלו המוחזרים הימנה) חשוב מאד מאד לשים לב לבדוק קודם אם הם לא Null שכן אחרת, בכל פעם שנשלחת הודעת Trace אשר כוללת משתנה שהוא Null (ללא כל קשר לסוג ה-Listener) תגרום לתוכנית להתפוצץ בהודעת שגיאה מרעישה…
טוב, זהו בינתיים, כמובן שאשתדל להרחיב בנושא זה בהמשך אבל בינתיים תוכלו להעשיר את ידיעותיכם בנושא ה-Tracing בעזרת הקישורים הבאים:

השאר תגובה