[MEGOLDVA] script/alkalmazas logfile szuresere adott mintara

Szkriptek: Python, Perl, Bash, ...

Hali,

 

van egy alkalmazas naplom.  Minden egyes elinditott process ebbe a file-be rakja az uzeneteket (alkalmazas processek).

 

Ezt szeretnem a process id alapjan szurni. Utolag viszonylag egyszeru, mert egy grep-pel a pid-re es meg is van az eredmeny. De van amikor a process indulasatol eloben szeretnem nezni.

A process indulasakor kapom meg pid-et, igy amikor atvaltok a masik ablakra es az elokeszitett tail nap.lo| grep {PID} -et kitoltom gyakran elofordul, hogy mar le is futott.
Persze az is, hogy meg el sem indult (gyujti a fuggosegeket,) ...

Mielott nekiesek egy ilyen script megirasanak, es eltoltok vele heteket, erdekelne, hogy talalkozott-e mar valaki ilyennel? Marmint ami buffereli a logot, majd amikor megkapja a filter sztringet, akkor az addigi sorokat egyezes eseten kiirja, a kesobb jovoket meg mint a tail+grep kiloki?

 

Megoldas:

#!/bin/bash

PID=$1
LOG="nap.lo"

BUFF='grep ${PID} ${LOG}'
if [ $? -eq 0 ]; then
  # get the linenumber of the last match
  LINENUM=`grep -n "${BUFF##*$'\n'}" ${LOG}| cut -f1 -d:`
  # we do not need duplication from the grep and tail
  ((LINENUM=LINENUM+1))
else
  LINENUM=0
fi

echo "${BUFF}"
tail -F -n +${LINENUM} ${LOG} | grep ${PID}
  • 408 megtekintés

( Crayon | 2021. 10. 29., p – 16:11 )

nem a grep --line-buffered kapcsolóját keresed?

Ha jol ertem a line-buffered opcioval a grep nem egybol irja ki az output-ot a kepernyore, hanem bufferel.

Az en problemam:

- process elindul es elkezd loggolni

- a kepernyore kiirja a pid-jet

- elinditom a tail -f naplo.fajl | grep {pid}

 

de addigra a process mar loggolt a filebe, es mire a tail-t elinditom mar akar be is fejezte a futasat, de legjobb esetbem is lemaradok a logok elejerol. 

Fordítva. A grep alapból bufferel így előfordulhat hogy több sort is összevár mielőtt kiírná az outputra. A line-buffered pont azt mondja hogy ezt ne tegye, de gyakorlati tapasztalat hogy ha az input nem egy állomány hanem stream akkor alapból - nálam - így működik. Legalábbis egy ideje, régebben mintha nem így ment volna, vagy lehet az nem GNU grep volt.

Ok, ertem. De ez akkor sem jo. A pattern-t amire grep-elni akarok, csak a process inditasa utan kapom meg.

 

#!/bin/bash

PID=$1

grep ${PID} nap.lo ; tail -f nap.lo| grep ${PID}

 

Jelenleg ez all a legkozelebb ahhoz amit szeretnek, de itt elofordulhat (legalabbis ugy velem), hogy kihagyhat sort mire elindul a tail.

( uzsolt v | 2021. 10. 29., p – 22:58 )

Nem lehet ezeket a logokat egy külön fájlba irányítani? Pl. nincs egy --logfile vagy ilyesmi opciója a "process"-nek?

( Raynes v | 2021. 10. 31., v – 00:27 )

watch egrep minta fájl

vagy

watch tail nap.lo|grep {PID}

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A watch az x idonkent lefuttatja a grep-et. Ami akar mukodhetne is.

Bar ehhez mokolni kell, hogy eltaroljam az aktualis sor szamat, es csak onnan greppeljek. De a grep onmagaban ilyet nem tud, sed-del kell hozza varazsolni.

Igaz, hogy annyira nem tail, de mondjuk 5 masodpercenkent parsolom a naplot mas kezdosorral. 

 

 

Ugyanazt a logot nem nyomtatnam ki a kepernyore, mert van amikor igy is eleg sokat naploz az alkalmazas, szoval egy az egyben ez a watch tail| grep kombo nem megoldas a bajsagomra.

No akkor lépjünk hátrébb két lépést, és első körben a scriptek alkotóját kéretik khm. inzultálni azügyben, hogy rendesen logoljon a ... a scriptje, (Hint: logger parancs), és egyeztetni a rendszergazdával, hogy a local* facility-ből melyiket lehet erre a célra használni.
Másodsorban ha ez nem megy, akkor meg a rendszer gazdáját, hogy a feladatodhoz kell a logtail csomag, és kéretik felrakni.

Sok-sok éve még nekem is az volt a természetes, hogy a motyóim saját naplófájlokat használtak, saját maguknak oldották meg ezeknek a rotálását, mentését, miegyebeket, és teljesen jónak tartottam ezt az irányt.
Aztán ez gyorsan elmúlt, amikor 1234 fájlba logolós vackot kellett bekötni központi naplózásba - oké, minden "rendes" syslog implementáció (és az rsyslog is) képes fájlokból felolvasni logsorokat és betolni egy központi gyűjtőbe, de sokkal-sokkal kényelmesebb azt mondani, hogy logger -p local6.info "Ez egy info logsor" - és a többit a syslog elintézi - akár rakhatja külön fájlba is, ha úgy tetszik - de legalább szabványos formátumban teszi.
 

Azokon a dolgokon probalok valtoztatni, amelyekre tudok hatni. Az alkalmazas (nem script, lehet, hogy felreertheto voltam mashol) ilyen jellegu modositasa nincsl a lehetosegeim kozott. Idoigenyes es kotlseges is. Meg nem lattam meg olyan kerest, ami egyreszt elkeszult volna, es az uzemeltetest konnyitette volna meg. 3-4 eve volt valami brainstorming, hogy miken kellene valtoztatni a sw-ben, hogy jobb legyen. Meg nem lattam egyik elfogadott pontot sem megvalosulni. 

Ha meg szuksegem van egy dologra, akkor az a leggyorsabb megoldas, ha nem varok masokra, hanem megprobalom megoldani. Mint jelen esetben ez ~10 soros bash scripttel meg van oldva, es nem kell varnom ra 5-10 evet, hogy egyszer talan a ceg is tamogatja, hajlando erte fizetni, es meg is rendeli a fejlesztotol.

 

Az nyilvanvalo, hogy nem feltetlen mukodik minden a lehet legjobban a cegnel, de a termek es a cel megeri a faradozast es a hajhullast.

"Ha meg szuksegem van egy dologra, akkor az a leggyorsabb megoldas, ha nem varok masokra, hanem megprobalom megoldani" - Aztán amikor ilyen -bocs- körbetákolásból lesz 123456 a rendszerben, akkor lesz pislogás, ha valamihez hozzányúlnak, és egy csomó dolog borul miatta. De akár az is keresztbe tehet, ha valaki, aki 1234 ilyen "workaround"-ot megcsinált, kiesik a csapatból - aztán akik meradnak, csak pislognak akár 1-2 év múlva is(!) a szekrényből kiboruló csontvázak láttán.

"3-4 eve volt valami brainstorming, hogy miken kellene valtoztatni a sw-ben, hogy jobb legyen. Meg nem lattam egyik elfogadott pontot sem megvalosulni. " - Akkor ott a fejlesztő társulatot, de akár a megrendelői oldal felelőst is páros lábbal kéne kipicsázni a búsba, és nem megoldani "okosba". Ezzel ugyanis ennek a foskupac állapotnak a megmaradását segíted elő, és egy "shadow-IT" kialakulását, ami a beszállító helyett fejleszt, illetve tákol olyasmit, amire valójában szükség lenne.

 

( csabka v | 2021. 10. 31., v – 23:53 )

Nem biztos, hogy jól értelek, de a tail -n kapcsolóval lehet rávenni, hogy a korábbi pl 1000 sor-t is kiírja, és abból grep-eljél. A -f miatt folytatólag az aktuálisig.

tail -f -n 1000 logfile |grep $PID

A másik értelmezés szerint pedig, kiszűrni -v azon logsorokat, amelyek tuti nem az új process logjai

tail -f logfile | grep -v -e "másikpid1" -e "egyébexclude"

Ha az egész fájlt akarod nézni, akkor nem kell tail. Akkor elég a cat, de még az se kell, mert a grep közvetlenül tud fájlban keresni, nem kell előtte a cat-et meghívni. Tehát a cat file | grep minta az pazarlás, helyette grep minta file, a watch meg meghívja rendszeresen. A tail-nak akkor van értelme, ha tényleg csak a legutolsó x sor kell, de azt is be lehet venni a watch-ba
watch "grep minta file | tail -n sorok"

BSD-s rendszereken alapból nincs watch, ott fel kell tenni a gnuwatch-ot.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez lesz az, valamiert beneztem a -n +K -t. 

Valahogy igy:

#!/bin/bash
PID=$1
BUFF='grep ${PID} nap.lo'
if [ $? -eq 0 ]; then
  # get the linenumber of the last match
  LINENUM=`grep -n "${BUFF##*$'\n'}" nap.lo| cut -f1 -d:`
else
  LINENUM=0
fi

echo ${BUFF}
tail -F -n +${LINENUM} nap.lo | grep ${PID}

 

A logrotation-nel lehetnek meg osszezordulesek, de az csak ejfel korul. Egyelore jo lesz.

 

Koszi!