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