Názory k článku Icinga: monitorování sítí a serverů
-
Díky, ta část s disky měla hlavně vystrašit, ale ... disky odcházejí různě, já měl štěstí vždy na pomalejší smrt. Patnáct let mi neodešel jediný disk a během posledních čtyř měsíců se u čtyř začaly objevovat chyby ve S.M.A.R.T.u. V serveru jsem jeden vyměnil téměř hned a ten by možná ještě nějaké hraní snesl, na Desktopu ještě běží, ale chová se divně a občas dělá divný zvuky, v netbooku to byla totálka dost rychle, ale taky předem křičel a v notebooku očekávám totálku každou minutou.
Že se disk vypne a už nezapne jsem slyšel jen z vyprávění, kde prý po letech bezproblémového chodu vyschly ložiska a motor to už znovu neroztočil. Dotklo se to všech disků v poli.
-
Hloupý Nemouš (neregistrovaný)
Pokud máte velká a rozsáhlá disková pole (tedy šuplata - externí shelfy) plná disků, zjistíte, že není vůbec nic mimořádného, že prostě disk odejde. Ve firmě používáme hardware od HP a máme na něj napsané vlastní skripty, které vyčítají z diagnostiky serveru varování a chyby. Skoro vždycky se u vadného disku vyskytnou nějaká varování a pak disk umře. Prostě jen tak.... A je po něm. Bohužel, znám i disky, které vesele hlásí varování a do věčných lovišť neodchází. Takže záleží na tom, jak je nastavená firemní politika, co do výměny potencionálně vadného hardware. Otázka nakonec skoro vždy zní: vyměnit, nebo ne (a většinou je odpověď: vyměnit co nejdříve).
Jinak Nagios je bezva, jen občas neohrabaný. Pokud máte spravovat desítky serverů se stovkami služeb, tak si užijete konfigurace.... hojně! -
Nassir (neregistrovaný)
Ved prave :)
Este hadam pred rokom bolo cele rozhranie ako staticke html a hromadka cgi sktiptov. Potom prisiel upgrade a hlavna stranka (jeden jediny sk...y subor) bol odrazu php a v nom dva testy na ip adresu a nazov stranky a.p. Kedze som hrdo urobil upgrade ako inokedy tak som len nechapavo zizal... Vyriesil som to tak, ze som ten subor prepisal jeho vygenerovanou html verziou. V dalsej minoritnej verzii mi uz taketo srandy nepomohli, lebo toho kodu tam dali viac. Tak som musel prekopat celu konfiguraciu, pretoze na php virtualhosty mam dost tvrde naroky a tie sa nezlucuju s vykonavanim cgi suborov a citanim skriptov po celom disku... Pridanie php do nagiosu je fail. Usetrilo robotu jednemu vyvojarovi a mne urobilo z konfiguracie peklo. -
Igi (neregistrovaný)
Nuz len par drobnosty:
- zabezpecenie zacina nie na 7restve ISO/OSI alebo na 4vrstve TCP/IP ale uz aj skor cize naprikald pouzitie iptables je tiez vhodne.- Neviem preco by monitoring server mal byt dostupny priamo z public internetu? Bez toho aby clovek bol autentyfikovany a aurorizovany uz ked nie inak tak len cez ssh (napirklad spojenie Portknocking/autentyfikacia a autorizacia cez kluce a nie cez hesla/nasledne pristup cez TCP port forwarding). A to nevravim o moznosto VPN ...
- Zaroven ako kazdy normalny admin v ramci firmy meniesa VALN-y ale separuje uzivatelov (USER VLAN) od manageemnt/monitoring VLAN-y. Taktiez oddeluje ostatne datove toky. Potom velmy jednoducho sa daju robit ACL lysty alebo iptables ruly.
-
Muff (neregistrovaný)
Mam 100-200 serveru a sluzeb nekolik tisic. Konfiguraci si uzivam ;-)
Generuji ji ruby skriptem z konfiguracni hashe.
Mam templaty podle typu serveru, ktere obsahuji i monitorovane sluzby. Tim mam taky zajisteno, ze na nejakem serveru nezapomenu nejakou beznou sluzbu monitorovat.
Vzhledem k tomu, ze ma nagios&friends relativne jednoduchy textovy konfigurak, neni konfigurace opravdu problem.
-
aquarius (neregistrovaný)
> Pokud máte spravovat desítky serverů se stovkami služeb, tak si užijete konfigurace.... hojně!
Neni to zas tak zly, pomoci sablon se da *hodne* prace usetrit. Taky neni spatnej napad mit konfiguraci v nejakym verzovacim systemu, u vetsiho prostredi se totiz da predpokladat, ze spravu muze delat vic lidi a v tu chvili je changelog zmen k nezaplaceni.
-
Ela (neregistrovaný)
Me to neprijde jako forek a uz vubec ne decentni... :-\
At je zazemi Karla jakekoli, jen 'loser' dokaze takhle uvazovat...
A propo - na co zije pak s manzelkou? At je jeho zazemi jakekoli?
Radeji no comment, pac mozek chlapku je pry ochuzen o jedno pomyslne kolecko a tomu docela verim... :-| -
Rozdílů je dost, ještě se o nich rozepíši.
http://www.icinga.org/wp-content/uploads/2010/08/Icinga-vs-Nagios-matrix1.pdf
-
Když už v článku zaznělo něco o pasivním monitoringu...
Za hlavní nevýhodu Nagiosu považuju to, že při distribuovaným monitoringu musím mít hlídaný uzel nakonfigurovaný na podřízeném i nadřazeném serveru (nebo - nedej Bože - na všech vrstvách, když je jich víc).
Jestliže má Icinga stejné konfiguráky, tak má asi i tuhle blbou vlastnost, že?
P.S. to povídání na začátku článku oceňuju, fakt hezky napsaný a dost ze života :)
-
VS (neregistrovaný)
Tohle:
http://omniti.com/video/noit-oscon-demo
vypadá oproti Nagiosu a jeho nadstavbám jak z jiného světa. Architektura dobře a 100% pochopitelně navržená, web console naprosto úžasná a dotažená do konce. Nemáte to někdo v provozu nebo aspoň otestováno? Konečně jsem asi nalezl řešení, co stojí za to se naučit a nasadit ho, a nahradit jím své in-house dočasné "bastly", co už dočasně běží hodně let...
-
VS (neregistrovaný)
Takže OSS část neobsahuje "alerts and notifications", což je škoda. Ta část ohledně sběru dat je výborná. Alerty jsou součástí hostované služby http://circonus.com
-
zbufg (neregistrovaný)
Chcel by som sa spytat na podobne riesenia. Pri prvom clanku serie by som to ocakaval.
PS: poznam zabbix a vyhovuje mi, ak nepozeram na jeho j......u architekturu. Zabbix pouzivam na monitoring cca 12 strojov, ale poznam firmu, kde monitoruju cca 100 strojov a pouzivaju nejaky distribuovany konfig, co by mohlo byt zaujimave.
PPS: Pekna otazka je, co robite, ked vam skape monitoring? (riesenie dvoch strojov s monitoringom, ktore sa navzajom monitoruju nemusi stacit. poznam z vlastnej skusenosti :)
-
Mordae (neregistrovaný)
Dost dobre nechapu, proc tady lidi tak silene tlaci nagios, kdyz zdaleka nedela vse, co clovek potrebuje. Napriklad neumi sbirat a uchovavat vykonnostni metriky. Takze az vam nekdy spadne vase kriticka aplikace, tak se nedozvite, ze to bylo pameti. Az zacne nejaky almost-RT system hlasit timeouty ze strany databaze, tak neuvidite zvyseni odezev na poli, nedohledate snadno vinika podle ostatnich grafu... nemate zadnou poradnou retrospekci a vhled do systemu pred X hodinami.
Ach jo.
