Jaký používáte nástroj pro analýzu logu Apache?

Ahoj, při komplexní analýze logů Apache (včetně historických) používáme + WebLog Expert Lite 8.6 + a nyní uvažujeme o zakoupení placené verze (Standard, Professional). --- http://www.weblogexpert.com/ Považujete tento program za kvalitní nebo používáte jiný a výrazně Lepší ?? Děkuji za všechny názory.

A co přesně od toho očekáváte? Importovat logy umí třeba i Piwik.

Maximum přesných informací v přehledném balení (grafy). Cena není primárním hlediskem.

 

Čau, já pro analýzu na eshopu používám MonkeyData, pro mě poskytují dostačující množství informací z různých zdrojů. Vše je tam hodně přehledně zobrazeno a popsáno. --mají fajn i fajn demo na webu https://www.monkeydata.com/cs/ Snad to nějak pomůže.

v praxi ti jen logy apache nestačí a potřebuješ v hromadě mít i nějaké ty systémové srandy (cpu, ram, io, pakety, cs atd. atd.). Používáme nagios, kibana pro ukládání logů. Log soubory parsujeme skripty v grepu nebo awk a důležité věci se grafují.Pro milovníky konzole třeba přímo pro apache existuje http://goaccess.io, občas ho také zapnu, ale jen když se řeší nějaký problém.

Napsal Jey0;1261969

Vždyť máš přece svůj vlastní SSD hosting, u kterého denně honíš, tak to přece musíš vědět nejlíp.

DNES ke každému SSD webhostingu doména ZDARMA. Ano, už je tady profi SSD webhosting. Žádná SSD cache, ale 100 procent serverové SSD disky.

A nebo snad ne?

Váš originální příspěvěk (email) : "Blbec je blbec a blbcem zůstává.. Snad máš svůj super hosting na SSD, o kterém jsi tu plkal v tématu u wedosu, tak to přece musíš vědět nejlíp." a odkaz na reklamní akci...ukazuje, že jste zakřiknutým milovníkem webhostingu...:-)) Lidé v Multimediaexpo.cz si však myslí, že webhosting je sprosté slovo, a proto používáme kvalitní dedikovaný server u společnosti Coolhousing.net, který má aktuálně 32 GB RAM. A během pár měsíců plánujeme další HW upgrade...:-)) 18383 PS: A který webhosting na světě nám poskytne, dobrovolně, 120 GB prostoru (pro současné fotografie) a dalších X Tisíc GB prostoru pro naše budoucí multimédia ??

Napsal Multimediaexpo;1263733

PS: A který webhosting na světě nám poskytne, dobrovolně, 120 GB prostoru (pro současné fotografie) a dalších X Tisíc GB prostoru pro naše budoucí multimédia ??

Amazon Simple Storage Service (S3) - Object Storage…

GUI na webovém serveru? Vtipné. Ukazování kdo má většího ***** je super disciplína, o tom žádná. Doufám, že až budeš mít desetinásobek, také nám o tom napíšeš, nerad bych o tu informaci přišel. Každopádně přeji hodně úspěchů na serveru bez ECC pamětí, víš vůbec kolik chyb denně vzniká v RAM v zatíženém serveru?Jak naznačuje souki, je největší blbost ukládat data přímo na samotném server, bez záloh, replikací, failoveru, recovery atd.

TomášX ::1. GUI na našem webovém serveru bylo vždy (6 let++) a vždy bude. Linux našeho serveru, těsně po restartu do GUI, zabere 1 GB RAM (z 32 GB). Když se nainstaluje Debian 8.x na libovolný náš počítač...Debian, těsně po restartu do GUI, zabere 700 až 900 MB RAM. Zatížení je v obou případech téměř neměřitelné (když nepřipojíme síťový/internetový kabel). A vy se snad připojujete, s KVM, do textového režimu? Vtipné.2. Až budeme mít 512 GB RAM (16-násobek), tak se samozřejmě tady Masivně Pochlubíme... WEDOS tady před 2 roky (přesné datum už nevím) vykřikoval přes 2 měsíce, že má "nekonečně výkonný" server s 2 procesory a 384 GB RAM. Ukazování kdo má většího *****, je tedy zcela běžným jevem i tady.3. ANO, máme server bez ECC RAM...a co má být ?? Za 22 let mojí praxe (moje první PC z roku 1993 stále funguje) jsem se ani jednou nesetkal, na všech svých i svěřených počítačích a serverech, s tím, že by chyba v RAM způsobila pád počítače nebo jiný velký problém. Několikrát jsem byl oficiálně zaměstnán jako Administrátor/Webový administrátor (třeba na Ministerstvu kultury ČR) a NIKDY jsem v těchto pozicích (před rokem 2007) nepotkal Server nebo PC s ECC RAM...:-)) A zhroutil se snad, kvůli chybějící ECC RAM, nějaký velký český server ?? Netvrdím, že používání ECC RAM je dnes zbytečné (ceny jsou dostupné), ALE nebudu okamžitě řešit problém, který jsem nikdy nepotkal !! 4. Vaší "blbost ukládat data přímo na samotném serveru" vám brát nebudu...:-))...naše data se již dávno replikuji na 4 externí disky WD 1 TB.

1. nejde o spotřebu prostředků, ale o přístup ke správě takového systému. Klikání se nedá automatizovat, složitě se dá logovat, auditování je vyloženě sci-fi, o škálování a efektivnosti údržby ani nemluvě. Pokud máš jeden server, ok, jak jich ale máš 400, máš problém. Ano, v případě nouze používáme KVM do textového terminálu, ono vlastně na server ani jinak systém nainstalovat nelze, pokud je HW problém, je to opět jediná možnost jak se dozvědět více, nikdo nechce jezdit denně do datacentra2. ano, argument stylu dělají to ostatní, budu to dělat také3. Pokud o problému nevíš, neznamená to, že neexistuje. Denně na jednom serveru ECC opraví desítky až stovky chyb (v našem případě; záleží na zatížení systému; a ano sleduje se to). Je mylné se domnívat, že chyba se může snadno projevit, jedná se defacto o změnu jednoho bitu v datové větě a důsledek může být jiná hodnota objednávky, zahozený http request, jiné písmeno v logu, chyba komunikace mezi procesy. Řada podobných chyb se sama opraví vyšší vrstvou, řada projeví naprosto nepodstatně, ale u pár je důsledek kritický a špatně odhalitelný, málokterá databáze si kontroluje konzistenci dat zapsaných na disk atd. K pádu systému není moc důvod, většina operací s pamětí se děje v user space, kernel max zapisuje na disk nebo posílá data po síti (tam se chyby projevují). Pokud jde přímo o webové servery, ty si spadlého workera/thread restartují sami naprosto v tichosti aniž by tě o tom nějak informovali. Problém můžeš potkat jednoduše, stačí si mezi servery po síti přenést 100TB a statisticky v tom máš jednu chybu, checksum ti to odhalí.4. blbost to je z pohledu provozovatele webové aplikace, kdyby se k datům choval zodpovědně, nepotřebuje na webhostingu 120 GB místa. Na aplikační server klidně stačí 8GB disk pro provoz desítek aplikací (moje praxe), rozumím ale že u malých projektů je jednodušší to mít vše na jednom místě vč. dat a jejich ztráta se řeší až když nastane

Přátelé, už jsme opravdu mimo původní téma.

Napsal Souki;1263966

Přátelé, už jsme opravdu mimo původní téma.

ANO, mohl bych se klidně hádat dál, ale už by to fakt bylo mimo mísu. Uvidíme se v jiném vláknu...:-) ---------- Příspěvek doplněn 05.02.2016 v 13:23 ----------

Napsal TomášX;1263904

1. nejde o spotřebu prostředků, ale o přístup ke správě takového systému. Klikání se nedá automatizovat, složitě se dá logovat, auditování je vyloženě sci-fi, o škálování a efektivnosti údržby ani nemluvě. Pokud máš jeden server, ok, jak jich ale máš 400, máš problém. Ano, v případě nouze používáme KVM do textového terminálu, ono vlastně na server ani jinak systém nainstalovat nelze, pokud je HW problém, je to opět jediná možnost jak se dozvědět více, nikdo nechce jezdit denně do datacentra

2. ano, argument stylu dělají to ostatní, budu to dělat také

3. Pokud o problému nevíš, neznamená to, že neexistuje. Denně na jednom serveru ECC opraví desítky až stovky chyb (v našem případě; záleží na zatížení systému; a ano sleduje se to). Je mylné se domnívat, že chyba se může snadno projevit, jedná se defacto o změnu jednoho bitu v datové větě a důsledek může být jiná hodnota objednávky, zahozený http request, jiné písmeno v logu, chyba komunikace mezi procesy. Řada podobných chyb se sama opraví vyšší vrstvou, řada projeví naprosto nepodstatně, ale u pár je důsledek kritický a špatně odhalitelný, málokterá databáze si kontroluje konzistenci dat zapsaných na disk atd. K pádu systému není moc důvod, většina operací s pamětí se děje v user space, kernel max zapisuje na disk nebo posílá data po síti (tam se chyby projevují). Pokud jde přímo o webové servery, ty si spadlého workera/thread restartují sami naprosto v tichosti aniž by tě o tom nějak informovali. Problém můžeš potkat jednoduše, stačí si mezi servery po síti přenést 100TB a statisticky v tom máš jednu chybu, checksum ti to odhalí.

4. blbost to je z pohledu provozovatele webové aplikace, kdyby se k datům choval zodpovědně, nepotřebuje na webhostingu 120 GB místa. Na aplikační server klidně stačí 8GB disk pro provoz desítek aplikací (moje praxe), rozumím ale že u malých projektů je jednodušší to mít vše na jednom místě vč. dat a jejich ztráta se řeší až když nastane

1. Nikdy by mne nenapadlo používat KVM do textového terminálu, protože existuje převratný vynález jménem : PuTTY (www.multimediaexpo.cz/wiki/PuTTY). Formulace "nikdo nechce jezdit denně do datacentra" asi znamená, že máte servery u OVH.cz (Kanada, Francie) nebo HETZNERu (Německo). Naše datové centrum je vzdáleno 14 minut autem. 2. Ano, tady to dělají všichni...každý tady je přece Superman ! 3. Dnes ráno jsem si ověřil, že naše nejlepší stanice : HP xw9400 Workstation z roku 2010 má 48 GB ECC RAM DDR2 (to "ECC" mi dodnes unikalo), takže ho můžeme nasadit místo našeho webového serveru. Stanice má dva 6-jádrové procesory AMD Opteron 2435 (12-jader), takže má i citelně větší výkon... Problémem této stanice je však zdroj 1050 W (web server má zdroj 300 W). Jinak, obecně, souhlasím s tím, že kdybychom měli e-shop, který každý den vydělá 500.000...tak by nás děsila "jiná hodnota objednávky, zahozený http request, jiné písmeno v logu, chyba komunikace mezi procesy". 4. Tohle nemá smysl komentovat. ---------- Příspěvek doplněn 05.02.2016 v 17:42 ----------

Napsal Souki;1263765

Amazon Simple Storage Service (S3) - Object Storage…

Díky. Základní myšlenka je dobrá, ale protože požadují poplatky za absolutně každou operaci : PUT, COPY, or POST Requests : $0.01 per 1,000 requests GET and all other Requests : $0.01 per 10,000 requests ...tak se obávám, že by celková měsíční fraktura rychle přesáhla částku 500 USD. A raději ani nechci domýšlet jak by se na fraktuře projevil libovolný DDOS útok...

Napsal Multimediaexpo;1263988

Díky. Základní myšlenka je dobrá, ale protože požadují poplatky za absolutně každou operaci :

PUT, COPY, or POST Requests : $0.01 per 1,000 requests

GET and all other Requests : $0.01 per 10,000 requests

...tak se obávám, že by se celková měsíční fraktura rychle přesáhla částku 500 USD. A raději ani nechci domýšlet jak by na fraktuře projevil libovolný DDOS útok...

Nijak, protože je to stejně schované za CDN. Hostujeme takhle ~10TB obrázků a je to nesrovnatelně levnější a hlavně spolehlivější než původní vlastní HW.Klidně si o tom můžeme povídat, ale prosím pěkně v jiném tématu, protože tohle nemá absolutně nic společného s analýzou logů.