központi syslog kéne...

Hálózatok általános

...vagyis, hogy központi syslog az már van (syslog-ng), különböző eszközök loggolnak is rá, még Windowshoz is találtam syslog megoldást. :) De ez így jelenleg csak egy log archívum, kb greppelni lehet benne, ha valami kell, de nem túl kényelmes, meg nem is átlátható.

Kellene nekem valami ami ennél több, amiben lehet kényelmesen keresni, szűrni, statisztikákat látni, esetleg még egy két eseményre riasztást/akciót is generálni. Mindezt valami webes interface-szel képzelem el, gondolom vannak ilyen cuccok, de én egyet sem ismerek, érdekelne, hogy ki mit tud erre ajánlani.

Minden megoldás érdekel, open source vagy fizetős is lehet, épülhet a jelenleg használt syslog-ng-re is, de ha azt is le kell cserélnem az sem gond.

--------------------------------------------------------
Update1 2015.10.05

Az alabbi lehetosegek merultek fel komolyabban a hozzaszolasokban:
* Syslog-ng Storebox
* Logalyze
* Graylog
* ELK (Elasticsearch, Logstash, Kibana)
* Splunk
* Fluentd

Ezek kozul vegul az ELK-t valasztottam, mert tetszett, hogy modularis es ugy tunt egyre nepszerubb.

Egyelore nem vagyok 100%-ig elegedett. Mukodni mukodik a dolog, de nem vagyok semmivel elorebb minthogy eddig volt egy kozponti syslogom hostonkent levalogatott logokkal. Jelenleg a Kibanaban latom az osszeset, de minden hosthoz kulon search-ot kell csinalnom, hoston beluli esemenyekre meg gyakorlatoilg semmilyen beepitett filterem nincs. Gyanitom az a baj, hogy a logstashhez kene mindenfele pluginokat felraknom, hogy azok ertelmezzek mondjuk a Windows altal kuldott logot es jol feltageljek. Ugye?
Kicsit bonyolitja a helyzetet, hogy kozponti syslogomat nem dobtam felre, az kuldi az osszes logot a logstash-nek igy a kuldo hostnak a kozponti syslogom latszik...

  • 5217 megtekintés

( hardhead | 2015. 08. 24., h – 16:53 )

Ajánlom magamat... ;)

Ugyan van webes interfész a massalyzerhez, de az inkább a menet közbeni kontrollra való...

Jelenleg készül az ablakos, "összekattintós" kiegészítés.

A doksiban még nem szerepel, de azóta már elkészült jó néhány rugalmasan használható plugin is hozzá. Ha úgy döntesz, hogy érdekes lehet az alábbi linken talált dolog, de kellene segítség, akkor fordulj hozzám bátran!

Bővebben: http://www.massalyzer.com/hu

Üdv.!

en is megneztem a weboldalt, es semmit nem latok, ami miatt ezt valasztanam a kibanaval szemben. Nem gyoz meg a weboldal semmirol. Keress meg egy UX-hoz erto embert, meg keress meg egy marketingest, akkor ket nagysagrenddel tobb ugyfeled lesz, mint most.
--
Blog | @hron84
Üzemeltető macik

( lilo v | 2015. 08. 24., h – 16:40 )

Szia

Esetleg nézd meg ezt:

http://logalyze.com/

Webes, opensource és ha kell lehet venni hozzá kereskedelmi támogatást is.

(ui: partnereik vagyunk)

( _ventura_ v | 2015. 08. 24., h – 19:34 )

nálam rsyslog + logstash + elasticsearch + kibana alkotja a "logszervert"

Fedora 22, Thinkpad x220

Ha nem akarsz bonyolultabb dolgokat megcsinálni a központi logszerveren, akkor akár jó is lehet, de egyébként a konfigurálása khm. messze nem optimális. Ja, és a file felolvasásban kellemes bugot lőttünk: Ha a fájl utolsó sora "csonka", azaz nem "\n" az utolsó karaktere (mert ami a fájlt írja, a bufferelt írást csinál, és van, hogy fél sor jön ki), akkor azt a fél sort jól kihagyja... RHEL, wontfix, anyád.

Nem kéne, épp ez a gond: a logba a kiírás az utolsó "\n"-ig történik meg, a "logba kiírva" jelölő viszont a fájl tényleges végére mutat, és a következő olvasáskor onnantól kezdve írja ki a logba a sort - azaz yool adatot veszít, mert a fájlba félig kiíródott sor eleje nem kerül bele a logba.

a kozvetlen elastic-ba tolasra kepes az open source syslog-ng is? Ha igen, van errol valami leiras? A neten egyelore csak logstash beiktatasaval lattam leirasokat.

update: ehh, a 3.6 doksija elobb jott gugelben, de a 3.7-nel mar van ra hivatkozas, nezzuk...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Csak az OSE kepes erre. 3.6 eseteben az Incubator kepes erre, tobbfelekeppen: program() -on keresztul, vagy perl, vagy python modul segitsegevel (program()-nal azok jobbak, de nem sebessegkiraly egyik sem). 3.7-ben van nagyon utos Java tamogatas. Azzal picit nagyobb melo osszerakni az ElasticSearch destinationt, cserebe sokkal hatekonyabb, mint a korabbi megoldasok.

Egyebkent kb 3.4 ota megoldhato az ElasticSearch-be iras kozvetlenul, 3.5 ota program() nelkul.

3.5 + Incubator setuppal kb ennyi: https://asylum.madhouse-project.org/blog/2015/05/07/grepping-logs-is-st…

--
|8]

A 300 körüli logforrásból 120-nak a logjait az "aaa", 100-nak a logjait a "bbb", míg a maradéknak a logjait a "ccc" csoportnak kell tudnia olvasni a logszerveren (a fájlokat birtokló csportot kell ennek megfelelően állítani, és csoport olvasási jogot adni rá). Ezen felül bizonyos logforrások meghatározott logjait tovább kell küldeni az sss, illetve a lll szerver felé. Továbbá ha meghatározott forrásból érkező logban előfordul bizonyos minta, akkor levelet kell küldeni n+1 usernek. Satöbbi. A központi logszerver nem minden esetben egy nagy bödön, amire csak tolja mindenki a logokat, és nem kerül továbbításra/további feldolgozásra helyben... A fenti feladatlista egyébként közel sem teljes - ezt a sorosan feldolgozásra kerülő rsyslog.conf használatával megvalósítani... Szóval a rúdaszpirin kellemetlenebbik végén történő térdeléssel ér fel.
A küldő oldalon meg fel kell olvasni _normálisan_ n+1 logfájlt is, a fél sorokat nem el...va (retek5-ben lévő mindkét rsyslog verzió bugzik ebben, de ha jól tippelem, még a retek6-ban is olyan van...)

Nezd, szep az, ami erdek nelkul teszik. Ha valakinek a regi formatum jon be, az uj meg nem, hat hasznaljon rsyslogot, legyen boldog vele. Kotelezni nem kotelez senki, hogy azt hasznald, a syslog szerver - bizonyos korlatok kozt - szabadon lecserelheto a rendszeren.
--
Blog | @hron84
Üzemeltető macik

( dzsambo | 2015. 08. 24., h – 21:27 )

nálam rsyslog + loganalyzer bár csak 1 fájlt olvas, én csak hálózati eszközök
syslog üzeneteit nézegetem vele.

Esetleg tud valaki olyat ami több fájlt is olvas?

lehet hogy rosszul gondolom, de én külön fájlba gyűjteném a pl: hálózati eszközök, squid, szerver syslog stb. üzeneteket és ezeket jó lenne elkülönítve látni webes felületen, nem egy nagy halmazban.

Lehet rossz a megközelítésem, autodidakta módon tanulom az üzemeltetést úgy meg azért kicsit nehéz.

Az, hogy elkulonitve latod, semmilyen modon nem jelenti azt, hogy kulon fileba kene tenni. Az a webes felulet ami kozvetlenul logfileokbol dolgozik, hasznalhatatlan fos.

Mindegyik ertelmesebb webes logbongeszo, analizalo, stb eszkoz ennel azert csoppet szofisztikaltabb, es tipikusan valamifele adatbazisbol dolgozik (lett legyen az SQL, vagy ElasticSearch, vagy sajat fejlesztes, vagy akarmi).

--
|8]

A logelemző pont arra jó, hogy akár az egyetlen fájlba gyűjtött adatokat is szépen szét tudja szortírozni - ha épp az kell kell - , számlálni, beavatkozásokat kezdeményezni, stb. A külön gyűjtéssel csak bonyolítod a feladatot. Biztosan van olyan amikor elkerülhetetlen a dolog. Én pont erre vagyok kíváncsi.

A több fájl olvasására 2 lehetőséget látok és nem tudom eldönteni, hogy melyik a jobb megoldás:

1. Egyszerűen megnyitni több fájlt és a timestamp sorrendjében felolvasni a különböző fájlokból a sorokat.

2. Megtartani, hogy egy massalyzer példány egyszerre csak egy "fizikai" fájlt olvas, de adott események kimenete egy IP-n kapcsolt másik massalyzer példány. A felismert minta alapján elküldi a megfelelő adatokat a másik példánynak. Egy ilyen "másodlagos" példány pedig akár több elsődleges példányhoz is kapcsolódhat. Így, ha korreláció keresésről van szó, akkor ez a másodlagos példány végezné el. (Ez nem is olvasna közvetlen fájlból.) Ez utóbbi példány tehermentesítve lenne a nyers kereséstől és akár elosztott elemző rendszereket is lehetne így építeni.

Nekem a második megoldás szimpatikusabbnak tűnik, de nem tudom, hogy a felhasználókat lehetne-e terhelni egy kicsit bonyibb megoldással.

Az olvasás technikája mellékes. A felhasználó úgyis csak annyit érzékel, hogy több fájlt adhat meg inputként. (Magával az olvasás technikájával nincs gond. Persze fent leegyszerűsítettem, mert részleteibe nem akartam belemenni.) Inkább csak az volt a kérdés, hogy vajon megéri-e bonyolultabb megoldást lehetővé tenni. (Ugyanis az több tervezést igényel a felhasználótól - hiszen több példány fut és ezek kapcsolatait is végig kell gondolni -, szemben az egyszerű inputok megadásával.) A kérdésed alapján behúztam egy strigulát az egyszerűbb megoldás mellé. :)

Lehet, hogy félreérthető volt a kérdés, elnézést! Kifejezetten felhasználói szemszög érdekelt, nem a programozástechnika.

"hiszen több példány fut és ezek kapcsolatait is végig kell gondolni" - ez az, amit mar az elejen se ertettem. Miert kellen tobb peldanynak futni, mi haszna lenne ebbol a felhasznalonak? Ha maga a GUI (amit szemermesen rejtegetsz mindenki elol) el tudja valasztani valahogyan az inputokat, akkor senki nem fog akarni tobb peldanyt futtatni a cuccbol.
--
Blog | @hron84
Üzemeltető macik

"Miert kellen tobb peldanynak futni, mi haszna lenne ebbol a felhasznalonak?"

Nem kell, hanem lehet(ne). Abban gondolkodom, hogy nagy terhelésű rendszereknél is használható legyen. Akkor kifejezetten előny lehet, ha szét lehet osztani gépek között a real-time feldolgozást. Ezt viszont - ha már kész - elvileg fel lehet használni arra is, hogy több fájlból olvasson egyszerre...

"Ha maga a GUI (amit szemermesen rejtegetsz mindenki elol)..."

Nem rejtegetem, hanem még nincs. (A visszajelzések alapján nemrég kezdtem bele.) Az eredeti koncepcióm az volt, hogy minimális - mondjuk egy SSH kapcsolatot - feltételeztem, mivel egy Linux szervernek nem igazán "kötelessége", hogy X is legyen rajta így nem a GUI volt a fő csapásirány.

"... el tudja valasztani valahogyan az inputokat, akkor senki nem fog akarni tobb peldanyt futtatni a cuccbol."

Igen, megértettem. Ha nem is senki, de kevesen. Köszönöm! Mindenképpen figyelembe veszem!

Egyelőre egy spec. .ini szerkesztő lesz, amivel egyszerűbb összedobni az adott feladatot. (Aztán ki tudja mivé növi ki magát.) A többin még filózom. Eddig arra lett kihegyezve a kód, hogy rugalmasan konfigurálható legyen, közre tudjon működni más programokkal és a lehető leggyorsabban tegye a dolgát. Nem arra, hogy menet közben konfigurálni távolról konfigurálni lehessen. Ha nem akarok sebességcsökkenést, akkor mindenképp kell valamit írni hozzá. Ez lehet egy vastag kliens is, de ha nem, akkor szerver oldalra is kell valami még, mert a mostani programot- főleg real-time feldolgozás közben - nem szeretném további http kérésekkel bombáztatni.

Jelenleg alapvető dolgokat lehet el lehet távolról is érni böngészőből, de túlságosan nem szeretném a szolgáltatásait elbonyolítani. Szeretném meghagyni azt, hogy gyakorlatilag a futtatható kód felmásolásával működjön a dolog, ne kelljen hozzá semmi egyéb. (pl. Apache, MySQL, akármi, stb.) Szóval ha valami szolgáltatásbővítés lesz még, akkor mindenképpen valami új dolgot hozzáfejleszteni, ami tartja a kapcsolatot a klienssel. Adott esetben még az is lehet, hogy egy vastagkliens (is ?) lesz. Még nem döntöttem. Megfontolom a tanácsod.

( zeller | 2015. 08. 24., h – 21:52 )

A Syslog-NG-t ne akard lecserélni - nem nagyon van kényelmesebb :-P A log mazsolázásához splunk-ot javaslok.

( Anubisss | 2015. 08. 24., h – 22:51 )

cloud:
- papertrail: http://help.papertrailapp.com/kb/configuration/configuring-remote-syslo…
- loggly: https://www.loggly.com/docs/syslog-ng-manual-configuration/
- logentries: https://logentries.com/doc/syslog-ng/

self hosted:
- ELK stack: https://www.elastic.co/webinars/introduction-elk-stack, Elasticsearch -> tarolas/kereses, Kibana -> analitika, Logstash -> log aggregalo
- splunk: http://www.splunk.com/
- fluentd: http://www.fluentd.org/
- graylog: https://www.graylog.org/

( pirate | 2015. 08. 25., k – 11:05 )

Splunk?

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( uid_194 | 2015. 08. 25., k – 18:12 )

syslog-ng + elasticsearch + kibana trio szerintem tok jo lehet. Osszeloni sem nagy ordongosseg. (Nalam ez a trio futott sokaig, mostansag a syslog-ng resz egyes klienseken mar kiesett, de ElasticSearch es Kibana maradt.)

--
|8]

SSB egy fostalicska. Egyetlen elonye, hogy az indexeles gyorsabb (de annak meg eleg huzos ara van, olyan limitaciok, amikkel en nem szeretnek egyutt elni), a kereses is gyorsabb lehetne, ha az UI nem lenne ratyi. Viszont ES+Kibana paros sokkal komplexebb kereseseket enged meg, egyszerubben skalazhato, szebben nez ki, tobb hozza a doksi, stb.

Szoval nagyjabol minden teren veri az SSB-t. Es most mar - ha jol remlik - commercial support is van hozza, igy SSB-nek ez az elonye is buko.

--
|8]

Persze integralva nem lett amig ott voltam.

akkor mar ertem, miert nem birtad tovabb :-)

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Semmi koze nem volt a tavozasomnak ehhez. syslog-ng OSE volt a feladatom a cegnel, SSB-s hackatonos PoC az mokabol volt, nem erdekelt, mi lesz vele. Nem is jutottunk el olyan szintig PoC-cal, hogy realisan integralni lehessen, csak azt akartuk elerni, hogy lassuk, lehet modernizalni a feluleten, es felmerjuk, mekkora befektetest igenyel ez. Ilyen szempontbol a PoC teljesen es tokeletesen elerte a celjat.

--
|8]