rsyslog - áthidalva

Linux-haladó

Az a gondom, hogy van egy Graylog szerver, ebbe ugye mindenhonnan jönnek a syslog dolgok, hurrá. Próbálom az apache2/mysql logokat is, leesik, hogy ezekben nincs syslog, direktben fileba mennek. Kotorászok, graylog-sidecar, filebeat, szenvedek, nem megy.
Ígéretes megoldás: rsyslog tud filet olvasni. És valóban, tud:
 

module(load="imfile" PollingInterval="10" statefile.directory="/var/spool/rsyslog")

input(type="imfile"
      File="/var/log/apache2/*.log"
      Tag="http"
      Severity="*")
#      Facility="local1")

# local1.* action(type="omfile" File="/var/log/local1.log")

Szóval a tervem az lett volna, hogy local1 facilitybe nyomja, amit aztán szépen a /var/log/local1.log fileba nyomok . Elvileg már a /var/log/syslog-ba se kellene kerülnie, de odamegy. Mindegy.

Tehát, valami ötlet rá, hogy a beolvasott filenak mi legyen a kimenete ?

Ilyet nem találok a configban, valójában a "Facility" is az olvasott filera vonatkozik, ami számomra totál értelmetlen.

Mellékelve az "imfile" doksija. 
https://www.rsyslog.com/doc/v8-stable/configuration/modules/imfile.html

Bevallom, nekem az eredeti syslog is nehézkes volt, de azzal mégis elboldogult az ember - ezzel képtelen vagyok.
Egyébként ez a default kimenet és működik, csak az /var/log/syslog fileba ne kerülne bele :(

*.* @@10.31.75.10:1514

(a syslog.log kihagyására is itt van ez - de minthogy nem a local1-be megy a beolvasott file, semmit nem ér:
local1.none                     -/var/log/syslog )

( peterdif | 2023. 08. 30., sze – 16:17 )

Szerkesztve: 2023. 08. 30., sze – 16:17

Általánosan: az action(ök) után állítsd meg a feldolgozást amikor oda elment ahova akarod, egyébként minden destination-re kiküldi.

& ~

Más:

Lehet nem ez az optimális mód a probléma megoldására, + ha van kedved/lehetőséged nézd meg a syslog-ng-t inkább. Szerintem jóval átláthatóbb.

Köszi. Közben más irányba indultam el, kiderült, hogy egész kultúrált az apache logolása:
- nem csak egyetlen érvényes CustomLog sor lehet, hanem több is - és mindet végrehajtja
- lehet akár script is, azaz (példák szerint) a "logger" is meghívható.

Innen már egyszerűbbnek tűnik, azaz az apache2 fog a rsyslog-ba logolni. (mégpedig megmarad az eredeti, virtualhostonkénti logfile is)
Na, ha hasonló van a mysql-nél is, akkor boldog leszek.

"& ~" -> ezt köszi, ma is tanultam valamit. Rémlik, mintha lett volna valahol említve ilyen a doksiban, de átsiklottam felette, az jobban izgatott, hogy tudok filet olvasni és írni. 
Ha lehet is, nem egyszerű, nekem meg semmi kedvem olyan dolgot létrehozni, amit egy hónap múlva nem látok át.

http://www.micros~1
Rekurzió: lásd rekurzió.

- lehet akár script is, azaz (példák szerint) a "logger" is meghívható.

Ez de mekkora gány!

Ráadásul több sebből vérzik:

- performance overhead: nagyobb terhelésű webszerver esetén minden egyes sor meghív egy külön logger-t ?!

- semmi nem garantálja, hogy ne veszíts logot,

- ha audit log is van, akkor ezzel megduplikálod a logbejegyézésket, mert az összes logeer hívás is logolva lesz.

- security vonzata: 'ps' is szépen mutatja majd a logokat - bármelyik usernek...

 

Ehez képest akármelyik syslog agent file reader implemetációja fényévekkel jobb és megbízhatóbb.

 

szerintem.

zrubi.hu

- performance overhead: nagyobb terhelésű webszerver esetén minden egyes sor meghív egy külön logger-t ?!

Én is majdnem ezzel kezdtem, de aztán megolvastam, hogy is van ez, az apache egyszer forkol, a logger pedig tud stdint olvasni hosszan.  (Bár hevenyészett tesztjeim alapján baszik bekerülni a journalba, míg ki nem lép a logger, szóval valami van a puffereléssel.

- semmi nem garantálja, hogy ne veszíts logot,

Elvileg restartolja, ha meghal 

- ha audit log is van, akkor ezzel megduplikálod a logbejegyézésket, mert az összes logeer hívás is logolva lesz.

nem lesz, mert egyszer indít loggert 

- security vonzata: 'ps' is szépen mutatja majd a logokat - bármelyik usernek...

nem paraméter, stdin, nem látszik.

Ehez képest akármelyik syslog agent file reader implemetációja fényévekkel jobb és megbízhatóbb.

Én is hajlanék erre, de nem tűnik ez akkora borzalomnak, mint mikor magam elé képzeltem egy minden alkalommal forkolt loggert. 

A soha el nem készülő? Apache 2.6-ban (2.5 devel ág van már vagy 11!! éve) persze már van mod_syslog és mod_journald natívan.

https://httpd.apache.org/docs/trunk/mod/mod_log_config.html#customlog

# CustomLog logging to journald
CustomLog "journald" "%h %l %u %t \"%r\" %>s %b"

# CustomLog logging to syslog with "user" facility
CustomLog "syslog:user" "%h %l %u %t \"%r\" %>s %b"

( Celtic v | 2023. 08. 30., sze – 17:31 )

Ok, akkor az apache megoldva. virtualhost:
        CustomLog ${APACHE_LOG_DIR}/prodweb0001l_access.log combined
        CustomLog "|/usr/bin/logger -t apache2_web1 -p local0.info" combined 

Syslogba meg most nem kell semmi extra, már a *.* megy UDP-n a graylogba.
Feltűntek az "apache2_web1" üzenetek is, így már lehet rá szűrni.

http://www.micros~1
Rekurzió: lásd rekurzió.

( Celtic v | 2023. 08. 31., cs – 12:59 )

Egyben köszönöm az ötleteket, elhiszem, hogy jó a syslog-ng, de rsyslog van az Ubuntun gyárilag. Nem akarok most 10 gépet átkonfigurálni ezért - plusz az újaknál is.

Ha egyetlen sor beszúrásával az apache2 virtualhostok configjába megúszom, akkor hurrá (úgyis csak másolom és szerkesztem, ha új vh lesz)

http://www.micros~1
Rekurzió: lásd rekurzió.

Ja, én csak azért mondtam, mert írtad, hogy az rsyslog konfig pfejj.

Egyébként ennyi gépnél már van értelme elkezdeni ansiblezni vagy valami. :)

Azzal pont az ilyen skálázódási szarok favágását tudod megúszni. Bár kicsit több idő lesz megfaragni mondjuk egy rsyslog -> syslog váltást, mint egyszer, cserébe onnan már mindegy, hogy még 5 vagy még 50re kell kimenni neki.

Igen, tudom, már vagy 10 éve rá akarom venni magam az ansible megismerésére. Mondjuk 10 év múlva meg nyugdíj, szóval ha elég ideig rágom a körmöm, akkor nem lesz gondom.

Virtuális gépek, szóval nem egy iszonyat bonyolult dolog klónozni. Aztán persze van, amit két év után vettem észre....

btw, minden syslog config pfej :) Az eredeti is meg a többi is. Max annyit szoktam, hogy pl. smtp szervernél ne nyomja a mail logját a syslogba is meg hasonló apróságok.
Mondjuk így 50+ már nagyrészt mindennel úgy vagyok, hogy minél kevesebbet kelljen módosítani, utálom, mikor upgrade-nél fejreáll.

http://www.micros~1
Rekurzió: lásd rekurzió.

25? éve első dolgom minden Linux/Unix (még annó Solarisban is) telepítésnél/klónban/templateban whatever a random syslog implementációt cserélni syslog-ng-re :).

Ugyanez az  exim->postfix-el is :)

Kivéve egy két strict helyen (RHEL) ahol megkövetelik az alaptelepítéssel felmenő syslog-ot.

hát passz, én mindigis postfix-szel találkoztam (jó, életem első linuxa, a Mandrake, az kérdezte, postfix vagy sendmail legyen)
De mindig postfixet pakolnak a disztrók, úgy láttam. Nem mintha olyan iszonyú tapasztalatom lenne, debian/ubuntu meg centos és kész ( és linuxból elég is)

http://www.micros~1
Rekurzió: lásd rekurzió.

Igen, tudom, már vagy 10 éve rá akarom venni magam az ansible megismerésére. Mondjuk 10 év múlva meg nyugdíj, szóval ha elég ideig rágom a körmöm, akkor nem lesz gondom.

Hát, ha úgy érzed, megélsz majd a nyugdíjból :D

Virtuális gépek, szóval nem egy iszonyat bonyolult dolog klónozni. Aztán persze van, amit két év után vettem észre....

Nem szeretem az ilyen template / cloneozgatás alapú dolgokat, valahogy mindig kupi lesz kicsit. 

btw, minden syslog config pfej :) Az eredeti is meg a többi is. Max annyit szoktam, hogy pl. smtp szervernél ne nyomja a mail logját a syslogba is meg hasonló apróságok.
Mondjuk így 50+ már nagyrészt mindennel úgy vagyok, hogy minél kevesebbet kelljen módosítani, utálom, mikor upgrade-nél fejreáll.

Még talán a syslog-ng a legnormálisabb, ha egyszer felfogtad, hogy hogy áll össze egy logpath, akkor elég jó, a syntax sem annyira obskurus. Tény, hogy tud owerwhelming lenni elsőre, mert elég sok mindent tud, amire a végeken nem annyira van szükség, de egyébként nagy centralizálós menjen minden egy helyre dolgoknál elég sokat tud segíteni, ha ez van a felhordó hálózaton. 

"megélsz majd a nyugdíjból :D" 
talán a temetésre fussa (nem az állami nyugdíjra aspirálok)
Nincs az az érzésem, hogy megszámlálhatatlan évtized van előttem (szegény nagybátyám is 65 volt, mikor meghalt - igaz, apám 78.)

 

http://www.micros~1
Rekurzió: lásd rekurzió.

( Celtic v | 2023. 08. 31., cs – 15:19 )

"Nem szeretem az ilyen template / cloneozgatás alapú dolgokat, valahogy mindig kupi lesz kicsit. "
Nekem bejön. Sokkal egyszerűbb, mint a nulláról telepíteni és gondolkodni, mit szedjek le, mit rakjak fel.

http://www.micros~1
Rekurzió: lásd rekurzió.

Pont az a bajom vele, hogy nem nulláról van, hanem van valahol egy golden image, amit egyszer valaki összerakott, és igazából passzpiros mi van benne, aztán mikor egy év múlva rájövünk, hogy már kurva sokáig tart az apt update, kéne frissebb, akkor jön némi fejvakargatás. Meg a clone után azért még csak telepítek ezt azt, aztán szét van az egséz. Jobb szeretem azt, mikor indulunk mondjuk az isoból, aztán szépen ott a kotta, hogy így lesz ebből egy példány.

Ha van egy "prod" image-ed, ami a prod vm-ekkel egyszerre frissül, meg van egy teszt image-ed, ami a tesztekkel egyszerre frissül, akkor kvázi bármikor tudsz a meglévő VM-ekkel azonos verzión lévő környezetet létrehozni. Tudom, első látásra világbéke és minden elleni bűn az új gépet telepítés után azonnal nem minden részletre kiterjedően frissíteni, de van, ahol az az elvárás, hogy adott "körben" az adott frissítési cikluson belül egységes legyen minden.

Automatizálás... Azt, hogy mondjuk sssd-vel (vagy pbis, vagy más) AD-ből authentikáljon a frissen kialakított vm, azt hogyan automatizálnád le? Hol, és milyen credential-t tárolnál az automatikus domainbe léptetéshez?

Ha van egy "prod" image-ed, ami a prod vm-ekkel egyszerre frissül, meg van egy teszt image-ed, ami a tesztekkel egyszerre frissül, akkor kvázi bármikor tudsz a meglévő VM-ekkel azonos verzión lévő környezetet létrehozni. Tudom, első látásra világbéke és minden elleni bűn az új gépet telepítés után azonnal nem minden részletre kiterjedően frissíteni, de van, ahol az az elvárás, hogy adott "körben" az adott frissítési cikluson belül egységes legyen minden.

Szerintem elbeszélünk egymás mellett, nem arról van szó, hogy frissnek kell lenni, automatizált eljárásokkal nyugodtan meg lehet szabni a környezetet, amit létre szeretnél hozni. Remekül lehet pontosan egységesen tartani mindent. Azért nem szeretem a temlpates mókát, mert a prod image jellemzően valami nagyon nyekergős kézi/félkézi processz mentén keletkezik, azzal szemben, mintha normálisan le volna írva valahova, hogy minek kell benne lenni, és azt a gép produkálná "magától". Nem feltétlen kell ennek így lennie, készülhet az a prod image is "jól", én is csináltam már olyat, de tapasztalataim szerint nem ez a jellemző. Továbbá az egész környezetnek, amit kapsz, jellemzően nem része az ehhez szükséges tooling, ami meg megvan belőle, az általában nem valami jó. Vannak előnyei is a templatesdinek (pl jellemzően gyorsabb vmivel talán), de összességében szerintem nem az igazi.

  • Automatizálás... Azt, hogy mondjuk sssd-vel (vagy pbis, vagy más) AD-ből authentikáljon a frissen kialakított vm, azt hogyan automatizálnád le? Hol, és milyen credential-t tárolnál az automatikus domainbe léptetéshez?

Tipikusan két lépcsős folyamat szokott ez lenni, az első lépésben előáll egy nagyon alap vm, mondjuk valami cloud-init segítségével a vmware APIn,  ebbe belekerül valami, ami az autmatizációhoz kell (mondjuk egy user, meg egy ssh kulcs, vagy valami hazatelefonálós izé, ha mondjuk puppet, de a cloud-initnek pl van beépített ansible izéje, ami ansible-pullol egyet), onnantól pedig már az automata konfigolja a konkrét igényeknek megfelelelően a vmet, és viszi le pl az sssdhez szükséges konfigot. Ha arra igény van, akkor meg tudja itt azt is csinálni, hogy pl a deployhoz beégetett usert beszántja, hogy a jövőben már ő is mondjuk vmi ADn keresztüli hitelesítéssel jöjjön.

( Celtic v | 2023. 09. 04., h – 16:00 )

MySQL mégsem annyira egyszerű. Egyrészt csak és kizárólag az error.logot képes - másrészt verzióról verzióra (vagy akár mysql - mariadb) is a config. Valami mariadb, mysql 5.7 meg mysql 8.0 és mindhárom más, csodás. De elégedettek lehetnek vele, párnaponta (ha újraindul a mysql), kerül valami a graylogba

 

Csak jegyzetként felírtam, hátha valakinek hasznos lesz

MySQL 8.x
mysql, utána:
INSTALL COMPONENT 'file://component_log_sink_syseventlog';

config fileba:
    syseventlog.tag             = mysql_dev2
    syseventlog.facility        = local1
    syseventlog.include_pid     = On

 (mariaDB)
/etc/systemd/system/multi-user.target.wants/mariadb.service     fileba:
StandardOutput=syslog
StandardError=syslog
SyslogFacility=local1
SyslogLevel=err
SyslogIdentifier=mysql_mon

 (mysql 5.7)
    log_syslog_tag              = mysql_webgalamb
    log_syslog_facility         = local1
    log_syslog_include_pid      = On
    log_syslog                  = On

http://www.micros~1
Rekurzió: lásd rekurzió.

Oh, igen, köszi. Bár igazán a slow.log izgalmas, de azt meg jelenleg sokkal jobb parancssori eszközzel nézni, mint a graylogban :)

ha az oracle mysql-nek is van ilyen, akkor boldogok lehetnek, akiknek az a vágyuk, hogy a graylogban lássák.

http://www.micros~1
Rekurzió: lásd rekurzió.