Jump to content
php.lv forumi

Doma Ienāca Prātā Par Kļūdu Reģistrēšanu


3ps

Recommended Posts

Ienāca man prātā doma. Gudrais kļūdu reģistrs. Kā zināms, error handļeri un log failus visi māk močīt. Pēc mazāka vai lielāka laika, atkarībā no aplikācijas lietošanas biežuma, kļūdu reģistra specifiku u.tml, kļūdu pieraksta fails kļūst mežonīgi liels un, lai no tā izlobītu vajadzīgo informāciju arī paiet laiks ... dažreiz sanāk tā, ka vieglāk būtu trijās stundās iziet pa diagonāli cauri visam kodam nekā error logā noorientēties un izlobīt patiesību. Kļūdas mazas vai lielas vienmēr ir. Jā, ja gudri plāno log failu, un kaut kā iedala kad un kā raksta, tad kaut vai ar teksta redaktoros iebūvētajiem find or whatever var atrast kas un kā. Bet doma mana gudrā bija tāda, ka močījam visas kļūdas iekš DB.

 

Ir divas tabulas: kļūdu saraksts un kļūdu apstākļi. Pirmajā glabājam kļūdu paziņojumu unikālu hashu vai kāviņtursauc. Karoče ņemam md5($kludas_pazinojums) un liekam unique indeksu uz šo lauciņu. priekš šī lauciņa vajadzētu hashēt tādu kļūdas paziņojumu, kas nav atkarīgs no īpašajiem ievaddatiem. Te varētu būt kļūdas paziņojuma sākums, piemēram, sql error tiri piri, bet neliekam pašu SQL fragmentu, lai nebūtu miljoniem unikālu ierakstu, vēl varētu pielikt klāt failu un rindiņas numuru. Tātad kaut kas tāds:

$error_msg = ereg_replace(":::.*$", "", $error_msg ); ( tas izdzēsīs visu aiz ':::' ??

md5( $error_msg . $error_file . $error_line );

 

Šo tātad bāžam iekšā kļūdu saraksta tabulā. Vēl šajā tabulā uztaisam lauciņu, kas parāda kļūdu skaitu - tātad reizes cik šī kļūda gadījusies. Katru reizi kad gadīsies kāda kļūda, šis te skaitlis tiks palielināts par viens.

 

Otrajā tabulā bāžam iekšā aptuveni tādus lauciņus:

kluda_id

registreta_kluda_id (foreign key uz pirmās tabulas registrēto kļūdu id lauciņiem)

kludas_pazinojums (šis būs konkrētajam gadījumam atbilstošais kļūdas paziņojums, piemēram konkrētais SQL. to var iegūt atlasot no kļūdas paziņojuma visu pēc :::, piemēram.

kludas_laiks

kludas_ip

kludas_requestquery

un sazin vēl kādi citi lauciņi jūsu ērtībām.

 

Ar to request query arī tā ir kā ir ... tas atkarībā no jūsu aplikācijas. hashā laikam jāiekļauj līdz kaut kādam līmenim arī. piemēram, ja jums viss iet čerez index.php ar kaut kādu mod=Fočenes, ?mod=eMpē7 or whatever, tad laikam vajadzēs arī šo ?mod=... daļiņu iekļaut hašā.

 

Kad gadīsies kāda kļūda ģenerēsim hashu, skatīsimies vai pirmajai tabulai to var pievienot, ja nevar, tad tur tāds jau ir (unique, atceramies?). ja nevar tad ir vienkārši jāpieskaita tur tam skaitītājam viens. ja var pievienot, tad būsim reģistrējuši jaunu kļūdu! un otrā tabulā liekam uz konkrēto gadījumu attiecināmo informāciju (skatīt iepriekš aprakstītos otrās tabulas lauciņus).

 

Kas tālāk?

 

Tālāk seko saldais ēdiens. Mūsu rīcībā ir visai gudri organizēta informācija no kuras ar visvienkāršākajiem sql pieprasījumiem var vilkt ārā dažnedažādus jokus. un tā jūs varat kārtot kļūdas pēc to biežuma, lūkot ar kļūdām visbiežāk saistītās IP adresītes (:D - acīmredzot šiem lietotājiem kaut kas ir aiz ādas, varbūt tikai asinis, varbūt kas vairāk .. tas katram pašam jālemj), lūkot kādos laikos kļūdas gadās visvairāk ... pēc tam seko darbība - biežākās kļūdas labojam, ideālā gadījumā visas kļūdas labojam...

 

p.s. nu jā tai pirmajā tabulā blakus hasham jāglabā arī patiesā rinda, kas slēpjas zem šī hasha - hash tiek ģenerēts tikai tāpēc, lai nebūtu jāliek unique uz text tipa lauciņa :))

 

p.s.c. jā nekāds vieglais pasākums tas nav - piepildīsies tā kļūdu tabula diezgan fiksi un tad jāiestāda automātiski jaunu tabulu veidošana ...

 

bez tam ar DB savienojumiem saistītas kļūdas, šis reģistrs laikam nereģistrēs ;)) tātad šis nevarētu būt vienīgais kļūdu fiksētājs - failīgam vai mailīgam variantam arī jābūt.

 

neko reālu uzrakstījis neesmu, tik tā, neliels brainstormings, bļe

Link to comment
Share on other sites

Nu ta tāpat ir jātaisa kāds TXT log fails par Datubāzes atliekšanās notikumiem,

kura datus pēc tam kad tā DB ir atleikusies atpakaļ,

varētu ienest nu jau darbojošajās DB kļūdu reģistrā vot ;)

Link to comment
Share on other sites

Nu ta tāpat ir jātaisa kāds TXT log fails par Datubāzes atliekšanās notikumiem,

kura datus pēc tam kad tā DB ir atleikusies atpakaļ,

varētu ienest nu jau darbojošajās DB kļūdu reģistrā vot ;)

ugu...

vēl tādu ērtu web-interfeisu ar f-ijām tipa 'View new errors' :D

Link to comment
Share on other sites

Nu jums kaut kur jau velk uz nelabu pusi.. Ar domu ka bugfree (lai gan realitaate) lietojumu neuzrakstiit.

Tagad njems un rakstiis speciaalu Event logeri/Vieweri Bug Reporteri un kam tas viss?

Lietotaajam? Taksh nee. Userim vajag funkcioneejoshu pergu nevis taadu kas smuki maak izmest kljuudu pazinjojumus. Kas stradaa fiksi nevis maljas un dumpo kaarteejo errormessagi un attieciigi iemeslus kapeec taa ir noticis.

 

No developeeshanas viedoklja manupraat vienkaarshaak ir skatiities jau attieciigi standarta (php/apache) erorus. Nedod dies tik daudz identiskas kam lai atskjirtu buutu veel hashs japieksjir ;)

 

Cien 3ps doma jau visumaa nav slikta un proti taa arii darbojas tas pats EventLogeris/Viewers ieksh win vai Syslogs, klogs ieksh *ix sisteemaam, bet tie ir risinaajumi kas paarkjer un piefiksee jau citu lietojumu kljuudas nevis savas. Nesaskatu iespeejas shaadu variantu izstradaat ieksh php, kas speetu logeet citu neatkariigu scriptu darbiibu (iznjeemums ja tiek ieviests kopeejs API)..

Link to comment
Share on other sites

  • 3 weeks later...

Roze sez:

Kam tas viss vajdzīgs?

 

Lapas taču tiek apstrādātas un turētas uz lietotāju mašīnām. Tāpat arī tām vajadzētu būt uzlabojamām/atjaunojamām/salabojamām reālā laikā.

 

Bieži vien softu var uzstādīt un tad pievienot jaunas fīčas attālināti.

 

Vai tas ir vajadzīgs vai ne atkarīgs no konkrēta projekta, bet pie lielākas kompleksitātes vajadzība pieaug.

Link to comment
Share on other sites

×
×
  • Create New...