Application monitoring

Ojla, ker imam svoj sistem za monitoring ze rahlo zastarel (nonflexible html) in ni cajta za dodelave, bi rad poskusil kaj modernejsega.
Gre izkljucno za monitoriranje aplikacij (ne sistema), kar mora imeti je:

- hiter prikaz (najverjetneje v smislu elasticsearcha) real-time stanja
- direkten udp transport (tcp ne pride v postev)
- centralni sistem *BREZ* agentov (aplikacije bojo same posiljale podatke v ta sistem)
- logi (aplikacije posiljajo loge preko udp), v browserju mora biti moznost live, da se spremlja real-time
- metrika (aplikacije posiljajo metrike preko udp) - grafi, statistike, mogoce tendence ipd.
- alarmi (aplikacije posiljajo alarme preko udp)

Sistem naj bo cimbolj blackbox (razne skripte, tisoc pluginov itd. ne pridejo v postev), ce je treba tudi placljiv.
Tako da po hitrem iskanju razni nagiosi, graylog ipd nekako ne padejo v te zahteve.

Sedajsen sistem mi iz aplikacij v posebnem threadu(queuing) posilja po udp na centralni sistem, zato bi rad, da zgolj spremenim lib za kreiranje udp paketa
Uporablja oz. pozna kdo kak tak sistem zdajsnjega cajta ? :)

Mavrik je 15. sep 2018 ob 15:23 izjavil:

A je morda NewRelic nekaj kar bi ti ustrezalo?

Zal ne (kot vidim, uporablja agente, logging je neuporaben, udp je na wish listi). Ma pa zlo fajn frontend na prvi uc :)
Verjetno bolj namenjen za kontrolo nad skriptami ipd.
Ti to uporabljas sicer ?

kunigunda je 15. sep 2018 ob 14:18 izjavil:

Ojla, ker imam svoj sistem za monitoring ze rahlo zastarel (nonflexible html) in ni cajta za dodelave, bi rad poskusil kaj modernejsega.
Gre izkljucno za monitoriranje aplikacij (ne sistema), kar mora imeti je:

- hiter prikaz (najverjetneje v smislu elasticsearcha) real-time stanja
- direkten udp transport (tcp ne pride v postev)
- centralni sistem *BREZ* agentov (aplikacije bojo same posiljale podatke v ta sistem)
- logi (aplikacije posiljajo loge preko udp), v browserju mora biti moznost live, da se spremlja real-time
- metrika (aplikacije posiljajo metrike preko udp) - grafi, statistike, mogoce tendence ipd.
- alarmi (aplikacije posiljajo alarme preko udp)

Sistem naj bo cimbolj blackbox (razne skripte, tisoc pluginov itd. ne pridejo v postev), ce je treba tudi placljiv.
Tako da po hitrem iskanju razni nagiosi, graylog ipd nekako ne padejo v te zahteve.

Sedajsen sistem mi iz aplikacij v posebnem threadu(queuing) posilja po udp na centralni sistem, zato bi rad, da zgolj spremenim lib za kreiranje udp paketa
Uporablja oz. pozna kdo kak tak sistem zdajsnjega cajta ? :)

- Kaj je zate hiter prikaz?
- Izogibaj se UDP, če ti je monitoring pomemben. Drugače SNMP, če sistem podpira, ampak aplikacija ga ponavadi ne .
- Izogibaj se pošiljanja logo preko UDP, ker boš v primeru izpada mreže izgubil vse. Real time nikoli ne rabioš. Res malokrat...
- Metriko shranjuj lokalno, magari v CSV. Pošlješ to potem nekam preko syslog protokola. To je zadosti zanesljivo. Zgoraj isto...
- Alarmi, O.K., ampak prepiši aplikacijo v TCP in uporabljaj standardne protokole. Ti bo na dolgi rok lažje.

Realnost je taka, da so varnostni inženirji alergični na UDP , poleg tega ni secure, če ne enkriptiraš sporočila pred pošiljanjem, kar pa spet zakomplicira zadevo.

Sam bi implementiral lokalni sprejemnik UDP (syslog-ng recimo), zadeve vsaj nekaj časa shranjeval tudi lokalno (txt file, kaka manjša baza) za vsak primer.

Je pa vse odvisno kako pomembni so ti ti podatki.

Ali je to samo tvoja želja po real-timu in gre predvsem za preseravanje ali je to zahteva uporabnikov. Pozabi na real-time zadeve iz filmov, to deluje samo tam .

Invictus je 16. sep 2018 ob 10:06 izjavil:

- Kaj je zate hiter prikaz?
- Izogibaj se UDP, če ti je monitoring pomemben. Drugače SNMP, če sistem podpira, ampak aplikacija ga ponavadi ne .
- Izogibaj se pošiljanja logo preko UDP, ker boš v primeru izpada mreže izgubil vse. Real time nikoli ne rabioš. Res malokrat...
- Metriko shranjuj lokalno, magari v CSV. Pošlješ to potem nekam preko syslog protokola. To je zadosti zanesljivo. Zgoraj isto...
- Alarmi, O.K., ampak prepiši aplikacijo v TCP in uporabljaj standardne protokole. Ti bo na dolgi rok lažje.

Sej SNMP dela prek UDP by default :)
Logi + morebitni alarmi se shranjujejo tudi v dnevni fajl lokalno na serverjih za double check, tud metrika je
prav tako lokalno (in se jo prek api-ja dobi na request).
Drgac mi ta sistem preko udp dela 10+ let uspesno (tud net izpada k sreci ni blo, ceprav mam loceno mrezo za te OM stvari).
Real time dostikrat rabim, ce se sumi na problem, se nardi test, kjer se gleda loge.
Zelja po nadgradnji je zato, ker dosti ljudi spremlja dogajanje, dostopa do samga sistema nimajo, ker ga nocem dat,
in spremljajo centralno, nimam pa cajta vec vzdrzevati nadzornega sistema, ki je zarad zgodovine in veliko podatkov postal okorn,
tud ne uporablja nobenga javascripta in je vse na nacin refreshov, grafi pa se celo preko gnuplota.
Skratka, podatki so, tako lokalno kot centralno, sam frontend bi posodobil z necim boljsim(lepsim).
V skrajnem primeru bom sicer verjetno locil stvari (logi,alarmi na en sistem, grafi na grafane, ki so tudi ze v nadzoru,
ampak v prvi vrsti gledam za all-in-one sistem :)

Invictus je 16. sep 2018 ob 15:29 izjavil:

SNMP v normalni firmi danes dela preko TCP z enkripcijo (V3). Že dolgo UDP ni edini protokol, ki ga SNMP podpira .

Če je zate real time to, da gledaš loge, potem to ni ravno real time .

Good look for cheap, low work, all in one system .

Vem, ker delam monitoring že kar 15 let poklicno...

Lahko pa cloud solution .

TCP z enkripcijo, 1000packets/s z 8 serverjev po 10 servisov ? Out of question.
Za UDP mi dost zasici OM network ob spicah. Poleg tega je SNMP uporaben zgolj za metrike, za loge pa ne vidm smisla v njemu.

kunigunda je 16. sep 2018 ob 16:50 izjavil:

TCP z enkripcijo, 1000packets/s z 8 serverjev po 10 servisov ? Out of question.
Za UDP mi dost zasici OM network ob spicah. Poleg tega je SNMP uporaben zgolj za metrike, za loge pa ne vidm smisla v njemu.

Monitoring 80 servisov 1000 packets/s ?!?!?!

Očitno delaš nekaj narobe , da ti monitoring zabaše mrežo. Ali pa imaš zanič mrežo .

Real time monitoring zahteva zelo veliko resourcov, za katere te bo vsak poslal v 3PM...

SNMP ni samo za metrike ... (kaj povprečen Itjevec ve o SNMP ) ... lahko je za karkoli. Je pa pošiljanje logov seveda butasto s SNMP. Lahko pa jih... Za to imaš syslog... Poleg tega je syslog precej bolj preprost...

Invictus je 17. sep 2018 ob 16:55 izjavil:

kunigunda je 16. sep 2018 ob 16:50 izjavil:

TCP z enkripcijo, 1000packets/s z 8 serverjev po 10 servisov ? Out of question.
Za UDP mi dost zasici OM network ob spicah. Poleg tega je SNMP uporaben zgolj za metrike, za loge pa ne vidm smisla v njemu.

Monitoring 80 servisov 1000 packets/s ?!?!?!

Očitno delaš nekaj narobe , da ti monitoring zabaše mrežo. Ali pa imaš zanič mrežo .

Real time monitoring zahteva zelo veliko resourcov, za katere te bo vsak poslal v 3PM...

SNMP ni samo za metrike ... (kaj povprečen Itjevec ve o SNMP ) ... lahko je za karkoli. Je pa pošiljanje logov seveda butasto s SNMP. Lahko pa jih... Za to imaš syslog... Poleg tega je syslog precej bolj preprost...

Zabase jo glih ne, se pa poznajo spice, itak je optika z loceno mrezo. Drgac ma vsak servis po 1000/s spice, odvisn od requestov uporabnikov, zato mam tud locen queueing za te loge (kjer se pol pise po fajlih in udp-jih), ce bi vklopu se ful trejs bi blo pa dodatno tono solate, sam tega ne uporabljam.
Syslog je neuporaben za moje log. Prov tako snmp (za metrike sem razsiril snmp s stvarmi ki jih nima), je bolj namenjen server viewju ne task viewju, pa se z mibi se mors pol ukvarjat. no time.
Verjetn bom metrike mogu kalkulirat pa v kako grafano posiljat, ce ne se ne bo ta graylog izkazu. Bom vidu, kaj bojo v it nastudiral, test sm jim naredu, cajta majo pa 1 tedn :)
Ce ne bom pa na obstojecem sistemu ostal, pa se bodo operaterji mogl skulirat in ne gledat, kako lepo majo drugi oddelki (ki imajo zgolj simpl stvari :)