Ինչպես կազմել արդյունավետ տվյալների լոգ

Նախ, թույլ տվեք մի փոքր նախաբան: ծրագիրը, հիմնականում որի սպասարկմամբ զբաղվում եմ աշխատանքիս վայրում, որոշակի հետաքրքիր առանձնահատկություններ ունի: Դասական “An error has occurred”-ը (Սխալ է տեղի ունեցել) միանգամայն անարժան նկարագրթություն է դեպքերի համար՝ երբ ինչ-որ բան այն չէ: Սխալների մասին հաղորդագրությունները ոչ թէ պարզապես սկսվում են այս նախադասությամբ, նրանք այդքանով էլ սահմանափակվում են:

Կամ ի՞նչ կասեք սրան. “Information about the error is stored in the server logs” (Սխալի մասին ինֆորմացիան պահպանվել է սերվերի տեղեկամատյաններում/լոգերում), բայց թէ հստակ ո՞ր սերվերն է բացառությունը գցել(throw exception)՝ մնում է միայն գուշակել:

Այս հոդվածն այն մասին է, թէ ինչպես գրել սխալների մասին հաղորդագրություններ՝ որոնք այդքան էլ երկիմաստ/անիմաստ չեն հնչի:

Իսկ արդյո՞ք դա մեզ պետք է

Այս հոդվածը մեծամասամբ նվիրված է լինելու ավելի շատ տեղեկություններ տրամադրելուն: Բայց, եկեք մի պահ աչքի անցկացնենք լոգ-ֆայլի այնպիսի հաղորդագրությունների, որոնք կարող են անվտանգ բաղդատվել: Ինչո՞ւ… Այդ հարցի պատասխանը դուք ինքներդ կգտնեք, երբ ստիպված լինեք կարդալու կիլոմետրերի երկարության հասնող լոգ ֆայլ, և համոզված եմ, այնուհետև, գուցե շնորհակալ լինեք այն ամենի համար, ինչը չի սպառում ձեր մտավոր ռեսուրսները:

Շատ դեպքերում ինֆորմացիայի ավելցուկն ավելի լավ է, քան պակասը, բայց ամեն դեպքում արժե հաշվի առնել հանգամանքները՝ չափազանցության չհասնելու համար:

Նշեք թէ ինչն է կոնկրետ սխալ

Բացառությունների (Exception) մեծ մասը, որոնց հանդիպում են առօրյայում, անմիջականորեն չեն մշակվում, ինչը նշանակում է, որ մենք հաճախ ստանում ենք մի սթեքի հետագիծ (stack trace), որը մեզ հստակ ասում է, թե ինչ է տեղի ունեցել, որտեղ և երբ: Այստեղ ամեն ինչ կարգին է: Այն առանձնապես ընթեռնելի չէ, բայց գոնե հնարավոր է հետևել աղբյուրին:

Եթե, այնուամենայնիվ, բացառությունը բռնել եք catch բլոկի միջոցով, որպեսզի այնուհետև կենսոլում արտաբերեք «Ինչ-որ բան չի աշխատում», նույնիսկ լոգում սխալի մասին լիարժեք հաղորդագրությունը չտպելով, պարզապես մի արեք դա: Եթե ​​դուք գրում եք հատուկ բացառությունների կարգավորիչ, ընդամենը մեկ լրացուցիչ րոպե ծախսեք՝ բացատրելու, թե որն է սխալը: Սա, օրինակ, տվյալների բազայում սխալ կամ անվավեր գրառման արդյունք է, թե՞ սխալ ֆորմատավորված անուն: Այսպես դուք պարզապես կշտկեք տվյալների բազայի անհրաժեշտ գրառումը և խնդիրն անմիջապես կլուծվի:

Իմ համար ամենացավոտ թեմաներից մեկը ևս. մենք ստանում ենք սխալների հաշվետվությունների ամենօրյա մոնիտորինգ, բայց ամենալավ գրված գրառումը նույնիսկ հեռու չի տանի, եթե չպարունակի ինֆորմացիա, թե որտեղից է այն առաջացել: Պարզապես արտաբերեք նմանատիպ հաղորդագրություն՝

fatal error: invalid cast at serverIWouldLikeToSlaughter

Ներկայացրեք լրացուցիչ պարամետրեր, որոնց հետ կարելի է աշխատել

Որպես նախորդ օրինակի շարունակություն. սխալի մասին հաղորդագրություն գրելու պահին, դուք հավանաբար արդեն իսկ ձեռքի տակ ունեք ամբողջական ինֆորմացիա, ուստի ինչո՞ւ այն չմատուցել հենց հաճախորդին: Պարզապես արտաբերեք հաճախորդի իդենտիֆիկատորը, հաշվի համարը, էլ. փոստի հասցեն, որը չի հաջողվում դեսերիալիզացնել.

Fatal error: Invalid cast type Boolean to Integer numberOfSwearwords at serverIWouldLikeToSlaughter

Ծանրաբեռնեք միայն անհրաժեշտ ու հստակ բացառությունները

Եթե ​​ուզում եք բացառություն նետել տվյալների անվավեր տեսակների կամ նմանատիպ այլ դեպքերի համար, ապա ավելի լավ է օգտագործել InvalidCastException կամ ինչոր այլընտրանք, քան պարզապես Exeption: Այսպիսով, ամենատարածված սխալը կուղեկցվի մեծ հաղորդագրությամբ` խոսուն անունով և նկարագրությամբ: Բայց երբ ինչ-որ արտասովոր բան է տեղի ունենում, դուք ամեն դեպքում գրանցում եք սթեքի ամբողջական հետագիծը, և այն չի կորչում.

Try{thisOrthat();}
Catch castEx as InvalidCastException{
  log.error("detailed description of error");
}
Catch ex as Exception{
  log.error(ex.stacktrace);
}

Դիտարկենք լոգերից դուրս բերված որոշ օրինակներ

Ահա ընդամենը մի քանի պատահականորեն ընտրված նմուշներ, որոնք ես օգտակար լոգ գրառումներ եմ համարում. բաներ, որոնք էականորեն հեշտացնում են հասկանալ, թե որտեղ է տեղի ունեցել սխալը և ինչպես շտկել այն:

-booting up server1 application4 
-Connecting to otherServer at Port 1337…ok
-Checking database Connection to databaseServer5 Error 400:Of course it doesn’t work, your credentials are outdated but not even the database admins have a clue what the new one are.
-program shut down at 00:34 pm, 1234 files processed successfully, 23 unsuccessful, 45 skipped
-Can't access file asdfadsfa.txt because the file is open in another process
-error updating database table tb_xyz, maximum column length of 50 exceeded at column "name"
-processing HTML text box failed, this is often caused by formatting issues on the database side. Check with database admins, the following value was retrieved from DB: <a">helloworld"</a>

Այս հաղորդագրություններից յուրաքանչյուրը կխնայի ձեր թանկագին ժամանակը՝ գտնելու համար սխալի աղբյուրն ու էությունը, այն հաղորդագրությունների համեմատ, որոնք կամ ընդհանրապես չեն նկարագրում սխալը, կամ այն ​​նկարագրում են անարդյունավետ:

Սկզբնաղբյուր՝ How to Write Log Files That Save You Hours of Time