Ko darīt ar Apache log failiem?

[Kaklz]

Tātad jautājums ir ko darīt ar apache log failiem. Vienkārši pareizināt ar 3 un izdzēst negribās. Ir doma uzrakstīt kaut ko līdzīgu statistikas ģeneratoram, tikai ir viena nelaime - gribas analizēt apjomā diezgan palielus log failus* un pietrūkst idejas, kā varētu organizēt datu apstrādi.

 

Reāli domājot noparsēt apache log failu ir triviāli. Ar nelieliem testiem nodarbojoties sanāca noparsēt apmēram 3700 ierakstus sekundē (veicot tik vien, kā uzskaiti, cik rindas ir noparsētas un cik daudz trafika ir izlietots). Bet nelaime ir citur: kā lai ar saprātīgu atmiņas apjomu uzģenerē detalizētu statistiku? Iedomāsimies, ka būvējam kaut vai to pašu webalizer klonu. Tur ir statistika pa stundām, pa dienām, hiti, hosti, refereri, statistika pa valstīm, un tā tālāk.

 

No vienas puses, varētu itkā visu sadzīt kaut vai tajā pašā MySQL, bet tie maģiskie SQL pieprasījumi vienalga nežēlīgi iebremzēs.

 

No otras puses itkā varētu visu krāmēt masīvos un cerēt, ka datu apjoms nepārsniegs PHP konfigurācijas failā norādītos. Ja nu gadījumā izmantojam incremental parsing, tad var mēģināt beigās uzģenerētos masīvus serializēt un iebāzt teiksim kādā failā un pēc tam turpināt. Attiecīgi ik pa laikam palaižot caur cron skriptu varētu arī mēģināt izbraukt uz to, ka klāt ir jānoparsē tikai pāris tūkstoši ierakstu, kas aizņemtu tikai pāris sekundes.

 

Varbūt kādam ir kādas labas idejas par šo tēmu? Varbūt ir zināms, kā tas notiek iekš tā paša Webalizer?

 

Paldies jau iepriekš :)

__________

* ne pārāk lielas lapas ar ~20 000 hostiem mēnesī apache log fails varētu būt uz kādiem 2 000 000 ierakstiem

[Gacha]

stradaatEs ilgi domaju, ka shis var tik atri stradaat

[bubu]

Lai MySQL nebremzētu, saģenerē INSERT teikums atsevišķā failā un tad taisi LOAD FILE INFILE :)

Par tiem masīviem gan nebūtu prāta darbs. Domā 8Mb iekļausies tie miljoni ierakstu? Tas nozīme 8 baiti uz ierakstu (miljons ierakstiem). Vai arī, ja pat palielini piemēram uz 50Mb, tad 50 baiti. Domāju, ka nepietiks. Vajag DB izmantot.

 

Jā, un Gacha: AWstats nav php, bet ir perl :)

Edited December 1, 2004 by bubu

[Kaklz]

Lai MySQL nebremzētu, saģenerē INSERT teikums atsevišķā failā un tad taisi LOAD FILE INFILE :)

Par tiem masīviem gan nebūtu prāta darbs. Domā 8Mb iekļausies tie miljoni ierakstu? Tas nozīme 8 baiti uz ierakstu (miljons ierakstiem). Vai arī, ja pat palielini piemēram uz 50Mb, tad 50 baiti. Domāju, ka nepietiks. Vajag DB izmantot.

 

Jā, un Gacha: AWstats nav php, bet ir perl :)

Ar to datubāzi jau būs problēmas nevis pie insert, bet pie maģiskajiem selektiem. Vismaz man tā liekas. Ja datubāze ir ar 2 000 000 ierakstiem, tad nekādus jaudīgos selektus saprātīgā laikā arī ārā dabūt būs grūti.

 

Teiksim tas pats webalizer - viņš taču neizmanto nekādu DB, awstats arī ne. Pie tam, ja nemaldos tad gan vienam, gan otram nav nekāda limita uz log faila lielumu.

 

Ja nu tomēr ejam roku rokā ar masīviem, man liekas, ka pietiek ar:

 

$dailyResults = array(
   '2004-12-01' => array(
       'hits' => 1000000,
       'hosts' => 10000,
       'pageviews' => 10000,
       'bandwidth' => 1000000,
       'visits' => 10000
   )
   '2004-12-02' => array(
       'hits' => 1000000,
       'hosts' => 10000,
       'pageviews' => 10000,
       'bandwidth' => 1000000,
       'visits' => 10000
   )
   ... līdz mēneša pēdējam datumam
)

 

Līdzīgi pa stundām

 

$hourlyResults = array(
   0 => array(
       'hits' => 10000,
       'pages' => 1000
   )
   1 => array( ...līdz 23
)

 

Un kopējais masīvs priekš total results:

 

$totalResults = array(
   'hits'=> 23949
   'pages' => 398969
   'visits' => 50225
   'bandwidth' => 18314746
   'hosts' => 1923
}

 

Labi, te nebūtu iekšā referer, user-agent un kāda tur vēl statistika. To pārējo varētu vēl piedomāt pēc tam. Iesākumam pietiktu kaut vai ar šādiem datiem, no kuriem ar GD varētu uzģenerēt normālus grafikus.

 

Tikko ienāca prātā viena cita doma - kā būtu pamēģināt izmantot SQLite? It kā viņi baigi lepojās, ka ir ātrāki par MySQL, PostgreSQL un citām datubāzu pārvaldības sistēmām.

[bubu]

Uz vienkāršiem selektiem SQLite ir ātrāks nekā MySQL vai Postgre.

[Gacha]

Varbūt var palīdzēt Output Bufferings? Varētu ar cron izveidot scriptu, kas kaut kad pa nakti saveido attiecīgajiem "QUERY_STRING" vai datumiem jau gatavus HTML failus!

[bubu]

Īstenībā tas nesaucās Output Bufferings, bet gan kešošana :)

[Gacha]

tas jau nav svarigi ka sauc bet domaju, ka tada ideja varetu noderet.

 

Un kas uz Perl tas viss notiek 10X atraak?

[bubu]

Nezinu vai 10-reiz, bet perl's ir ātrāks php gan.

[Aleksejs]

Šiem mērķiem mēdz izmantot tā saukto "round robin" datubāzi: tajā ir fiksēts skaits ierakstu.

Ieskatam:http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/index.html

Savukārt pašus apache logus ar logrotate regulāri arhivē.

Edited December 2, 2004 by Aleksejs

[Kaklz]

logrotate ir pats par sevi, vienkārši bija doma, kā organizēt statistikas ģenerēšanu.

 

Laikam jau iesākumam pietiks arī ar to pašu masīvu padarīšanu un datu serializēšanu. Pieņemsim, ka būs iesākumam tie paši pāris tūkstoši ierakstu sekundē. Galvenais ir no sākuma kaut ko izveidot un pēc tam jau var sākt veidot optimizācijas.

[рпр]

manuprāt ja katru dienu vai daudzmaz regulāri taisiitu to statistiku, tad jau nebūtu tik traki, bez tam kapēc tu uzskati, ka sql tabulā jāliek visi ieraksti? apkopo ko tev vajag un par katru mēnesi ieliec vienu iereakstu (vai arī 31 par katru dienu).

 

es vismaz darītu tā, izejot cauri logam piefiksētu pēdējo laiku, no kura atkal turpinātu darbu.

[Kaklz]

manuprāt ja katru dienu vai daudzmaz regulāri taisiitu to statistiku, tad jau nebūtu tik traki, bez tam kapēc tu uzskati, ka sql tabulā jāliek visi ieraksti? apkopo ko tev vajag un par katru mēnesi ieliec vienu iereakstu (vai arī 31 par katru dienu).

 

es vismaz darītu tā, izejot cauri logam piefiksētu pēdējo laiku, no kura atkal turpinātu darbu.

kā tu iedomājies uzskaitīt unikālo hostu skaitu?

 

Manā izpratnē ir jāsaglabā visas IP, kuras ir apmeklējušas tavu lapu.