Čím prohlížíte logy při ladění? A jak se vám líbí moje prohlížítko?

Zdar všem,

Občas se dostávám do situace, že potřebuju najít chybu v aplikaci, která komunikuje s různými přístroji, a občas se někde něco nepovede. Tak pozapínám na různých místech Debug a Trace levely a pak dlouho hloubám nad logy. Zatím jsem hloubal s pomocí grepu a vim-u, ale už mě to otravovalo, zkoušel jsem najít nějakou aplikaci která by mi to usnadnila, ale nic funkčního jsem nenašel. Nakonec jsem si malou věc napsal, měl jsem trochu volného času a aspoň to byla pěkná příležitost vyzkoušet si jazyk Elm (spokojenost).

Otázky mám dvě:
 - Máte nějaký tip na aplikaci pro takovéhle situace? Aby to nebyla cloudová služba ale aplikace, ideálně přenosná (Linux, Windows), umělo to základní filtrování, zvýrazňování nalezených řetězců. Stačí pro menší logy, nechci Kibanu nebo Logstash.
 - Co si případně myslíte o mém pidivýtvoru: K vyzkoušení zde, https://dvtomas.github.io/portable-log-viewer/ , github: https://github.com/dvtomas/portable-log-viewer/ .

Je mi jasné že je to nehotové a aktuálně užitečné tak sotva pro mě, spíš mě zajímá jestli je tu někdo, komu podobná aplikace chybí a tohle by mu přišlo fajn..



Používám http://glogg.bonnefon.org/
Hmm, to není blbý. Je zajímavý jak se autoři soustředili na jiný featury než já. Ten nápad se dvěma oknama je asi docela šikovnej. Díky za tip.

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
pro sledování živých logů při vývoji auto-revert-mode v emacsu. Na serveru se mi osvědčilo ukládat si čísla sloupců do proměnných s odpovídajícími názvy.

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
možná by to prohlížítko mohlo podporovat řazení a stránkování.


možná by to prohlížítko mohlo podporovat řazení a stránkování.
Řazení dělat asi nebudu, to mi nedává moc smysl (usecase?), stránkování je tam v TODO :-)

Řazení není tak důležité, pokud by šlo lze vyhledávat dle sloupců. Umožnilo by to vyhledat například periodicitu určitého jevu. To je ale už smysluplnější ten log rozparsovat, vložit do databáze a pak nad ním spouštět sql dotazy.

Jeden z favoritů na logy je pro mne ELK a hlavně nástavby, které nad ním vznikají. Jako příklad bych uvedl Graylog.

clh

Jeden z favoritů na logy je pro mne ELK a hlavně nástavby, které nad ním vznikají. Jako příklad bych uvedl Graylog.

Elasticsearch se na tento typ dat vůbec nehodí. IMHO se nehodí na nic. Do clickhouse uložíte na stejném HW násobně víc dat, rychleji, na dotazy můžete používat téměř plnohodnotné SQL.

ELK. Pomaly, spatne skalovatelny, lucene domain specific language, priplatek za hloupy aclka a integraci s ldapem.  Upgrade vsech komponent to je tak na 3 dny prace pokud vse funguje.

Maji nasazeno nektere aplikacni tymy na java appky  ale hledat neco v tom prakticky je za trest.
Nechapu na co se ucit dalsi dotazovaci jazyk.

ELK. Pomaly, spatne skalovatelny, lucene domain specific language, priplatek za hloupy aclka a integraci s ldapem.  Upgrade vsech komponent to je tak na 3 dny prace pokud vse funguje.

Maji nasazeno nektere aplikacni tymy na java appky  ale hledat neco v tom prakticky je za trest.
Nechapu na co se ucit dalsi dotazovaci jazyk.

A napriek tomu je to de fakto standard na logy. V cloude si ELK das na par klikov ako SaaS a tiez na par klikov naskalujes podla potreby (nerozumiem pojmu spatne skalovatelny).

Mne se odvedcilo delat logy ve wireshark formatu. Neni nikterak slozitej a wireshark umi skvele filtry. Na lepsi filtrovani pouzivat setiny skund. Napriklad zarizeni A ma v case 0.001, zarizeni B zase 0.002 atd...

clh

A napriek tomu je to de fakto standard na logy.

ze setrvačnosti a kvůli ignoranci lepších řešení. Technologicky je to sračka, ve všech benchmarcích řádově horší než moderní sloupcové DB.

Mne se odvedcilo delat logy ve wireshark formatu. Neni nikterak slozitej a wireshark umi skvele filtry. Na lepsi filtrovani pouzivat setiny skund. Napriklad zarizeni A ma v case 0.001, zarizeni B zase 0.002 atd...

Nejaky example?Neni lepsi pridat UUID pro danej request nebo zarizeni?