monitorizarea unei retele
TRANSCRIPT
Cuprins
Introducere …………………………………………………………………………………….... 3
1. Sisteme de Monitorizare a unei rețele de calculatoare. …………….……………………… 3
2. Întrebuințarea sistemelor de monitorizare. ………………………….……………………....3
3. Scopul Monitorizării. ………………………………………....…………………………….. 4
Capitolul I. Softuri pentru monitorizare…………………………………………………………..5
1.1. Softuri pentru monitorizare... ………………...…………………………………………...5
1.2. MRTG (Multi Router Traffic Grapher) ….……………………………………………......5
1.3. RRDtool (Round-robin Database). ……………………………………………………......6
Cum funcţionează Sistemul de monitorizare RRDTool. …………………………………..8
Controlul traficului. ………………………………………………………………………..8
1.4. Munin. ………………………………………………………………………………….....9
Pugin-urile ………………………………………………………………………………...9
1.5. Nagios ……………………………………………………………………………………11
Proprietăţi ale sistemului de monitorizare Nagios. ………………………………………12
Serviciile care sunt oferite de acest soft. …………………….……………………...…....21
Cum funcționează Nagios ………………………………………………………………..23
Capitolul II. Implementarea unui sistem de monitorizare……………………………………….25
2.1. Implementarea sistemului de monitorizare pentru organizaţia NicrutNet S.R.L……….25
2.2. Configurarea MRTG. …………………………………………………………………...25
Instalarea MRTG. ……………………………………………………………………....26
Instalarea rutei în MRTG ……………………………………………………………....28
2.3. Instalarea sistemului de monitorizare RRDTool……………………………………… ..29
Crearea bazei de date in RRDTool (rrdb)………………………………………………. 33
2.4. Instalarea sistemului de monitorizare Munin………………….………………………...34
2.5. Configurarea sistemului de monitorizare pe server……………………………………...36
2.6. Configurarea unui client care va fi monitorizat………………………………………….39
Concluzie………………………………………………………………………………………...41
Bibliografie ……………………………………………………………………………………...42
Anexe…………………………………………………………………………………………….43
Introducere
1. Sisteme de Monitorizare a unei rețele de calculatoare.
Monitorizarea reprezintă observarea si înregistrarea regulata a serviciilor din cadrul unui
server sau a unui element din rețea. Acest proces presupune colectarea informațiilor referitoare la
toate aspectele unui server .
A monitoriza înseamnă a urmări desfășurarea proceselor incluse intr-un server. Aceasta
presupune observarea sistematica a serviciilor proceselor care se desfasoara in rețeaua pe care o
monitorizam.
Monitorizarea presupune de asemenea informarea periodica a celor care au grija de rețea si
de serviciile care sunt monitorizate.
Raportarea datelor culese permite luarea unor decizii la rezolvarea problemelor care apar si
duc la imbunatatirea serviciilor care sunt prestatate intr-o rețea unde avem un sistem de monitorizare.
2. Întrebuințarea sistemelor de monitorizare.
Monitorizarea rețelelor adesea evoca astfel de detalii cum ar fi traficul routerelor, Quality of
Service (QoS), calitatea experienţei (QoE), detectarea intruziunilor, raportarea şi alertare de reţea şi
de disponibilitatea sistemelor, de obicei sub controlul unui web-based GUI. Dar, de fapt, conceptul
de monitorizare a rețelei este de a deveni parte a unui proces de monitorizare mult mai mare care
implica examinarea în timp real şi trucuri a procesului din întreaga afacere.
Asta nu ar însemna ca sa nu acordam o atenţie la detalii, cum ar fi QoS şi elementelor de reţea. Un
sistem de monitorizare ajuta foarte mult unui furnizor de reţea şi echipamentelor sale de comunicaţii,
permiţând astfel administratorului de reţea sa examineze complet fluxului de date şi să identifice
zonele cu probleme până la nivelul de pachete folosind o interfaţă grafică. Am observat necesitatea
de a implementa câteva tipuri de monitorizare pentru a avea la orice ora cit mai multe date si mai
multe statistici legate de rețea. De exemplu când se monitorizează VoIP se atrage foarte multa
importanta la datele cu care ele lucrează, si aceste parți ale monitorizării sunt traficul in diferite
parți, aspectul QoS este la fel foarte importanta in comparație cu date ordinare care nu se executa in
timp real. Deci un sistem de monitorizare ia o privire în toate, traficul de date, serviciile prestate, şi
permite să efectuezi o reţea de depanare şi de monitorizare a serviciilor care sunt oferite.
Un sistem de monitorizare a rețelelor are posibilitatea sa analizeze pachete aninate, de bruiaj,
pachetele pierdute, pachete aruncate, folosind un algoritm care generează aceste informaţii si
afisindule cit mai comod nou. Intr-o interfața grafica comoda si ușor de inteles. Toate acestea permit
2
furnizorului de servicii să vadă ce se întâmplă cu calitatea serviciului sau sa vadă ce se întâmpla cu
serviciile pe care el le prestează la moment. Deja nu mai este nevoie sa stea multa lume in fata
aparatelor si sa urmărească după ele. Acum e mult mai simplu având un sistem de monitorizare te
poți conecta la el si in orice timp poți sa vezi ce se întâmpla in rețea sau ce e cu serviciile prestate.
Uitându-ne in sistemul de monitorizare, putem determina toate informaţiile menţionate mai
devreme legate de ceea ce se întâmpla la intrarea şi ieşirea de la router din partea clientului. Acest
lucru permite furnizorului de servicii să monitorizeze rețeaua cu un pas mai înainte şi să
monitorizeze efectiv traficul de si serviciile oferite.
Un sistem bun de monitorizare va permite, de asemenea, să vizualizaţi şi să raportați
conţinutul şi istoricul datelor stocate, statisticile de performanţă, şi să monitorizați starea de sănătate
a reţelei în funcţie de locaţie sau de client. Dar, in funcție de ceea ce face retezau noastră este nevoie
ca sa configuram acest sistem de monitorizare cit mai bine si sa ne colecteze cit mai multe date si cu
precizie mai mare.
3. Scopul Monitorizării.
Monitorizarea este extrem de importanta intr-o rețea. De ea depinde funcționarea buna si
rapida a rețelei, calitatea serviciilor prestate in rețea. Ea poate fi comparata cu mersul pe bicicleta;
doar privind înainte poți alege direcția corecta.
Informațiile obținute prin monitorizare pot fi folosite pentru:
1. A analiza situația serviciilor si a serverului monitorizat.
2. A determina daca resursele implicate sunt utilizate corespunzător;
3. A identifica problemele cu care apar si a lua posibilele soluții pentru rezolvare lor;
4. A se asigura ca toate serviciile sunt efectuate corect si la timp in rețea.
5. A avea informația cum lucrează utilajele care sunt folosite in rețea.
6. A urmări după toate procesele care au o importanta in rețea.
3
Capitolul I. Softuri pentru monitorizare.
1.1. Softuri pentru monitorizare.
Pentru monitorizare se pot folosi multe softuri, unele din ele sunt gratis cu licențe GPL
(General Public License) iar altele sunt cu bani. Softurile de monitorizare ca MRTG (Multi Router
Traffic Grapher), RRDtool (Round-robin Database), Munin şi Nagios sunt descrise mai jos.
1.2. MRTG (Multi Router Traffic Grapher)
Vă puteţi imagina un instrument de monitorizare care poate monitoriza performanţa
dispozitivelor de reţea, sistemelor, aplicaţii şi parametrii de mediu, în acelaşi timp? Toate acestea pot
face programul Multi Router Traffic Grapher (MRTG) pentru o configurare corectă a fişierelor de
configurare. MRTG generează pagina HTML formatul de imagine PNG (Portable Network
Graphics) pentru reprezentarea grafică a statisticilor de trafic. Puteţi configura pentru a monitoriza
orice variabile SNMP, cum ar fi sistemele de încărcare sau interfeţe de reţea.
Cele mai multe dintre toate, MRTG este util pentru administratorii - le dă posibilitatea de a
monitoriza modul de utilizare a resurselor de reţea. Multe organizaţii utiliziază acest program pentru
a monitoriza reţelele lor, şi aplicaţii. Dezvoltatorul comunitare MRTG regulat creaza actualizări
software şi extinde capabilităţile sale. Programul a fost scris în Perl Tobias Outaykerom Institutul
Naţional al Danemarcei, o cercetare de mediu în 1994 şi a fost conceput iniţial pentru a monitoriza
sarcina de canal care leagă reţeaua Institutului la internet. Mai târziu, Ofiţer ale Cisco Systems, Dave
Rand a îmbunătăţit eficienţa codului, scrise pentru el de către un modul pe limbajul C. Puteţi obţine
codul MRTG gratis în conformitate cu termenii GNU General Public License. Desigur, alegerea
software open source, ea si ceva sacrificii. Şi preţul de sacrificiu - de timp petrecut pentru a o studia,
instalaţia şi să menţină în stare de funcţionare. Acelaşi argument, în principiu, valabil pentru software
comercial, dar în acest caz, cel puţin, au un furnizor care poate fi criticat pentru faptul că produsul nu
funcţionează.
Pachetul MRTG care rulează pe platforme Unix, Linux şi Microsoft Windows. Cel mai bun
din toate, se execută lucrări Solaris, Linux, Windows NT, 2000 şi XP. O încercare de a lansa MRTG
sub Windows 98 sau ME nu merita efortul pentru a încerca: Nu se instalează numai pe SNMP, dar
realizează, de asemenea, configurări MRTG suplimentare. Pe lângă platforma
Windows 98 şi ME este instabilă şi de aceea mai bine de plecat la Linux sau Windows 2000 / XP.
Pentru a începe lucrul cu MRTG, nu trebuie sa fii un expert în domeniul de cunoaştere a C sau
4
Perl. Există mai multe ghiduri care vă pot ajuta ca să îl configuraţi pentru a monitoriza interfeţe de
reţea. Tot ce trebuie să ştiţi - aceasta este adresa IP şi socket de comunitate pentru dispozitiv. Dacă
doriţi să utilizaţi MRTG pentru a efectua mai multe sarcini complexe de monitorizare, trebuie să
învatati limbajul Perl. Montarea de limbaj este simplu. Tot de ce e nevoie de ceva pentru a rula
script-ul de instalare pe un calculator care rulează Windows NT sau de instalat pachetul RPM pe
Linux. Pe Web-site-ul MRTG sunt linkuri la distribuţia gratuită Perl - ActivePerl - din partea
societăţii ActiveState, pentru a o instala la fel de uşor ca orice alta aplicație Windows.
MRTG lucrează, astfel citește datele din protocol SNMP GET citeşte periodic valorile
contra SNMP, de exemplu ifInOctets (OID 1.3.6.1.2.1.2.2.1.10) şi ifOutOctets (1.3.6.1.2.1.2.2.1.16),
care înregistrează numărul de intrări (ifInOctetes) şi de ieşire (ifOutOctets) octeţi pentru această
interfaţă. Ambii parametri sunt afișați într-un calendar în PNG pentru pagina HTML. Aceşti
parametri se pot referi la orice dispozitiv, de la router la server. Ei bine, asta oferă MRTG etichete
predefinite, care sunt salvate de administrator.
Datele reprezentate sub forma de grafice de doua culori diferite - implicit albastru şi verde, cu
semnături caz, celebra minim, valorile maxime şi medii. În cele din urmă veţi obţine o imagine
completă a stării actuale a dispozitivului de observat.
MRTG afişează valorile medii ale parametrilor monitorizate în timpul săptămânii, lună şi an,
calculate pe baza unor măsurători efectuate la intervale de 5 minute. Un program săptămânal se
bazează pe intervale de o jumătate de oră, cu o medie a rezultatelor de şase ori consecutiv. În
consecinţă, graficul lunar se bazează pe date pentru intervale de o săptămână în medie 2 ore, iar
anual - datele pentru luna în medie la fiecare 24 ore frecvenţa cu care a colectat şi medie de date la
intervale adecvate puse în aplicare în instrumente de monitorizare.
Un pachet de MRTG nu susţine o baza de date exterioara. Informaţiile sunt stocate în fişiere de
tip text ASCII, care sunt şterse imediat după utilizarea lor pentru a calcula mediile de săptămâni, luni
şi ani. Exemplu, datele din diagramă lunar, nu puteţi obţine mai multe informaţii detaliate despre
sarcina maximă într-o anumită zi. Dacă aveţi nevoie de informaţii mai detaliate privind MRTG,
instalaţi plug-in-RRDtool (round robin de baze de date), vă permite să le salvați pentru o lungă
perioadă de timp.
1.3. RRDtool (Round-robin Database).
Un alt soft care tot des este utilizat in monitorizarea rețelelor este RRDtool (Round-robin
Database) cu acest soft noi deja putem sa luam mai multe informații care sunt legate de server sau de
serviciile care sunt prestate. Unele grafice administrator sau cel care se ocupa de monitorizare poate
sa le creeze singur după plac si dorința. Pentru a crea unele grafice cu acest soft este nevoie de a ști
5
limbajele de programare Perl, Python, Ruby si PHP. Un exemplu al acestui sistem de monitorizare
puteți sa vedeți in fig. 1.3.1
Fig. 1.3.1
6
Cum funcţionează Sistemul de monitorizare RRDTool.
Astfel, avem în vedere logica rrdtool. Mai întâi vom crea un aşa-numita bază de date round-
robin (circulară sau inelară de bază), care poate înregistra citirea contorului. De ce round-robin - ca în
baza de date se conţin doar un anumit număr de celule de date, în caz contrar, numărul tot mai mare
de date de intrare este pur şi simplu prea plin cu un fişier de date inutile, cu informaţii învechite. Se
pune întrebarea - cum să facă un program, de exemplu, un an de muncă? Ei au ales o soluție foarte
buna - de a înregistra o singură celulă, de la mai mulți indicatorii, făcându-le o parte din funcţia
statistică. În fiecare bază de date round-robin, puteţi înregistra mai multe rânduri de celule, ţinând
cifrele de la o singură sursă, dar într-un mod diferit prin combinarea datelor primite. Ei bine
reprezentate trivial extragerea de date din baza de date pentru o anumită perioadă.
Controlul traficului.
Desigur, de control al traficului în prim-plan routere, switch-uri, servere la sarcina de
hardware (CPU, utilizarea hard disk, monitorizarea de plăci de reţea, de memorie liber, etc), sarcina
pe serviciile de reţea, cum ar fi HTTP, FTP, server proxy. Şi prima întrebare cu care ne confruntăm -
cum să colectam informaţii statistice. Soluţia cea mai buna este de a utiliza protocolul SNMP, dar
acest lucru nu este întotdeauna acceptabilă pentru unele scopuri, de exemplu, statisticile serverului
HTTP. Atunci venim la ajutorul de utilitaţi diferite, unde analizam jurnalul de imagini.
Desigur, este necesar să se ia în considerare faptul că valoarea informaţiilor statistice, în
monitorizare continuă, care este, dacă ne uităm la starea sistemului la momentul de faţă, ar fi greu de
înţeles, dacă ea se descurca cu sarcina, sau cu previziunile de creştere a încărcăturii şi de a
identifica, atunci când ceva va trebui înlocuit sau de modernizat. După ce a definit sursă de
informaţii, puteţi începe a scrie scenariul pentru rrdtool. Pentru a începe cu câteva informaţii despre
structura de scripturi. Iniţial cream două sau trei scenarii, dintre care unul este efectuat doar o singură
dată, crearea bazei de date round-robin folosind rrdtool. Apoi, ar trebui să o ruleze periodic, o
actualizare a script-ul bazelor de date round-robin (rrdb denumit în continuare "), care ia citirile de la
diferiți senzori şi le transmite rrdb folosind rrdtool-update, în plus, acest script pot fi inclus pentru a
genera graficele (graficul rrdtool). În unele cazuri, puteţi face generatoare pentru graficele din
scripturile CGI, atunci de fiecare dată când apelam un script CGI sunt generate grafice. A doua
opţiune este potrivită atunci când se utilizează mod_expire (Apache, vă permite să specificaţi
perioadele de învechire de date statice, cum ar fi imaginile) şi este foarte practic, deoarece
7
Diagramele sunt actualizate atunci când datele sunt solicitate, şi numai în cazul în care datele vechi
sunt învechite (avantajul rrdtool este mult mai mare in acest caz dacit la MRTG).
Când creaţi un script de actualizare rrdb trebuie remarcat faptul că acesta va fi numit foarte
des şi, când un număr mare de date colectate poate fina sistemul. Pentru limbajele, cum ar fi Perl si
Python sunt scrise biblioteci adecvate pentru accesul la rrdb, prin urmare, deseori este recomandat să
se folosească aceste. Dar in cazul nostru vom folosi limbajul de programare Shell.
1.4. Munin.
În viaţa fiecărui administrator de sistem, mai devreme sau mai târziu, vine un moment în care
ochii si mâinile nu sunt suficiente pentru a urmări toate serverele , unde apar unele probleme, dar
pentru a le soluţiona sa creat un sistem de monitorizare a sistemului. Pentru început credeam ca
RRDTool este mai bun si mai performant, şi aşa mai departe, cu toate facilităţile pe care le avea el. În
final am descoperit ca el folosea de fapt doar 10% din capacitatea si necesitatea sistemului de
monitorizare. Totul sa schimbat când am testat Munin - soluția perfecta pentru monitorizarea
rețelelor mici.
Sistemul este alcătuit din două părţi independente: un server (în sine Munin), instalat pe o
maşină, care va colecta toate datele, precum şi un mic Munin daemon-nod, care este instalat pe
maşinile pe care le monitorizează. Acest daemon este un mic Perl Script, care ascultă portul 4949 cu
ajutorul Net:: Server. Unde acesta scanează plug-in-uri instalate în / etc / Munin / plugin-uri şi îşi
aduce aminte numele lor. Fiecare server Munin in 5 minute se conectează la toate nodurile, şi
primeşte informaţii de la toate plugin-uri şi menţine o bază de date de tip rrdtool. Astfel, pentru
salvarea statisticilor nu avem nevoie de o baza de date in MySQL.
Pugin-urile
Cel mai bun lucru in Munin sunt Plugin-urile. Simplitatea incredibila de punere în aplicare vă
permite să scrii plug-in-uri pentru tot ce vrei in cel mai Putin timp petrecut cu documentarea
sistemului. Poate că acest lucru explică faptul că un sistem relativ tânără a crescut într-un număr
mare de-a gata numai cu plug-in-uri.
De fapt, fiecare plugin este un sistem de fișier executabile care producţia lor oferă valorile
curente ale parametrilor.
Cel mai simplu mod pentru a analiza este un exemplu foarte simplu.
Pentru a monitoriza o reţea cu place foarte mare, o primești atunci când întreaga "viaţă" a reţelei
permanent poți sa vezi grafice clare, care să-ti permită să evaluezi rapid situaţia. Clienții conectați la
PPTP (Prin VPN ), astfel încât numărul de interfeţe existente corespunde exact cu numărul de
8
abonaţi online. Si unde sistemele noastre ca MRTG sau RRDTool lucrează direct cu plachetele de
rețea in cazul unde avem mai multe plachete de rețea aceste sisteme de obicei dau multe erori.
O alta descoperire plăcuta pentru mine a fost existenţa Munin-nod-win, care vă permite să
monitorizați şi servere bazate pe Windows.
După cum am observat Munin deja este un mic sistem de monitorizare care arata prin grafice datele
care sunt colectate din 5 in 5 minute dar la toate aceste date mai are si opțiunea sa anunțe daca careva
din serviciile care sunt monitorizate au probleme sau posibil sa apăra probleme. Acest soft are o
interfața grafica web care este ușor de utilizat si este destul de înţelegătoare pentru cei care au grija
de monitorizarea retelei. Acest soft poate monitoriza mult mai multe date ca softurile precedente. El
are posibilitate sa monitorizeze tot ce e legat de componentele serverului ca processor, memorie
operativa, hard discul si altele. Dar la baza monitorizării sunt serviciile pe care le oferă serverul. De
exemplu bazele de date care sunt create, procesele care sunt la moment active, traficul care a fost
utilizat, si multe altele. Exemplu al acestui soft in fig. 1.4.1 si fig. 1.4.2.
Fig. 1.4.1
9
Fig 1.4.2
1.5. Nagios
Nagios este un sistem liber de monitorizare a sistemelor informatice şi reţelelor de
calculatoare. Sistem de monitorizare ale nodurilor sau serviciilor de rețea si în cazul în care apar
probleme (de exemplu, serviciul nu răspunde) notifica administratorul. Monitorizarea continuă a
tuturor componentelor va dezvăluie zonele cu probleme şi le rezolvaţi înainte de eşec, care pot afecta
performanţa reţelei. Nagios monitorizează activitatea serviciilor de reţea: SMTP, POP3, IMAP, SSH,
Telnet, FTP, HTTP, DNS, si multe altele. De asemenea, el poate fi folosit pentru a urmări utilizarea
resurselor de pe server: încărcarea procesorului, consumul de memorie, spaţiu pe disc, etc - Şi nu
numai în Unix, dar şi în alte sisteme de operare. De exemplu, monitorizarea de servere care rulează
Windows cu modulul NRPE_NT.
Este creat pentru monitorizare de la distanta pe un sistem criptat SSH sau SSL tuneluri.
Arhitectura simpla de expansiune poate crea propriile lor căi de servicii de testare şi manipulanţii
eveniment (de exemplu, a reporni un serviciu de rețea). Conceptul de "mamă" nod permite să
definească ierarhia şi relaţiile dintre gazde. Nagios este apreciat pentru abilitatea de a construi hărţi
ale infrastructurii de reţea şi grafice a parametrilor diferitelor sisteme care sunt observate.
Proiectul are originea încă din 2002, deşi la început el a fost cunoscut sub numele de
10
NetSaint. Liderul ei este dezvoltatorul Ethan Galstad. Funcţionalitate extinsă de plugin-uri şi addons,
dintre care majoritatea sunt disponibile pe pagina de încărcare. http://www.nagios.org
Am testat cele două ramuri ale produsului: 2.x şi 3.x. Unde in 3.x, este corectat doar de bug-
uri găsite anterior, adăugate noi macro-uri şi mult mai multe algoritme de scanare, pentru a elimina
unul dintre principalele dezavantaje ale acestui sistem - lent în verificarea reţele de mari dimensiuni.
În 2.x toate testele sunt aproape constante, dar în noua ediţie a sarcinilor sunt executate în paralel.
Deşi a doua versiune este încă în evoluţie, este clar că, în viitor, toate eforturile vor fi aruncate pe al
treilea.
Proprietăţi ale sistemului de monitorizare Nagios.
Instalare vom face pe sistemul de operare CentOS. În alte distribuţii, procesul este complet
similare, cu excepţia pentru faza iniţială - instalarea dependenţelor.
$ Sudo yum search Nagios
- Va da un număr de pachete. Această listă conţine ambele versiuni ale Nagios.
Dacă nu aţi instalat un compilator şi alte instrumente necesare, atunci punem meta pachetului build-
essential. Pentru a vizualiza statistici ale Nagios, avem nevoie de un server web şi un GD2 biblioteca
grafică (avem nevoie de ea pentru imagini dinamice):
$ Sudo yum install apache libgd2-XPM-dev
$ Sudo yum install build-essential
Înainte de a compila Nagios ar trebui să cream un utilizator special şi o grupa cu numele căruia va
funcţiona. Dacă nu, Nagios nu va putea colecta datele necesare.
$ Sudo useradd-m Nagios
$ Sudo passwd Nagios
În unele distribuţii creează automat un user si o grupa cu acelaşi nume. Verificaţi dacă acest lucru
este:
Nagios Grep $ / etc / group
Nagios: x: 1001:
11
În cazul în care distributivul nu a arătat,vom adauga manual:
Nagios $ sudo Nagios usermod-G
Cu comanda nagcmd necesara pentru gestionarea configuraţiei printr-o interfața Web. Acesta trebuie
să includă în contul serverului web (în CentOS - www-date) şi utilizatorul Nagios:
$ Sudo groupadd nagcmd
$ Sudo usermod-G nagcmd Nagios
$ Grep-i utilizator / etc/apache2/envvars
APACHE_RUN_USER de export = www-date
$ Sudo usermod-G nagcmd www-date
Acum vom merge la pagina www.nagios.org / descărcam ultimele versiuni de Nagios şi plugin-uri.
În plus faţă de versiunile stabile, puteţi descărca cele mai recente CVS tăiat, dar acest lucru ar fi mai
bine sa-l fac cei care au mai multa experiența. Plugin-uri pot fi descărcate de la un nagiosplugins.org
site-ul web. De asemenea, este disponibil şi un link către o pagină cu addons (www.nagios.org /
download / addons). Acestea nu sunt necesare pentru ale instala, dar sunt necesare numai atunci
când cream unele servicii de rețea manual. După extragere obţinem fişierele şi le configuram in felul
următor:
$ Tar xzf Nagios-3.0.3.tar.gz
$ Cd Nagios-3.0.3
$. / Configure - cu-comanda-grup = nagcmd
După procedura de instalare si configurare. Asiguraţi-vă că toate rezultatele necesare şi parametrii
sunt corecte:
Opţiuni generale:
-------------------------
...
Nagios executabil: Nagios
Nagios utilizator / grup: Nagios, Nagios
Comandamentul de utilizator / grup: Nagios, nagcmd
...
Interfaţă web Opţiuni:
------------------------
URL-ul HTML: http://localhost/nagios/
12
CGI URL: http://localhost/nagios/cgi-bin/
Acum, compilaţi:
$ ./configure
După asamblare va fi data o listă de comenzi pentru a instala diverse componente ale sistemului de
monitorizare Nagios.
$ Sudo make install
$ Sudo make install-init
$ Sudo make install-config
$ Sudo make install-commandmode
$ Sudo make install-webconf
După executarea acestor comenzi în directorul / usr / local / nagios / etc / vor fi copiate fişierele de
configurare cu extensia (cgi.cfg resource.cfg nagios.cfg). Apoi este necesar de a configura serverul
web / etc/apache2/conf.d/nagios.conf, care este necesare pentru lucrul sistemului de monitorizare.
Pentru ca sa putem sa înregistram prin intermediul interfeţei web, cu htpasswd cream userul
nagiosadmin :
$ Sudo htpasswd-c / usr / local / nagios / etc / htpasswd.users nagiosadmin
Reporniţi Apache cu comanda:
$ Sudo / etc/init.d/httpd restart
După instalare in directorul / etc / init.d / vor fi plasate scripturile pentru rularare Nagios-ului.
Ln $ sudo-s / etc / init.d / Nagios / etc/rcS.d/S99nagios
Instalarea plugin-uri este obligatorie.
$ Tar xzf nagios-plugins-1.4.12.tar.gz
$ Cd-Nagios plugin-1.4.12
13
Există şi alte opţiuni de configurare.:
$. / Configure - cu-Nagios-user = Nagios - cu-Nagios-grup = Nagios
$ Sudo make install
Dup ace am terminat suntem gata sa lansam sistemul de monitorizare. Fişierele de configurare sunt
deja configurate pentru a monitoriza sistemul local. Vom Verifica configuraţiile:
$ Sudo / usr / local / nagios / bin / nagios-v / usr / local / nagios / etc /
nagios.cfg
Avertismente: 0
Erori Total: 0
Lucrurile arata bine - probleme grave nu au fost identificate în timpul controlului.
Acum vom porni sistemul Nagios sudo «comanda / etc / init.d / nagios start». O anumită
perioadă de timp va fi cheltuita pentru colectarea datelor din rețeaua pe care o administram. Pentru a
le vizualiza, folosim un browser web unde mergem la adresa care a fost determinata în timpul
instalării - http://localhost/nagios. Introduceţi un nume de utilizator şi parola nagiosadmin. Ca in fig
1.5.1
Fig 1.5.1.
Configuraţia de bază conţine un număr mare de directive care daemon-ul le citeşte la pornire,ele se
găsesc in nagios.cfg. Acest fișier este menţionat de două tipuri de fişiere. În fişierul de resurse
conţine macro-urile personalizate, inclusiv parolele de acces la obiecte. Această informaţie este în
mod special plasata separat, așa ca nu este posibila să le accesaţi de pe web. Din motive de
securitate, astfel de fişiere sunt instalate cu dreptul de 600 sau 660.
Utilizarea directivelor în nagios.cfg, ne permite adăugarea a orice număr de servicii si
14
obiecte. Obiecte, adică toate elementele implicate în sistemul de monitorizare (noduri, servicii,
persoane de contact, echipe, etc.), ele toate se afla intr-un fișier cu numele Objects.. Odată instalat
în / usr / local / nagios / etc / objects in el vor fi create subdirectorii cu exemple de configurări in
diferite fișiere. În acest subdirectoriu sunt obiecte si template-uri pentru marea majoritate a cazurilor
de configurare standartă. Ca de exemplu ca şablon ale setărilor le putem găsi si in windows.cfg.
Unde sunt setări pentru a ne conecta si a lua datele de pe un server cu sistem de operare windows.
cfg_file = / usr / local / nagios / etc / obiecte / windows.cfg
Mai jos vom deschide acest fișier si vom arata si lamuri conținutul
lui.
$ Sudo nano / usr / local / nagios / etc / obiecte / windows.cfg
Descriere # de nod (adresa IP, numele)
define gazdă (
, Moştenire de valori implicite din şablon
utiliza Windows-server
host_name server01
alias Windows Server
adresa 192.168.1.20
)
Descriere # serviciilor controlate
define serviciului (
utilizarea de servicii generice
host_name server01
service_description NSClient + + Version
# Comandă pentru a verifica
check_nt check_command! CLIENTVERSION
)
# CPU control
define serviciului (
utilizarea de servicii generice
host_name server01
service_description încărcarea procesorului
check_command check_nt! CPULOAD!-l 5,80,90
)
# Consumul de memorie,
define serviciului (
15
utilizarea de servicii generice
host_name server01
service_description Memorie Usage
check_command check_nt! MEMUSE! W-80-C 90
)
# Pentru a adăuga controlul serviciului specifice (cum ar fi Explorer), utilizaţi
această structură:
define serviciului (
utilizarea de servicii generice
host_name server01
service_description Explorer
check_nt check_command PROCSTATE!-d SHOWALL Explorer.exe-l!
)
Pentru citirea datelor de pe serverul Windows trebuie să instalam software-ul client NSClient + +.
Unde îl putem găsi pe pagina www. sf.net / proiecte / nscplus pentru al descărca pot fi in arhiva zip
sau fişier de instalare. Vă rugăm să reţineţi că, pentru sisteme de 32 - şi 64-biţi sunt fişiere diferite.
Instalarea standard MSI-dosar - în cazul de arhiva zip pentru a extrage, apoi modificaţi în acel
director, si tastaţi în terminal două comenzi:
> Nsclient + + / install
> + + Nsclient systray
Apoi, în Consola de Servicii va fi un nou serviciu. Apel fereastra de Proprietăţi, la rândul său, tab-ul
"Login" si un pluton de la cutie "permite interacţiunea cu desktop". Lansarea se poate prin tastarea
in terminal:
> Nsclient + + / Start
Înainte de a începe să modificaţi setările în fişierul de configurare NSC.ini, care se află în
subdirectorul în care aţi instalat NSClient + +. Sunt multe comentarii care previn si va ajuta ca sa-l
configurați cit mai ușor si rapid.
Dosar NSC.ini
[Module]
#Sunt modulele cu care el lucrează
FileLogger.dll
16
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
SysTray.dll
CheckEventLog.dll
CheckHelpers.dll
CheckWMI.dll
Setări []
# Parola de acces
password = parola secrete
# Nod sau noduri care sunt permise să se conecteze
allowed_hosts = 192.168.1.100
[] NSClient
# Portul pe care să lucreze NSClientListener.dll
port = 12489
Pentru mai multe comenzi ajutătoare de care aveți nevoie la monitorizare sau care deloc nu sunt le
puteți adăuga in fișierul commands.cfg
sg_file = / USR / local / nagios / etc / obiecte / commands.cfg
Pentru a citi datele şi a le transfera la server folosim check_nt plug-in, incluse în comenzile standarde
ale Nagios si se afla in commands.cfg.
Cum arata fișierul commands.cfg
$ Sudo nano / usr / local / nagios / etc / obiecte / commands.cfg
define comanda (
command_name check_nt
command_line user1 $ $ / check_nt-H $ $ HOSTADDRESS p-12489 \
S-secret_password-v ARG1 $ $ $ $ Arg2
)
După configurarea lui trebi sa adăugați serverul in fișierul de configurare al nagios.cfg şi să reporniți
sistemul de monitorizare.
$ Sudo / usr / local / nagios / bin / nagios-v / usr / local / nagios /
etc / nagios.cfg
17
$ Sudo / etc / init.d / Nagios reload
Acum, programul va colecta informaţii, apoi datele vor fi disponibile prin intermediul interfeţei web.
După cum sa menţionat deja, Nagios nu poate colecta doar statistici, dar, de asemenea, să
notifice atunci când apar probleme. Si sistemul de notificare al acestui sistem este foarte bun unde
noi putem sa trimitem notificările pe email, pe mobil in forma de sms, sau pe un pager. Totul este
creat pentru a informa cit mai rapid administratorul. Pentru a configura aceste opțiuni avem nevoie
de fișierul contacts.cfg
$ Sudo nano / usr / local / nagios / etc / obiecte / contacts.cfg
define de contact (
CONTACT_NAME nagiosadmin
alias Nagios Admin
# Perioada de alertă
24x7 service_notification_period
24x7 host_notification_period
Parametrii # ca: u = facilitate necunoscute, de avertizare w = (avertizare), c =
critice (critică), r = recuperări (restaurat), f = start / stop, n = none (alerte
nu fi de acord)
service_notification_options W, U, C, R
host_notification_options d, u, r
# Tip de alertă commands.cfg
service_notification_commands notifice-cu-mail, să notifice-cu-epager
host_notification_commands-gazdă notifică-cu-e-mail, gazdă-notifice-cu-epager
Adresele #
e-mail [email protected]
pager [email protected]
Adresa1 [email protected]
)
Exemplu al acestui fisier se poate de vazut in fig 1.5.2
18
Fig 1.5.2
Puteți defini la care utilizatorii si in ce mod va fi trimis notificarea a anumitor tipuri de servere sau
servicii. Noi folosim grupurile de contacte (contactgroups.cfg). Nu uitaţi să verificaţi că fişierul daca
fost conectat la nagios.cfg. După cum ne dam seama acest sistem nu este creat pentru a monitoriza un
calculator sau doua dar el este creat pentru a monitoriza o rețea întreaga unde avem multe servii si
multe servere care oferă aceste servicii. Acest sistem este unul din cel mai răspândit soft utilizat
pentru monitorizare . El este utilizat de fote multe companii in care exista rețele. Nagios este un
sistem întreg de monitorizare care permite monitorizarea a fiecărui serviciu care poate fi oferit sau
utilizat in rețea. Nagios are si un sistem foarte bun care anunța apariția a diferitor probleme in rețea.
Exemplu in fig. 1.5.3. si 1.5.4.
19
Fig 1.5.3.
20
Fig 1.5.4.
Toate aceste softuri care sunt utilizate pentru monitorizare pot sa lucreze pe diferite sisteme de
operare.
Serviciile care sunt oferite de acest soft.
Monitorizarea serviciilor de reţea (SMTP, POP3, HTTP, NNTP, ICMP, SNMP)
Monitorizarea resurselor gazdă (sarcina procesorului, utilizarea disc, serviciilor oferite).
Este utilizat in cele mai multe sisteme de operare de reţea, Microsoft Windows, chiar si cu
modul NRPE_NT
Suport pentru monitorizarea de la distanţă prin intermediul tunelurilor criptate SSH sau SSL
Uşor de utilizat pe baza de modul de arhitectura (plugin-uri) să permită, folosirea orice
limbaj de programare, la alegerea (Shell, C + +, Perl, Python, PHP, C # şi altele) pentru a
dezvolta cu uşurinţă propriile lor căi de verificare a serviciilor
Servicii de testare simultană
Capacitatea de a defini gazdă ierarhia reţea utilizând "mamă" gazde, poate detecta şi
distincţia între gazde care nu mai sunt de ordine, precum şi cele care nu sunt disponibile
21
Trimite alerte atunci când apar probleme cu serviciul sau gazdă (prin e-mail, pager, SMS, sau
în orice alt mod stabilit de către utilizator prin intermediul sistemului de modul)
Capacitatea de a defini evenimentele care au avut loc cu serviciile sau gazdele, pentru a
rezolva problemele în mod proactive.
Rotaţie automată la fişierele de jurnal.
Abilitatea de a organiza munca în comun a mai multor sisteme de monitorizare pentru
îmbunătăţirea fiabilităţii şi de a crea un sistem de monitorizare distribuit.
Include nagiostats de utilitate, care afişează rezumatul global, pentru toate gazdele, care sunt
monitorizate.
Multe servicii se pot observa in fig. 1.5.5.
Fig. 1.5.5.
22
Cum funcționează Nagios .
a. Monitorizarea
Personalului IT configura Nagios pentru a monitoriza IT critice componentele sale infrastructurii,
inclusiv măsurătorile de sistem, protocoale de reţea, aplicaţii, servicii, servere si infrastructura de
rețea.
b. Alertare
Nagios trimite alerte atunci când componentele critice apar, oferind administratorilor cu un preaviz
de evenimente importante. Alertele pot fi livrate prin e-mail, SMS sau script-ul personalizat.
c. Răspuns
Personalul IT poate confirma alertele şi poată începe a investiga imediat. Alerta poate fi crescută la
diferite tipuri de alerte în cazul în care nu sunt recunoscute.
d. Raportarea
Rapoartele oferă o înregistrare istorică, evenimente, notificări, şi răspunsul de alertă pentru revedea
mai târziu.
e. Întreţinere
Previne alerte de downtime programate în cursul întreţinerii programate şi de upgrade Windows.
d. Planificare
Trending and capacity planning graphs and reports allow you to identify necessary infrastructure
upgrades before failures occur. Trending şi planificarea capacităţii grafice şi rapoarte vă permit să
identificați si sa îmbunataţiţi infrastructura necesară înainte de a apărea defecţiuni.
23
Schema de lucru a sistemului de monitorizare Nagios.
24
Capitolul II. Implementarea unui sistem de monitorizare
2.1. Implementarea sistemului de monitorizare pentru organizaţia NicrutNet
S.R.L.
Pentru organizaţia NicrutNet SRL a fost creat şi implementat un sistem de monitorizare care
monitorizează toate reţelele şi serverele care sunt administrate de această organizaţie. Scopul de bază
a fost ca sa cream un sistem de monitorizare care sa ne dea de ştire cit mai rapid când apar probleme
cu reţeaua sau cu serviciile care sunt monitorizate. Dar ca să avem un asemenea sistem a fost nevoie
de testat mai multe sisteme de monitorizare a reţelelor. Mai jos sunt descrise procesele de instalare si
configurare a sistemelor care au fost testate si implementate la această organizaţie.
2.2 Configurarea MRTG.
Configurarea MRTG poate provoca dificultăţi la început, aşa că înainte de a începe,
asiguraţi-vă că aţi înţeles sintaxa de configurare MRTG a pachetului de fişiere. Fişierul de
configurare conţine informaţiile necesare pentru acest program la pentru un dispozitiv special, şi
pentru interfeţele sale. Acest fişier conţine, de asemenea, comunitatea socket, necesare pentru a
accesa agentul SNMP pe dispozitivele observate, şi, în plus, în cazul în care stabileşte şi modul în
care a creat pagini HTML. Cele mai importante părţi a fişierului de configurare este conform cu
obiectivul de cuvinte cheie, descrierea şi WorkDir. Opţiuni pe linia de obiectivul stabilit adresa IP,
port, OID şi comunitatea socket SNMP pentru dispozitivul care va fi monitorizat.
Puteţi crea un fişier de configurare simplă, cu un minim de parametri, folosind pachetul
cfgmaker script-ul MRTG. Acest script controlează variabila SNMP MIB, şi generează un fișier cu
configurarea dispozitivelor găsite pe calculator. Aveţi posibilitatea să editaţi manual acest fişier dacă
aveţi nevoie pentru a schimba sau adăuga orice opţiuni, cum ar fi numele raportului, valoarea de
ieşire sau identificator OID a dispozitivului de ţintă., cfgmaker Scenariul, la fel ca toate pachetele
incluse în pachetul MRTG cu fişiere executabile, o puteți porni din linia de comandă. Acest lucru nu
va cauza probleme daca folosiți Linux sau Unix, dar poate fi dificil pentru cei care au numai
experienţă de lucru doar cu Windows.
25
Instalarea MRTG.
Pentru a utiliza MRTG el necesită următoarele biblioteci:
* gd - graph drawing library , biblioteca responsabil pentru
formarea graficei.
* Libpng - este necesara pentru a crea grafică în png
* Zlib - această bibliotecă este folosită de comprimare a creat grafică
Toate aceste biblioteci le putem instala foarte uşor cu comanda rpm –ivh
gd-1.8.4-4.rpm
libpng-1.0.12-2.rpm
zlib-1.1.4-8.rpm
Copiem pachetul de instalare a sistemului de monitorizare MRTG de pe site-ul proiectului
http://people.ee.ethz.ch/ oetiker ~ / webtools / MRTG /. Şi îl descărcam la noi pe calculator.
Titlul [eth0]: Trafic eth0 # numele paginii generat
MaxBytes [eth0]: # 125000 atunci când primeşte o valoare mai mare decât cea
specificată, valoarea este ignorat pentru programul de
construcţie
AbsMax [eth0]: # 125000 atunci când primeşte o valoare mai mare decât cea
specificată, valoarea nu ia în considerare
Opţiuni [eth0]: gabaritului # înseamnă opţiune care ia valoarea curentului de
intrare
Target [eth0]: `/ usr / sbin / cban-i eth0-m" # date unde
Pagetop [eth0]: # eth0 statisticile antet generat pagina
YLegend [eth0]: Bytes / s # semnătura la valoarea Graficul axa Y
ShortLegend [eth0]: B / s # unitate de măsură. adăugat la maxim,
# Actuale, iar valoarea medie
Legend1 [eth0] traficul de intrare semnătura # pentru traficul de intrare
Legend2 [eth0]: Outgoing Trafic semnătura # pentru trafic de ieşire
Legend3 [eth0]: Maxim punctul de a sosi Trafic semnătura # pentru traficul de
intrare maximă
Legend4 [eth0]: maximă de ieşire de trafic # semnătura pentru outbound maximă
Trafic
LegendI [eth0]: În: # o legendă de scurtă durată pentru date digitale
(primite)
LegendO [eth0]: out: # o legendă de scurtă durată pentru date digitale (de
ieşire)
WithPeak [eth0]: ymwd # grafice pentru a construi y ani, m-luni, w săptămâni,
26
D-Day
În plus, trebuie să specificaţi directorul unde veţi adăuga rezultatele lucra în formă de HTML
Fig.2.2.1 - pagini cu grafica:
WorkDir: / Var / www / html / MRTG
După ce am terminat cu un fişier de configurare, încercam să executăm fişierul executabil /
usr / bin / MRTG
# / Usr / bin / MRTG / etc / MRTG / mrtg.cfg - de logare / var / log / mrtg.log
Apoi configuram ca la fiecare 5 minute sa colecteze datele.
# crontab-e
Şi adăugam rândul dat in fereastra care sa deschis.
*/ 5 * * * * / usr / bin / MRTG / etc / MRTG / mrtg.cfg - de logare / var / log /
mrtg.log
Fig.2.2.1.
27
Instalarea rutei în MRTG .
Trebuie să ştii cum să instalaţi ruta fişierului de configurare. După încărcarea pachetului
MRTG din internet el este despachetat pe disc într-un director numit ca MRTG-2.9.25. Faceți o
favoare şi redenumiţi directorul uşor, de exemplu, "MRTG", pentru a evita greşeli atunci când veți
intra in el din consola.
Când rulaţi crearea scripturilor cu cfgmaker, este posibil să apară probleme dacă aţi instalat o
cale greşită. Deoarece MRTG este scris în Perl, are nevoie de un interpret, cum ar fi ActivePerl.
Acest lucru înseamnă că, atunci când rulaţi MRTG sau cfgmaker, executarea acestor comenzi începe
cu lansarea Perl fişier executabil. Prin urmare, spre cale lor ar trebui să fie incluse si o variabila de
mediu al sistemului de operare (ActivePerl face acest lucru în mod automat). Dacă nu ştiţi cum să
specificaţi calea, mai fiabil va fi de rulat iniţial din directorul MRTG bin/ MRTG \, care, în mod
implicit sunt fişiere executabile. Pentru a plasa fişiere de configurare într-un directoriu, trebuie să
specificaţi calea către acesta.
Dacă doriţi să MRTG script să ruleze automat, pentru a crea un şort-l în folderul Startup sau de a
folosi un demon. Cu RunAsService utilitate de Microsoft sau de produse gratuite, cum ar fi
FireDaemon sau MRTG Updater Statistică, daemon poate funcţiona într-un mediu Windows ca un
serviciu fără înregistrare în sistem.
Deci, MRTG este un mecanism simplu si ieftin de a monitoriza mai multe interfeţe de rețea.
Programul poate monitoriza cu uşurinţă porturile routerelor şi switch-urilor la multe companii.
Odată cu creşterea numărului de porturi de monitorizat, cu atâta creste complexitatea MRTG.
Mai multe porturi, necesita un calculator mai puternic, pe care va trebui să le monitorizeze.
Cea mai mare necesitate de la performantele calculatorul sunt atunci când sistemul de monitorizare
MRTG colectează informaţii cu privire la toate porturile si elaboreze o imagine unificata a
performanţei reţelei. Fig. 2.2.2.
Fig. 2.2.2.
28
2.3. Instalarea sistemului de monitorizare RRDTool.
Instalarea nu ar trebui să cauzeze probleme: alege versiunea corectă a sistemului de operare
FreeBSD sau Linux. Rrdtool include, de asemenea, mai multe biblioteci terţe părţi cum ar fi libgd
(pentru a genera grafice), libpng (pentru a genera imagini PNG), şi zlib (compresie pentru imagini).
probleme de instalare nu contează, trebuie doar să se precizeze argumentele pentru a configura -
enable-shared. Da pentru a crea o bibliotecă rrdtool comuna pentru utilizarea în continuare de către
alte programe.
Vom instala sistemul de monitorizare RRDTool pe sistemul de operare CentOS.
Pasul 1.
Instalăm bibliotecile de care are nevoie acest sistem.
# yum install cairo-devel libxml2-devel pango-devel pango libpng-devel freetype freetype-devel libart_lgpl-devel
Va trebui să obţinem acest rezultat.
Loading "rhnplugin" pluginLoading "security" pluginrhel-x86_64-server-vt-5 100% |=========================| 1.4 kB 00:00rhn-tools-rhel-x86_64-ser 100% |=========================| 1.2 kB 00:00rhel-x86_64-server-5 100% |=========================| 1.4 kB 00:00Setting up Install ProcessParsing package install argumentsPackage libxml2-devel - 2.6.26-2.1.2.1.x86_64 is already installed.Package libxml2-devel - 2.6.26-2.1.2.1.i386 is already installed.Package pango - 1.14.9-3.el5.i386 is already installed.Package pango - 1.14.9-3.el5.x86_64 is already installed.Package freetype - 2.2.1-20.el5_2.i386 is already installed.Package freetype - 2.2.1-20.el5_2.x86_64 is already installed.Resolving Dependencies--> Running transaction check---> Package libart_lgpl-devel.x86_64 0:2.3.17-4 set to be updated---> Package pango-devel.i386 0:1.14.9-3.el5 set to be updated--> Processing Dependency: libXft-devel for package: pango-devel--> Processing Dependency: libXrender-devel for package: pango-devel--> Processing Dependency: libXext-devel for package: pango-devel--> Processing Dependency: libX11-devel for package: pango-devel--> Processing Dependency: fontconfig-devel >= 2.0 for package: pango-devel---> Package pango-devel.x86_64 0:1.14.9-3.el5 set to be updated---> Package freetype-devel.x86_64 0:2.2.1-20.el5_2 set to be updated---> Package libpng-devel.i386 2:1.2.10-7.1.el5_0.1 set to be updated---> Package cairo-devel.x86_64 0:1.2.4-5.el5 set to be updated---> Package libpng-devel.x86_64 2:1.2.10-7.1.el5_0.1 set to be updated---> Package cairo-devel.i386 0:1.2.4-5.el5 set to be updated---> Package libart_lgpl-devel.i386 0:2.3.17-4 set to be updated--> Processing Dependency: libart_lgpl_2.so.2 for package: libart_lgpl-devel---> Package freetype-devel.i386 0:2.2.1-20.el5_2 set to be updated--> Running transaction check---> Package libXrender-devel.i386 0:0.9.1-3.1 set to be updated--> Processing Dependency: xorg-x11-proto-devel for package: libXrender-devel
29
---> Package libXft-devel.i386 0:2.1.10-1.1 set to be updated---> Package libX11-devel.i386 0:1.0.3-9.el5 set to be updated--> Processing Dependency: libXdmcp-devel for package: libX11-devel--> Processing Dependency: libXau-devel for package: libX11-devel---> Package fontconfig-devel.i386 0:2.4.1-7.el5 set to be updated---> Package libart_lgpl.i386 0:2.3.17-4 set to be updated---> Package libXext-devel.i386 0:1.0.1-2.1 set to be updated--> Running transaction check---> Package xorg-x11-proto-devel.i386 0:7.1-9.fc6 set to be updated--> Processing Dependency: mesa-libGL-devel for package: xorg-x11-proto-devel---> Package libXdmcp-devel.i386 0:1.0.1-2.1 set to be updated---> Package libXau-devel.i386 0:1.0.1-3.1 set to be updated--> Running transaction check---> Package mesa-libGL-devel.i386 0:6.5.1-7.5.el5 set to be updated--> Finished Dependency ResolutionDependencies Resolved============================================================================= Package Arch Version Repository Size=============================================================================Installing: libart_lgpl-devel x86_64 2.3.17-4 rhel-x86_64-server-5 21 k libart_lgpl-devel i386 2.3.17-4 rhel-x86_64-server-5 21 k pango-devel i386 1.14.9-3.el5 rhel-x86_64-server-5 280 k pango-devel x86_64 1.14.9-3.el5 rhel-x86_64-server-5 281 kInstalling for dependencies: cairo-devel x86_64 1.2.4-5.el5 rhel-x86_64-server-5 131 k cairo-devel i386 1.2.4-5.el5 rhel-x86_64-server-5 130 k fontconfig-devel i386 2.4.1-7.el5 rhel-x86_64-server-5 168 k freetype-devel x86_64 2.2.1-20.el5_2 rhel-x86_64-server-5 151 k freetype-devel i386 2.2.1-20.el5_2 rhel-x86_64-server-5 151 k libX11-devel i386 1.0.3-9.el5 rhel-x86_64-server-5 665 k libXau-devel i386 1.0.1-3.1 rhel-x86_64-server-5 11 k libXdmcp-devel i386 1.0.1-2.1 rhel-x86_64-server-5 7.6 k libXext-devel i386 1.0.1-2.1 rhel-x86_64-server-5 57 k libXft-devel i386 2.1.10-1.1 rhel-x86_64-server-5 16 k libXrender-devel i386 0.9.1-3.1 rhel-x86_64-server-5 8.9 k libart_lgpl i386 2.3.17-4 rhel-x86_64-server-5 76 k libpng-devel i386 2:1.2.10-7.1.el5_0.1 rhel-x86_64-server-5 182 k libpng-devel x86_64 2:1.2.10-7.1.el5_0.1 rhel-x86_64-server-5 186 k mesa-libGL-devel i386 6.5.1-7.5.el5 rhel-x86_64-server-5 465 k xorg-x11-proto-devel i386 7.1-9.fc6 rhel-x86_64-server-5 247 kTransaction Summary=============================================================================Install 20 Package(s)Update 0 Package(s)Remove 0 Package(s) Total download size: 3.2 MIs this ok [y/N]: Downloading Packages:(1/20): libXext-devel-1.0 100% |=========================| 57 kB 00:00(2/20): freetype-devel-2. 100% |=========================| 151 kB 00:00(3/20): libXau-devel-1.0. 100% |=========================| 11 kB 00:00(4/20): libart_lgpl-devel 100% |=========================| 21 kB 00:00(5/20): libart_lgpl-2.3.1 100% |=========================| 76 kB 00:00(6/20): cairo-devel-1.2.4 100% |=========================| 130 kB 00:00(7/20): libpng-devel-1.2. 100% |=========================| 186 kB 00:00(8/20): cairo-devel-1.2.4 100% |=========================| 131 kB 00:00(9/20): fontconfig-devel- 100% |=========================| 168 kB 00:00(10/20): mesa-libGL-devel 100% |=========================| 465 kB 00:01(11/20): libXdmcp-devel-1 100% |=========================| 7.6 kB 00:00(12/20): libpng-devel-1.2 100% |=========================| 182 kB 00:00(13/20): libX11-devel-1.0 100% |=========================| 665 kB 00:02(14/20): freetype-devel-2 100% |=========================| 151 kB 00:00(15/20): libXft-devel-2.1 100% |=========================| 16 kB 00:00(16/20): pango-devel-1.14 100% |=========================| 281 kB 00:01
30
(17/20): pango-devel-1.14 100% |=========================| 280 kB 00:01(18/20): libXrender-devel 100% |=========================| 8.9 kB 00:00(19/20): libart_lgpl-deve 100% |=========================| 21 kB 00:00(20/20): xorg-x11-proto-d 100% |=========================| 247 kB 00:01Running rpm_check_debugRunning Transaction TestFinished Transaction TestTransaction Test SucceededRunning Transaction Installing: libart_lgpl ####################### [ 1/20] Installing: freetype-devel ####################### [ 2/20] Installing: fontconfig-devel ####################### [ 3/20] Installing: libpng-devel ####################### [ 4/20] Installing: libXau-devel ####################### [ 5/20] Installing: libart_lgpl-devel ####################### [ 6/20] Installing: libart_lgpl-devel ####################### [ 7/20] Installing: libpng-devel ####################### [ 8/20] Installing: freetype-devel ####################### [ 9/20] Installing: xorg-x11-proto-devel ####################### [10/20] Installing: libX11-devel ####################### [11/20] Installing: libXrender-devel ####################### [12/20] Installing: libXft-devel ####################### [13/20] Installing: cairo-devel ####################### [14/20] Installing: libXext-devel ####################### [15/20] Installing: pango-devel ####################### [16/20] Installing: pango-devel ####################### [17/20] Installing: libXdmcp-devel ####################### [18/20] Installing: mesa-libGL-devel ####################### [19/20] Installing: cairo-devel ####################### [20/20] Installed: libart_lgpl-devel.x86_64 0:2.3.17-4 libart_lgpl-devel.i386 0:2.3.17-4 pango-devel.i386 0:1.14.9-3.el5 pango-devel.x86_64 0:1.14.9-3.el5Dependency Installed: cairo-devel.x86_64 0:1.2.4-5.el5 cairo-devel.i386 0:1.2.4-5.el5 fontconfig-devel.i386 0:2.4.1-7.el5 freetype-devel.x86_64 0:2.2.1-20.el5_2 freetype-devel.i386 0:2.2.1-20.el5_2 libX11-devel.i386 0:1.0.3-9.el5 libXau-devel.i386 0:1.0.1-3.1 libXdmcp-devel.i386 0:1.0.1-2.1 libXext-devel.i386 0:1.0.1-2.1 libXft-devel.i386 0:2.1.10-1.1 libXrender-devel.i386 0:0.9.1-3.1 libart_lgpl.i386 0:2.3.17-4 libpng-devel.i386 2:1.2.10-7.1.el5_0.1 libpng-devel.x86_64 2:1.2.10-7.1.el5_0.1 mesa-libGL-devel.i386 0:6.5.1-7.5.el5 xorg-x11-proto-devel.i386 0:7.1-9.fc6Complete!
Pasul 2:
Copiem ultima versiune a sistemului de monitorizare RRDTool
# cd /opt/
# wget http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.3.1.tar.gz
Pasul3:
Compilăm şi instalăm pachetul pe care l-am copiat.
# export PKG_CONFIG_PATH=/usr/lib/pkgconfig/
# ./configure
Trebuie sa obţinem așa ceva.
onfig.status: executing default-1 commandsconfig.status: executing intltool commandsconfig.status: executing default commands
31
config.status: executing po/stamp-it commandschecking in... and out againordering CD from http://tobi.oetiker.ch/wish .... just kidding " class="wp-smiley"> ----------------------------------------------------------------Config is DONE! With MMAP IO: yes Static programs: no Perl Modules: perl_piped perl_shared Perl Binary: /usr/bin/perl Perl Version: 5.8.8 Perl Options: PREFIX=/usr/local/rrdtool-1.3.1 LIB=/usr/local/rrdtool-1.3.1/lib/perl/5.8.8 Ruby Modules: Ruby Binary: no Ruby Options: sitedir=$(DESTDIR)NONE/lib/ruby Build Tcl Bindings: no Build Python Bindings: yes Build rrdcgi: yes Build librrd MT: yes Link with libintl: yes Libraries: -lxml2 -lcairo -lcairo -lcairo -lm -lcairo -lpng12 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Type 'make' to compile the software and use 'make install' toinstall everything to: /usr/local/rrdtool-1.3.1. ... that wishlist is NO JOKE. If you find RRDtool usefulmake me happy. Go to http://tobi.oetiker.ch/wish andplace an order. -- Tobi Oetiker ----------------------------------------------------------------
Continuam sa facem instalarea sistemului de monitorizare.
# make
# make install
# cd /usr/local/
# ln -s rrdtool-1.3.1/ rrdtool/
# cd rrdtool
# ls -l
Testam daca totul sa instalat si lucrează bine.
# cd /usr/local/rrdtool/share/rrdtool/examples/
# ./stripes.pl
# ls -l
# cp stripes.png /var/www/html/
Ca să testăm daca merge sistemul nostru, avem nevoie sa deschidem browserul si sa scriem adresa
calculatorului pe care am instalat sistemul dat in felul următor http://adresa
calculatorului/monitoring.png. Şi vom vedea ca ce am obţinut ca în fig. 2.3.1
32
Fig. 2.3.1
Crearea bazei de date in RRDTool (rrdb).
Deci, pentru a începe descrie utilizării de utilităţi din pachetul rrdtool. Pentru a crea rrdb utilizam
comanda rrdtool, care are următoarea sintaxă:
. / Rrdtool filename.rrd – lungimea pasului \ calea
Parametru specifică numele fişierului rrdb filename.rrd (poate fi absolută sau relativă), - lungimea
pasului - specifică numărul de secunde între rrdb presupune update-uri, urmate de stabilirea surselor
de date (DS). Linii DS descrie sursele de date care vor veni în rrdb, opţiuni DS-line sunt după cum
urmează:
Aici este un exemplu de creare a rrdb:
. / Rrdtool / usr / local / var / rrdtool / myrouter.rrd - pas 300 \
DS: intrare: COUNTER: 600: U: U \
DS: ieșire: Counter: 600: U: U \
RRA: medie: 0.5:1:600 \
RRA: medie: 0.5:6:700 \
RRA: medie: 0.5:24:775 \
RRA: medie: 0.5:288:797 \
RRA: MAX: 0.5:1:600 \
RRA: MAX: 0.5:6:700 \
RRA: MAX: 0.5:24:775 \
RRA: max: 0.5:288:797
Această comandă creează rrdb myrouter.rrd pentru a elimina statisticile de la router de la interfaţa de
33
reţea, presupunând că datele din acesta va fi trimis la fiecare 5 minute pentru a stabili două surse de
date: contor de primit şi de trimis bytes, iar computerul nu are nici restricţie de mai sus sau mai jos .
Se creează 8 rânduri, dintre care patru sunt utilizate pentru media funcţia de date, precum şi alte
MAX. Aceasta creează următoarele intervale: 600 celule timp de 5 minute, 700 de celule de 30 de
minute (5 * 6), 775 celule timp de două ore (5 * 24), precum şi 797 celule, care să păstreze statistici
pentru a doua zi. În acest caz simulează lucrul sistemului de monitorizare MRTG, de fabricaţie a
statisticei in intervalele de timp.
2.4. Instalarea sistemului de monitorizare Munin.
În cazul sistemului de operare CentOS, avem posibilitatea sa instalăm sistemul nostru de
monitorizare din repozitoriu, dar ca sa putem face aşa ceva va trebui sa ne conectam la el si asta o
vom face in felul următor.
rpm-Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-
1.el5.rf.i386.rpm
Instalăm pachetul Munin şi-nod Munin cu utilita yum.
yum install Munin Munin-node
După cum am mai spus ca Munin este alcătuit din două părţi, un pachet al sistemului de
monitorizare Munin pentru noduri, care ar trebui să funcţioneze pe un server care dorim să-l
monitorizez, dar sistemul de monitorizare Munin are inca o parte care poate fi instalat în altă parte.
În cazul nostru, totul va fi la unul şi acelaşi server. În mod implicit, fişierul de configurare / etc /
Munin / Munin-node.conf accesul este permis numai la nivel local.
Creaţi un folder care Munin va genera fişiere (htmldir opţiune în / etc / Munin / munin.conf):
# mkdir / var / www / html / Munin
# cd / var / www / html / Munin
# chown munin:munin / var / www / html / Munin
Vom porni sistemul nostru de monitorizare:
# service munin-node start
34
Numai decât trebuie să configuram sistemul nostru ca sa se pornească automat când vom se va porni
serverul nostru:
chkconfig --level 345 munin-node on
La fiecare 5 minute (/ etc / cron.d / Munin), Munin va actualiza grafica, care se va adăuga in
mapa / var / www / html / Munin.
Tot ce a mai rămas – de creat un server web pentru a avea aces la / var / www / html / Munin.
În cazul nostru vom utiliza Apache, recoltarea datelor este deja în fişierul de configurare / etc /
httpd / conf.d / munin.conf.
Ca să testăm daca merge sistemul nostru, avem nevoie sa deschidem browserul si sa scriem adresa
calculatorului pe care am instalat sistemul dat in felul următor http://adresa
calculatorului/monitoring.png. Şi vom vedea ca ce am obţinut ca în fig. 2.4.1.
Fig. 2.4.1
35
2.5. Configurarea sistemului de monitorizare pe server.
Pentru a instala un sistem de monitorizare pe un server cu sistem de operare Linux avem
nevoie ca sa copiem sau sa-l instalam un soft care se ocupa de asta. In cazul nostru vom alege
sistemul de monitorizare Nagios.
Pasul 1.
Ne conectam la server, apoi intram pe el sub root (administratorul de baza). Apoi instalam
softul in cauza.
[root@nicrutnet]# yum install nagios*
Pasul 2.
Editam fișierul /etc/nagios/contacts.cfg unde vom introduce coordonatele pe care vom primi
noutatea si alertele legate de servicii si de servere.
[root@nicrutnet]# nano /etc/nagios/contacs.cfg
/etc/nagios/contacs.cfg
define contact{ contact_name joe alias Joe Blow service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by-email,notify-by-pager host_notification_commands host-notify-by-email,host-notify-by-epager email [email protected] pager [email protected] }
define contact{ contact_name eugen alias eugen service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by-email,notify-by-epager host_notification_commands host-notify-by-email,host-notify-by-epager email [email protected] pager [email protected]
Pasul 3.
36
Vom configura utilizatorii care vor utiliza acest sistem de monitorizare. Si ii vom clasifica pe
grupuri. In fișierul /etc/nagios/contactgroups.cfg
[root@nicrutnet]# nano /etc/nagios/contactgroups.cfg
/etc/nagios/contactgroups.cfg
define contactgroup{ contactgroup_name router_admin alias Network Administrators members eugen}
define contactgroup{ contactgroup_name server_admin alias Systems Administrators members eugen1}
Pasul 4.
Configuram serverele care se vor conecta la sistemul de monitorizare /etc/nagios/hosts.cfg
[root@nicrutnet]# nano /etc/nagios/hosts.cfg
/etc/nagios/hosts.cfgdefine host{ use generic-host host_name gw1.yourdomain.com alias Gateway Router address 10.0.0.1 check_command check-host-alive max_check_attempts 20 notification_interval 240 notification_period 24x7 notification_options d,u,r }
define host{ use generic-host host_name mail.yourdomain.com alias Mail Server address 10.0.0.100 check_command check-host-alive max_check_attempts 20 notification_interval 240 notification_period 24x7 notification_options d,u,r }
Pasul 5.
Serviciile de care avem nevoie ca sa le avem in monitoring se afla in fișierul
/etc/nagios/services.cfg
37
[root@nicrutnet]# nano /etc/nagios/services.cfg
/etc/nagios/services.cfg
define service{ use generic-service host_name mail.yourdomain.com service_description SMTP is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups server_admin notification_interval 240 notification_period 24x7 notification_options w,u,c,r check_command check_smtp }
define service{ use generic-service host_name gw1.yourdomain.com service_description PING is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups router_admin notification_interval 240 notification_period 24x7 notification_options w,u,c,r check_command check_ping!100.0,20%!500.0,60% }
Pasul 6.
Testam daca tot ce am editat noi este corect si fără greşeli.
[root@nicrutnet]# nagios -v /etc/nagios/nagios.cfg
Pasul 7.
Se creaza parola pentru utilizatorul care va utiliza sistemul nostru.
[root@nicrutnet]# htpasswd2 -nb nagiosadmin mypassword >> /etc/nagios/htpasswd.users
Pasul 8.
Pornim sistemul nostru de monitorizare.
[root@nicrutnet]# /etc/init.d/nagios start
Controlam daca sa pornit serverul nostru pentru monitorizare clienților de la care vom primi
date. Fig. 2.5.1.
38
Fig. 2.5.1.
2.6. Configurarea unui client care va fi monitorizat.
De asemenea vom alege un server la care sistemul de operare este Linux si vom instala pe el
partea client al sistemului de monitorizare.
Pasul 1.
Instalam sistemul pe serverul client.
[root@dits]#yum install nagios-nrpe
Pasul 2.
Gătim fișierele pentru editare.
[root@dits]#cd /etc/nagios[root@dits]#chown nagios.nagios *.cfg
Pasul 3.
Editam fișierul /etc/nagios/nrpe.cfg
[root@dits]#nano /etc/nagios/nrpe.cfg
/etc/nagios/nrpe.cfg# addservice nrpe{ flags = REUSE type = UNLISTED port = 5666 socket_type = stream wait = no
39
user = nagios group = nagios server = /usr/sbin/nrpe server_args = -c /etc/nagios/nrpe.cfg --inetd log_on_failure += USERID disable = no # was yes only_from = NAGIOS_MASTER_IP (master nagios host you want toconnect from) # was localhost}
Pasul 4.
Pornim clientul ca sa înceapă a transmite datele la serverul de monitorizare.
[root@dits]# /sbin/service nrpe start (fig. 2.6.1)
Fig. 2.6.1
40
Concluzie.
Efectuând teza de master, am determinat ca într-o rețea de calculatoare este foarte important
de creat si de derulat un sistem de monitorizare cit mai eficient.
Avînd un sistem de monitorizare vom putea permanent sa identificam si corectam erorile ce
apar, precum si problemele care apar in rețea.
Un sistem de monitorizare bine configurat trebuie sa ne inştiintizeze cit mai rapid, in cazul in care
apar problem legate de rețea si serviciile prestate.
Exista multe sisteme de monitorizare, fiecare având atât puncte forte, cit si neajunsuri. Pentru
a identifica un sistem optimal trebuie sa testam foarte multe din ele si sa ne gândim ce date si
servicii dorim sa monitorizăm. După ce apreciem care servicii trebuie de monitorizat, începem sa
căutam sistemul de monitorizare care ne convine noua.
In teza respectiva am testat patru sisteme de monitorizare, in urma căreia am observat ca cel
mai bun este Nagios deoarece el ne informează rapid in cazul in care apare o abatere legată de rețea
sau de serviciu prestat. Intr-o rețea de calculatoare e de dorit ca sa fie doua puncte in rețea care sa
monitorizeze, pentru a avea o informație cît mai bună şi mai vastă despre ceea ce se petrece în rețea,
precum si informaţii ce ţin de serviciile pe care le prestăm.
După implementarea sistemului de monitorizare in organizaţia NicrutNet S.R.L. s-a facilitat
mult lucru de administrare a reţelelor şi serviciilor ce sunt prestate. În urma acesteia s-a constatat că
monitorizarea reţelelor si serviciilor a devenit mai eficientă şi mai rapidă în depistarea problemelor
ce survin. În urma practicii pe care am efectuat-o am remarcat ca este necesar sa existe doua servere
pe care sa fie instalat sistemul de monitorizare, deoarece uneori problemele care apar sunt observate
cu întirziere.
Aceste întirzieri apar din cauza reţelei supraincărcate sau din alte motive tehnice, cum ar fi
lipsa luminii, sau nefuncţionarea plachetei de reţea şi multe altele. Cu astfel de probleme m-am
confruntat în timpul implementării sistemului de monitorizare, pe care le-am rezolvat creaînd şi al
doilea server de monitorizare.
41
Bibliografie
1. Olaf Kirch – “Руководство администратора сети в ОС Linux.” 2003
2. Smith, P. – “Client/Server Computing Second Edition”, Sams Publishing, 2005
3. Pascu C., Pascu A., -“Totul despre…Unix“, Editura Tehnica, Bucuresti 2007
4. Lars Wirzenius – “ОС Linux. Руководство системного администратора “ 2001
5. Sven Goldt, Sven van der Meer, Skott Burkett, Matt Welsh - “Linux Programmer's
Guide” 2002
6. А. Соловьев “ПРОГРАММИРОВАНИЕ НА shell (UNIX)” 2006
7. Traducere: Денис Каледин, Ник Фролов, Алекс Казанков - “Linux from scratch”
1998
8. Karl Fogel Producing – “Open Source Software” 1999
9. Parker T., Sportack M. – “TCP/IP”, Editura Teora, 2002
10. Ray J., Ray W. – “Administrarea sistemului UNIX”, Editura Teora, 2003
11. Dădârlat V.T. – “Retele locale de calculatoare - de la cablare la interconectare (editia III)”,
Editura Albastră, 2001
12. Vásárhelyi J., Kása Z. – “Mit si adevãr despre virusii calculatoarelor”, Editura 2001
13. Nastase F. – “Arhitectura retelelor de calculatoare”, Editura Economică, 1998
14. Muller N.J. – “Enciclopedia Internet”, Editura Tehnica, 2004
15. Levine J.R., Baroudi Carol, Levine Young M. – “Internet” Editura Tehnică, 2001
16. Karnyanszky T.M. – “Reţele de calculatoare si comunicatii de date”, Editura 2001
17. Tannenbaum A.S. – “Reţele de calculatoare”, Computer Press Agora, 1996
18. Peterson L., Davie B. – “Reţele de calculatoare”, Editura All Education, 2000
19. Oprea D. – “Protecţia şi securitatea sistemelor informaţionale”, Editura Polirom, 2002
20. Dusmore B., Brown W.J. – “Internet security”, Syngress, 2000
21. Cerchez E. – “Internet. Utilizarea reţelei Internet”, Editura Polirom, 2004
22. Munteanu A., Greavu Ş.V. – “Reţele locale de calculatoare”, Editura Polirom, 2004
23. http://www.nagios.org
24. http://www.munin.org
25. http://oss.oetiker.ch/mrtg/
26. http://oss.oetiker.ch/rrdtool/
27. http://www.boutell.com/gd/
28. http: / / www.libpng.org/pub/png/src/
29. ftp://sunsite.cnlab-switch.ch/mirror/infozip/zlib/
30. http://people.ee.ethz.ch/ oetiker ~ / webtools / MRTG /
42
Anexe.
Munin.cfg[root@nicrutnet ~]# cat /etc/munin/munin.conf
# Example configuration file for Munin, generated by 'make build'
# The next three variables specifies where the location of the RRD
# databases, the HTML output, and the logs, severally. They all
# must be writable by the user running munin-cron.
dbdir /var/lib/munin
htmldir /var/www/html/monin
logdir /var/log/munin
rundir /var/run/munin
# Where to look for the HTML templates
tmpldir /etc/munin/templates
# Make graphs show values per minute instead of per second
#graph_period minute
# Drop [email protected] and [email protected] an email everytime
# something changes (OK -> WARNING, CRITICAL -> OK, etc)
#contact.someuser.command mail -s "Munin notification" [email protected]
#contact.anotheruser.command mail -s "Munin notification" [email protected]
#
# For those with Nagios, the following might come in handy. In addition,
# the services must be defined in the Nagios server as well.
#contact.nagios.command /usr/sbin/send_nsca -H nagios.host.com -c
/etc/send_nsca.cfg
# a simple host tree
[localhost]
address 127.0.0.1
use_node_name yes
[nagios1]
Addres
s 188.94.83.4
use_node_name yes
[server1]
address 109.185.38.41
use_node_name yes
[server2]
43
address 93.116.151.240
use_node_name yes
[dits]
address 95.65.92.71
[ltghibu]
address 87.248.180.145
use_node_name yes
[shciocilteni]
address 92.115.41.108
use_node_name yes
#
# A more complex example of a host tree
#
## First our "normal" host.
# [fii.foo.com]
# address foo
#
## Then our other host...
# [fay.foo.com]
# address fay
#
## Then we want totals...
# [foo.com;Totals] #Force it into the "foo.com"-domain...
# update no # Turn off data-fetching for this "host".
#
# # The graph "load1". We want to see the loads of both machines...
# # "fii=fii.foo.com:load.load" means "label=machine:graph.field"
# load1.graph_title Loads side by side
# load1.graph_order fii=fii.foo.com:load.load fay=fay.foo.com:load.load
#
# # The graph "load2". Now we want them stacked on top of each other.
# load2.graph_title Loads on top of each other
# load2.dummy_field.stack fii=fii.foo.com:load.load
fay=fay.foo.com:load.load
# load2.dummy_field.draw AREA # We want area instead the default LINE2.
# load2.dummy_field.label dummy # This is needed. Silly, really.
#
# # The graph "load3". Now we want them summarised into one field
# load3.graph_title Loads summarised
# load3.combined_loads.sum fii.foo.com:load.load fay.foo.com:load.load
# load3.combined_loads.label Combined loads # Must be set, as this is
# # not a dummy field!
#
44
## ...and on a side note, I want them listen in another order (default is
## alphabetically)
#
# # Since [foo.com] would be interpreted as a host in the domain "com", we
# # specify that this is a domain by adding a semicolon.
# [foo.com;]
# node_order Totals fii.foo.com fay.foo.com
#
Munin-node.cfg
[root@nicrutnet ~]# cat /etc/munin/munin-node.conf
#
# Example config-file for munin-node
#
log_level 4
log_file /var/log/munin/munin-node.log
port 4949
pid_file /var/run/munin/munin-node.pid
background 1
setseid 1
# Which port to bind to;
host *
user root
group root
setsid yes
# Regexps for files to ignore
ignore_file ~$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
# Set this if the client doesn't report the correct hostname when
# telnetting to localhost, port 4949
#
#host_name lisse.hasselt.wieers.com
# A list of addresses that are allowed to connect. This must be a
# regular expression, due to brain damage in Net::Server, which
# doesn't understand CIDR-style network notation. You may repeat
# the allow line as many times as you'd like
45
allow ^127\.0\.0\.1$
Nagios.cfg
################################################################################ NAGIOS.CFG - Sample Main Config File for Nagios 3.2.0## Read the documentation for more information on this configuration# file. I've provided some comments here, but things may not be so# clear without further explanation.## Last Modified: 12-14-2008###############################################################################
# LOG FILE# This is the main log file where service and host events are logged# for historical purposes. This should be the first option specified # in the config file!!!
log_file=/var/log/nagios/nagios.log
# OBJECT CONFIGURATION FILE(S)# These are the object configuration files in which you define hosts,# host groups, contacts, contact groups, services, etc.# You can split your object definitions across several config files# if you wish (as shown below), or keep them all in a single config file.
# You can specify individual object config files as shown below:cfg_file=/etc/nagios/objects/commands.cfgcfg_file=/etc/nagios/objects/contacts.cfgcfg_file=/etc/nagios/objects/timeperiods.cfgcfg_file=/etc/nagios/objects/templates.cfg
# Definitions for monitoring the local (Linux) hostcfg_file=/etc/nagios/objects/nagios1.cfgcfg_file=/etc/nagios/objects/nicrutnet.cfgcfg_file=/etc/nagios/objects/dits.cfgcfg_file=/etc/nagios/objects/srvsl2.cfgcfg_file=/etc/nagios/objects/or-nicrutnet.cfgcfg_file=/etc/nagios/objects/vdm.cfgcfg_file=/etc/nagios/objects/nagios2.cfgcfg_file=/etc/nagios/objects/ltghibu.cfgcfg_file=/etc/nagios/objects/shciocilteni.cfgcfg_file=/etc/nagios/objects/mikrotik.cfgcfg_file=/etc/nagios/objects/videoCompsrv1.cfgcfg_file=/etc/nagios/objects/videoCompsrv2.cfgcfg_file=/etc/nagios/objects/host01.nicrutnet.com.cfg
# Definitions for monitoring a Windows machine#cfg_file=/etc/nagios/objects/windows.cfg
# Definitions for monitoring a router/switchcfg_file=/etc/nagios/objects/accesspoint.cfg
# Definitions for monitoring a network printer#cfg_file=/etc/nagios/objects/printer.cfg
# You can also tell Nagios to process all config files (with a .cfg# extension) in a particular directory by using the cfg_dir# directive as shown below:
#cfg_dir=/etc/nagios/servers
46
#cfg_dir=/etc/nagios/printers#cfg_dir=/etc/nagios/switches#cfg_dir=/etc/nagios/routers
# OBJECT CACHE FILE# This option determines where object definitions are cached when# Nagios starts/restarts. The CGIs read object definitions from # this cache file (rather than looking at the object config files# directly) in order to prevent inconsistencies that can occur# when the config files are modified after Nagios starts.
object_cache_file=/var/nagios/objects.cache
# PRE-CACHED OBJECT FILE# This options determines the location of the precached object file.# If you run Nagios with the -p command line option, it will preprocess# your object configuration file(s) and write the cached config to this# file. You can then start Nagios with the -u option to have it read# object definitions from this precached file, rather than the standard# object configuration files (see the cfg_file and cfg_dir options above).# Using a precached object file can speed up the time needed to (re)start # the Nagios process if you've got a large and/or complex configuration.# Read the documentation section on optimizing Nagios to find our more# about how this feature works.
precached_object_file=/var/nagios/objects.precache
# RESOURCE FILE# This is an optional resource file that contains $USERx$ macro# definitions. Multiple resource files can be specified by using# multiple resource_file definitions. The CGIs will not attempt to# read the contents of resource files, so information that is# considered to be sensitive (usernames, passwords, etc) can be# defined as macros in this file and restrictive permissions (600)# can be placed on this file.
resource_file=/etc/nagios/resource.cfg
# STATUS FILE# This is where the current status of all monitored services and# hosts is stored. Its contents are read and processed by the CGIs.# The contents of the status file are deleted every time Nagios# restarts.
status_file=/var/nagios/status.dat
# STATUS FILE UPDATE INTERVAL# This option determines the frequency (in seconds) that# Nagios will periodically dump program, host, and # service status data.
status_update_interval=10
# NAGIOS USER# This determines the effective user that Nagios should run as. # You can either supply a username or a UID.
nagios_user=nagios
# NAGIOS GROUP
47
# This determines the effective group that Nagios should run as. # You can either supply a group name or a GID.
nagios_group=nagios
# EXTERNAL COMMAND OPTION# This option allows you to specify whether or not Nagios should check# for external commands (in the command file defined below). By default# Nagios will *not* check for external commands, just to be on the# cautious side. If you want to be able to use the CGI command interface# you will have to enable this.# Values: 0 = disable commands, 1 = enable commands
check_external_commands=1
# EXTERNAL COMMAND CHECK INTERVAL# This is the interval at which Nagios should check for external commands.# This value works of the interval_length you specify later. If you leave# that at its default value of 60 (seconds), a value of 1 here will cause# Nagios to check for external commands every minute. If you specify a# number followed by an "s" (i.e. 15s), this will be interpreted to mean# actual seconds rather than a multiple of the interval_length variable.# Note: In addition to reading the external command file at regularly # scheduled intervals, Nagios will also check for external commands after# event handlers are executed.# NOTE: Setting this value to -1 causes Nagios to check the external# command file as often as possible.
#command_check_interval=15scommand_check_interval=-1
# EXTERNAL COMMAND FILE# This is the file that Nagios checks for external command requests.# It is also where the command CGI will write commands that are submitted# by users, so it must be writeable by the user that the web server# is running as (usually 'nobody'). Permissions should be set at the # directory level instead of on the file, as the file is deleted every# time its contents are processed.
command_file=/var/nagios/rw/nagios.cmd
# EXTERNAL COMMAND BUFFER SLOTS# This settings is used to tweak the number of items or "slots" that# the Nagios daemon should allocate to the buffer that holds incoming # external commands before they are processed. As external commands # are processed by the daemon, they are removed from the buffer.
external_command_buffer_slots=4096
# LOCK FILE# This is the lockfile that Nagios will use to store its PID number# in when it is running in daemon mode.
lock_file=/var/run/nagios.pid
# TEMP FILE# This is a temporary file that is used as scratch space when Nagios# updates the status log, cleans the comment file, etc. This file# is created, used, and deleted throughout the time that Nagios is# running.
temp_file=/var/nagios/nagios.tmp
48
# TEMP PATH# This is path where Nagios can create temp files for service and# host check results, etc.
temp_path=/tmp
# EVENT BROKER OPTIONS# Controls what (if any) data gets sent to the event broker.# Values: 0 = Broker nothing# -1 = Broker everything# <other> = See documentation
event_broker_options=-1
# EVENT BROKER MODULE(S)# This directive is used to specify an event broker module that should# by loaded by Nagios at startup. Use multiple directives if you want# to load more than one module. Arguments that should be passed to# the module at startup are seperated from the module path by a space.##!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!# WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!## Do NOT overwrite modules while they are being used by Nagios or Nagios# will crash in a fiery display of SEGFAULT glory. This is a bug/limitation# either in dlopen(), the kernel, and/or the filesystem. And maybe Nagios...## The correct/safe way of updating a module is by using one of these methods:# 1. Shutdown Nagios, replace the module file, restart Nagios# 2. Delete the original module file, move the new module file into place, restart Nagios## Example:## broker_module=<modulepath> [moduleargs]
#broker_module=/somewhere/module1.o#broker_module=/somewhere/module2.o arg1 arg2=3 debug=0
# LOG ROTATION METHOD# This is the log rotation method that Nagios should use to rotate# the main log file. Values are as follows..# n = None - don't rotate the log# h = Hourly rotation (top of the hour)# d = Daily rotation (midnight every day)# w = Weekly rotation (midnight on Saturday evening)# m = Monthly rotation (midnight last day of month)
log_rotation_method=d
# LOG ARCHIVE PATH# This is the directory where archived (rotated) log files should be # placed (assuming you've chosen to do log rotation).
log_archive_path=/var/log/nagios/archives
# LOGGING OPTIONS# If you want messages logged to the syslog facility, as well as the# Nagios log file set this option to 1. If not, set it to 0.
use_syslog=1
49
# NOTIFICATION LOGGING OPTION# If you don't want notifications to be logged, set this value to 0.# If notifications should be logged, set the value to 1.
log_notifications=1
# SERVICE RETRY LOGGING OPTION# If you don't want service check retries to be logged, set this value# to 0. If retries should be logged, set the value to 1.
log_service_retries=1
# HOST RETRY LOGGING OPTION# If you don't want host check retries to be logged, set this value to# 0. If retries should be logged, set the value to 1.
log_host_retries=1
# EVENT HANDLER LOGGING OPTION# If you don't want host and service event handlers to be logged, set# this value to 0. If event handlers should be logged, set the value# to 1.
log_event_handlers=1
# INITIAL STATES LOGGING OPTION# If you want Nagios to log all initial host and service states to# the main log file (the first time the service or host is checked)# you can enable this option by setting this value to 1. If you# are not using an external application that does long term state# statistics reporting, you do not need to enable this option. In# this case, set the value to 0.
log_initial_states=0
# EXTERNAL COMMANDS LOGGING OPTION# If you don't want Nagios to log external commands, set this value# to 0. If external commands should be logged, set this value to 1.# Note: This option does not include logging of passive service# checks - see the option below for controlling whether or not# passive checks are logged.
log_external_commands=1
# PASSIVE CHECKS LOGGING OPTION# If you don't want Nagios to log passive host and service checks, set# this value to 0. If passive checks should be logged, set# this value to 1.
log_passive_checks=1
# GLOBAL HOST AND SERVICE EVENT HANDLERS# These options allow you to specify a host and service event handler# command that is to be run for every host or service state change.# The global event handler is executed immediately prior to the event# handler that you have optionally specified in each host or# service definition. The command argument is the short name of a# command definition that you define in your host configuration file.# Read the HTML docs for more information.
50
#global_host_event_handler=somecommand#global_service_event_handler=somecommand
# SERVICE INTER-CHECK DELAY METHOD# This is the method that Nagios should use when initially# "spreading out" service checks when it starts monitoring. The# default is to use smart delay calculation, which will try to# space all service checks out evenly to minimize CPU load.# Using the dumb setting will cause all checks to be scheduled# at the same time (with no delay between them)! This is not a# good thing for production, but is useful when testing the# parallelization functionality.# n = None - don't use any delay between checks# d = Use a "dumb" delay of 1 second between checks# s = Use "smart" inter-check delay calculation# x.xx = Use an inter-check delay of x.xx seconds
service_inter_check_delay_method=s
# MAXIMUM SERVICE CHECK SPREAD# This variable determines the timeframe (in minutes) from the# program start time that an initial check of all services should# be completed. Default is 30 minutes.
max_service_check_spread=30
# SERVICE CHECK INTERLEAVE FACTOR# This variable determines how service checks are interleaved.# Interleaving the service checks allows for a more even# distribution of service checks and reduced load on remote# hosts. Setting this value to 1 is equivalent to how versions# of Nagios previous to 0.0.5 did service checks. Set this# value to s (smart) for automatic calculation of the interleave# factor unless you have a specific reason to change it.# s = Use "smart" interleave factor calculation# x = Use an interleave factor of x, where x is a# number greater than or equal to 1.
service_interleave_factor=s
# HOST INTER-CHECK DELAY METHOD# This is the method that Nagios should use when initially# "spreading out" host checks when it starts monitoring. The# default is to use smart delay calculation, which will try to# space all host checks out evenly to minimize CPU load.# Using the dumb setting will cause all checks to be scheduled# at the same time (with no delay between them)!# n = None - don't use any delay between checks# d = Use a "dumb" delay of 1 second between checks# s = Use "smart" inter-check delay calculation# x.xx = Use an inter-check delay of x.xx seconds
host_inter_check_delay_method=s
# MAXIMUM HOST CHECK SPREAD# This variable determines the timeframe (in minutes) from the# program start time that an initial check of all hosts should# be completed. Default is 30 minutes.
max_host_check_spread=30
# MAXIMUM CONCURRENT SERVICE CHECKS
51
# This option allows you to specify the maximum number of # service checks that can be run in parallel at any given time.# Specifying a value of 1 for this variable essentially prevents# any service checks from being parallelized. A value of 0# will not restrict the number of concurrent checks that are# being executed.
max_concurrent_checks=0
# HOST AND SERVICE CHECK REAPER FREQUENCY# This is the frequency (in seconds!) that Nagios will process# the results of host and service checks.
check_result_reaper_frequency=10
# MAX CHECK RESULT REAPER TIME# This is the max amount of time (in seconds) that a single# check result reaper event will be allowed to run before # returning control back to Nagios so it can perform other# duties.
max_check_result_reaper_time=30
# CHECK RESULT PATH# This is directory where Nagios stores the results of host and# service checks that have not yet been processed.## Note: Make sure that only one instance of Nagios has access# to this directory!
check_result_path=/var/nagios/spool/checkresults
# MAX CHECK RESULT FILE AGE# This option determines the maximum age (in seconds) which check# result files are considered to be valid. Files older than this # threshold will be mercilessly deleted without further processing.
max_check_result_file_age=3600
# CACHED HOST CHECK HORIZON# This option determines the maximum amount of time (in seconds)# that the state of a previous host check is considered current.# Cached host states (from host checks that were performed more# recently that the timeframe specified by this value) can immensely# improve performance in regards to the host check logic.# Too high of a value for this option may result in inaccurate host# states being used by Nagios, while a lower value may result in a# performance hit for host checks. Use a value of 0 to disable host# check caching.
cached_host_check_horizon=15
# CACHED SERVICE CHECK HORIZON# This option determines the maximum amount of time (in seconds)# that the state of a previous service check is considered current.# Cached service states (from service checks that were performed more# recently that the timeframe specified by this value) can immensely# improve performance in regards to predictive dependency checks.# Use a value of 0 to disable service check caching.
52
cached_service_check_horizon=15
# ENABLE PREDICTIVE HOST DEPENDENCY CHECKS# This option determines whether or not Nagios will attempt to execute# checks of hosts when it predicts that future dependency logic test# may be needed. These predictive checks can help ensure that your# host dependency logic works well.# Values:# 0 = Disable predictive checks# 1 = Enable predictive checks (default)
enable_predictive_host_dependency_checks=1
# ENABLE PREDICTIVE SERVICE DEPENDENCY CHECKS# This option determines whether or not Nagios will attempt to execute# checks of service when it predicts that future dependency logic test# may be needed. These predictive checks can help ensure that your# service dependency logic works well.# Values:# 0 = Disable predictive checks# 1 = Enable predictive checks (default)
enable_predictive_service_dependency_checks=1
# SOFT STATE DEPENDENCIES# This option determines whether or not Nagios will use soft state # information when checking host and service dependencies. Normally # Nagios will only use the latest hard host or service state when # checking dependencies. If you want it to use the latest state (regardless# of whether its a soft or hard state type), enable this option. # Values:# 0 = Don't use soft state dependencies (default) # 1 = Use soft state dependencies
soft_state_dependencies=0
# TIME CHANGE ADJUSTMENT THRESHOLDS# These options determine when Nagios will react to detected changes# in system time (either forward or backwards).
#time_change_threshold=900
# AUTO-RESCHEDULING OPTION# This option determines whether or not Nagios will attempt to# automatically reschedule active host and service checks to# "smooth" them out over time. This can help balance the load on# the monitoring server. # WARNING: THIS IS AN EXPERIMENTAL FEATURE - IT CAN DEGRADE# PERFORMANCE, RATHER THAN INCREASE IT, IF USED IMPROPERLY
auto_reschedule_checks=0
# AUTO-RESCHEDULING INTERVAL# This option determines how often (in seconds) Nagios will# attempt to automatically reschedule checks. This option only# has an effect if the auto_reschedule_checks option is enabled.# Default is 30 seconds.# WARNING: THIS IS AN EXPERIMENTAL FEATURE - IT CAN DEGRADE# PERFORMANCE, RATHER THAN INCREASE IT, IF USED IMPROPERLY
auto_rescheduling_interval=30
53
# AUTO-RESCHEDULING WINDOW# This option determines the "window" of time (in seconds) that# Nagios will look at when automatically rescheduling checks.# Only host and service checks that occur in the next X seconds# (determined by this variable) will be rescheduled. This option# only has an effect if the auto_reschedule_checks option is# enabled. Default is 180 seconds (3 minutes).# WARNING: THIS IS AN EXPERIMENTAL FEATURE - IT CAN DEGRADE# PERFORMANCE, RATHER THAN INCREASE IT, IF USED IMPROPERLY
auto_rescheduling_window=180
# SLEEP TIME# This is the number of seconds to sleep between checking for system# events and service checks that need to be run.
sleep_time=0.25
# TIMEOUT VALUES# These options control how much time Nagios will allow various# types of commands to execute before killing them off. Options# are available for controlling maximum time allotted for# service checks, host checks, event handlers, notifications, the# ocsp command, and performance data commands. All values are in# seconds.
service_check_timeout=60host_check_timeout=30event_handler_timeout=30notification_timeout=30ocsp_timeout=5perfdata_timeout=5
# RETAIN STATE INFORMATION# This setting determines whether or not Nagios will save state# information for services and hosts before it shuts down. Upon# startup Nagios will reload all saved service and host state# information before starting to monitor. This is useful for # maintaining long-term data on state statistics, etc, but will# slow Nagios down a bit when it (re)starts. Since its only# a one-time penalty, I think its well worth the additional# startup delay.
retain_state_information=1
# STATE RETENTION FILE# This is the file that Nagios should use to store host and# service state information before it shuts down. The state # information in this file is also read immediately prior to# starting to monitor the network when Nagios is restarted.# This file is used only if the preserve_state_information# variable is set to 1.
state_retention_file=/var/nagios/retention.dat
# RETENTION DATA UPDATE INTERVAL# This setting determines how often (in minutes) that Nagios# will automatically save retention data during normal operation.# If you set this value to 0, Nagios will not save retention# data at regular interval, but it will still save retention# data before shutting down or restarting. If you have disabled# state retention, this option has no effect.
54
retention_update_interval=60
# USE RETAINED PROGRAM STATE# This setting determines whether or not Nagios will set # program status variables based on the values saved in the# retention file. If you want to use retained program status# information, set this value to 1. If not, set this value# to 0.
use_retained_program_state=1
# USE RETAINED SCHEDULING INFO# This setting determines whether or not Nagios will retain# the scheduling info (next check time) for hosts and services# based on the values saved in the retention file. If you# If you want to use retained scheduling info, set this# value to 1. If not, set this value to 0.
use_retained_scheduling_info=1
# RETAINED ATTRIBUTE MASKS (ADVANCED FEATURE)# The following variables are used to specify specific host and# service attributes that should *not* be retained by Nagios during# program restarts.## The values of the masks are bitwise ANDs of values specified# by the "MODATTR_" definitions found in include/common.h. # For example, if you do not want the current enabled/disabled state# of flap detection and event handlers for hosts to be retained, you# would use a value of 24 for the host attribute mask...# MODATTR_EVENT_HANDLER_ENABLED (8) + MODATTR_FLAP_DETECTION_ENABLED (16) = 24
# This mask determines what host attributes are not retainedretained_host_attribute_mask=0
# This mask determines what service attributes are not retainedretained_service_attribute_mask=0
# These two masks determine what process attributes are not retained.# There are two masks, because some process attributes have host and service# options. For example, you can disable active host checks, but leave active# service checks enabled.retained_process_host_attribute_mask=0retained_process_service_attribute_mask=0
# These two masks determine what contact attributes are not retained.# There are two masks, because some contact attributes have host and# service options. For example, you can disable host notifications for# a contact, but leave service notifications enabled for them.retained_contact_host_attribute_mask=0retained_contact_service_attribute_mask=0
# INTERVAL LENGTH# This is the seconds per unit interval as used in the# host/contact/service configuration files. Setting this to 60 means# that each interval is one minute long (60 seconds). Other settings# have not been tested much, so your mileage is likely to vary...
interval_length=60
# CHECK FOR UPDATES# This option determines whether Nagios will automatically check to# see if new updates (releases) are available. It is recommend that you# enable this option to ensure that you stay on top of the latest critical# patches to Nagios. Nagios is critical to you - make sure you keep it in
55
# good shape. Nagios will check once a day for new updates. Data collected# by Nagios Enterprises from the update check is processed in accordance # with our privacy policy - see http://api.nagios.org for details.
check_for_updates=1
# BARE UPDATE CHECK# This option deterines what data Nagios will send to api.nagios.org when# it checks for updates. By default, Nagios will send information on the # current version of Nagios you have installed, as well as an indicator as# to whether this was a new installation or not. Nagios Enterprises uses# this data to determine the number of users running specific version of # Nagios. Enable this option if you do not want this information to be sent.
bare_update_check=0
# AGGRESSIVE HOST CHECKING OPTION# If you don't want to turn on aggressive host checking features, set# this value to 0 (the default). Otherwise set this value to 1 to# enable the aggressive check option. Read the docs for more info# on what aggressive host check is or check out the source code in# base/checks.c
use_aggressive_host_checking=0
# SERVICE CHECK EXECUTION OPTION# This determines whether or not Nagios will actively execute# service checks when it initially starts. If this option is # disabled, checks are not actively made, but Nagios can still# receive and process passive check results that come in. Unless# you're implementing redundant hosts or have a special need for# disabling the execution of service checks, leave this enabled!# Values: 1 = enable checks, 0 = disable checks
execute_service_checks=1
# PASSIVE SERVICE CHECK ACCEPTANCE OPTION# This determines whether or not Nagios will accept passive# service checks results when it initially (re)starts.# Values: 1 = accept passive checks, 0 = reject passive checks
accept_passive_service_checks=1
# HOST CHECK EXECUTION OPTION# This determines whether or not Nagios will actively execute# host checks when it initially starts. If this option is # disabled, checks are not actively made, but Nagios can still# receive and process passive check results that come in. Unless# you're implementing redundant hosts or have a special need for# disabling the execution of host checks, leave this enabled!# Values: 1 = enable checks, 0 = disable checks
execute_host_checks=1
# PASSIVE HOST CHECK ACCEPTANCE OPTION# This determines whether or not Nagios will accept passive# host checks results when it initially (re)starts.# Values: 1 = accept passive checks, 0 = reject passive checks
accept_passive_host_checks=1
56
# NOTIFICATIONS OPTION# This determines whether or not Nagios will sent out any host or# service notifications when it is initially (re)started.# Values: 1 = enable notifications, 0 = disable notifications
enable_notifications=1
# EVENT HANDLER USE OPTION# This determines whether or not Nagios will run any host or# service event handlers when it is initially (re)started. Unless# you're implementing redundant hosts, leave this option enabled.# Values: 1 = enable event handlers, 0 = disable event handlers
enable_event_handlers=1
# PROCESS PERFORMANCE DATA OPTION# This determines whether or not Nagios will process performance# data returned from service and host checks. If this option is# enabled, host performance data will be processed using the# host_perfdata_command (defined below) and service performance# data will be processed using the service_perfdata_command (also# defined below). Read the HTML docs for more information on# performance data.# Values: 1 = process performance data, 0 = do not process performance data
process_performance_data=0
# HOST AND SERVICE PERFORMANCE DATA PROCESSING COMMANDS# These commands are run after every host and service check is# performed. These commands are executed only if the# enable_performance_data option (above) is set to 1. The command# argument is the short name of a command definition that you # define in your host configuration file. Read the HTML docs for# more information on performance data.
#host_perfdata_command=process-host-perfdata#service_perfdata_command=process-service-perfdata
# HOST AND SERVICE PERFORMANCE DATA FILES# These files are used to store host and service performance data.# Performance data is only written to these files if the# enable_performance_data option (above) is set to 1.
#host_perfdata_file=/tmp/host-perfdata#service_perfdata_file=/tmp/service-perfdata
# HOST AND SERVICE PERFORMANCE DATA FILE TEMPLATES# These options determine what data is written (and how) to the# performance data files. The templates may contain macros, special# characters (\t for tab, \r for carriage return, \n for newline)# and plain text. A newline is automatically added after each write# to the performance data file. Some examples of what you can do are# shown below.
#host_perfdata_file_template=[HOSTPERFDATA]\t$TIMET$\t$HOSTNAME$\t$HOSTEXECUTIONTIME$\t$HOSTOUTPUT$\t$HOSTPERFDATA$#service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$
# HOST AND SERVICE PERFORMANCE DATA FILE MODES# This option determines whether or not the host and service# performance data files are opened in write ("w") or append ("a")# mode. If you want to use named pipes, you should use the special
57
# pipe ("p") mode which avoid blocking at startup, otherwise you will# likely want the defult append ("a") mode.
#host_perfdata_file_mode=a#service_perfdata_file_mode=a
# HOST AND SERVICE PERFORMANCE DATA FILE PROCESSING INTERVAL# These options determine how often (in seconds) the host and service# performance data files are processed using the commands defined# below. A value of 0 indicates the files should not be periodically# processed.
#host_perfdata_file_processing_interval=0#service_perfdata_file_processing_interval=0
# HOST AND SERVICE PERFORMANCE DATA FILE PROCESSING COMMANDS# These commands are used to periodically process the host and# service performance data files. The interval at which the# processing occurs is determined by the options above.
#host_perfdata_file_processing_command=process-host-perfdata-file#service_perfdata_file_processing_command=process-service-perfdata-file
# OBSESS OVER SERVICE CHECKS OPTION# This determines whether or not Nagios will obsess over service# checks and run the ocsp_command defined below. Unless you're# planning on implementing distributed monitoring, do not enable# this option. Read the HTML docs for more information on# implementing distributed monitoring.# Values: 1 = obsess over services, 0 = do not obsess (default)
obsess_over_services=0
# OBSESSIVE COMPULSIVE SERVICE PROCESSOR COMMAND# This is the command that is run for every service check that is# processed by Nagios. This command is executed only if the# obsess_over_services option (above) is set to 1. The command # argument is the short name of a command definition that you# define in your host configuration file. Read the HTML docs for# more information on implementing distributed monitoring.
#ocsp_command=somecommand
# OBSESS OVER HOST CHECKS OPTION# This determines whether or not Nagios will obsess over host# checks and run the ochp_command defined below. Unless you're# planning on implementing distributed monitoring, do not enable# this option. Read the HTML docs for more information on# implementing distributed monitoring.# Values: 1 = obsess over hosts, 0 = do not obsess (default)
obsess_over_hosts=0
# OBSESSIVE COMPULSIVE HOST PROCESSOR COMMAND# This is the command that is run for every host check that is# processed by Nagios. This command is executed only if the# obsess_over_hosts option (above) is set to 1. The command # argument is the short name of a command definition that you# define in your host configuration file. Read the HTML docs for# more information on implementing distributed monitoring.
#ochp_command=somecommand
58
# TRANSLATE PASSIVE HOST CHECKS OPTION# This determines whether or not Nagios will translate# DOWN/UNREACHABLE passive host check results into their proper# state for this instance of Nagios. This option is useful# if you have distributed or failover monitoring setup. In# these cases your other Nagios servers probably have a different# "view" of the network, with regards to the parent/child relationship# of hosts. If a distributed monitoring server thinks a host# is DOWN, it may actually be UNREACHABLE from the point of# this Nagios instance. Enabling this option will tell Nagios# to translate any DOWN or UNREACHABLE host states it receives# passively into the correct state from the view of this server.# Values: 1 = perform translation, 0 = do not translate (default)
translate_passive_host_checks=0
# PASSIVE HOST CHECKS ARE SOFT OPTION# This determines whether or not Nagios will treat passive host# checks as being HARD or SOFT. By default, a passive host check# result will put a host into a HARD state type. This can be changed# by enabling this option.# Values: 0 = passive checks are HARD, 1 = passive checks are SOFT
passive_host_checks_are_soft=0
# ORPHANED HOST/SERVICE CHECK OPTIONS# These options determine whether or not Nagios will periodically # check for orphaned host service checks. Since service checks are# not rescheduled until the results of their previous execution # instance are processed, there exists a possibility that some# checks may never get rescheduled. A similar situation exists for# host checks, although the exact scheduling details differ a bit# from service checks. Orphaned checks seem to be a rare# problem and should not happen under normal circumstances.# If you have problems with service checks never getting# rescheduled, make sure you have orphaned service checks enabled.# Values: 1 = enable checks, 0 = disable checks
check_for_orphaned_services=1check_for_orphaned_hosts=1
# SERVICE FRESHNESS CHECK OPTION# This option determines whether or not Nagios will periodically# check the "freshness" of service results. Enabling this option# is useful for ensuring passive checks are received in a timely# manner.# Values: 1 = enabled freshness checking, 0 = disable freshness checking
check_service_freshness=1
# SERVICE FRESHNESS CHECK INTERVAL# This setting determines how often (in seconds) Nagios will# check the "freshness" of service check results. If you have# disabled service freshness checking, this option has no effect.
service_freshness_check_interval=60
# HOST FRESHNESS CHECK OPTION# This option determines whether or not Nagios will periodically# check the "freshness" of host results. Enabling this option# is useful for ensuring passive checks are received in a timely# manner.# Values: 1 = enabled freshness checking, 0 = disable freshness checking
59
check_host_freshness=0
# HOST FRESHNESS CHECK INTERVAL# This setting determines how often (in seconds) Nagios will# check the "freshness" of host check results. If you have# disabled host freshness checking, this option has no effect.
host_freshness_check_interval=60
# ADDITIONAL FRESHNESS THRESHOLD LATENCY# This setting determines the number of seconds that Nagios# will add to any host and service freshness thresholds that# it calculates (those not explicitly specified by the user).
additional_freshness_latency=15
# FLAP DETECTION OPTION# This option determines whether or not Nagios will try# and detect hosts and services that are "flapping". # Flapping occurs when a host or service changes between# states too frequently. When Nagios detects that a # host or service is flapping, it will temporarily suppress# notifications for that host/service until it stops# flapping. Flap detection is very experimental, so read# the HTML documentation before enabling this feature!# Values: 1 = enable flap detection# 0 = disable flap detection (default)
enable_flap_detection=1
# FLAP DETECTION THRESHOLDS FOR HOSTS AND SERVICES# Read the HTML documentation on flap detection for# an explanation of what this option does. This option# has no effect if flap detection is disabled.
low_service_flap_threshold=5.0high_service_flap_threshold=20.0low_host_flap_threshold=5.0high_host_flap_threshold=20.0
# DATE FORMAT OPTION# This option determines how short dates are displayed. Valid options# include:# us (MM-DD-YYYY HH:MM:SS)# euro (DD-MM-YYYY HH:MM:SS)# iso8601 (YYYY-MM-DD HH:MM:SS)# strict-iso8601 (YYYY-MM-DDTHH:MM:SS)#
date_format=us
# TIMEZONE OFFSET# This option is used to override the default timezone that this# instance of Nagios runs in. If not specified, Nagios will use# the system configured timezone.## NOTE: In order to display the correct timezone in the CGIs, you# will also need to alter the Apache directives for the CGI path # to include your timezone. Example:
60
## <Directory "/usr/local/nagios/sbin/"># SetEnv TZ "Australia/Brisbane"# ...# </Directory>
#use_timezone=US/Mountain#use_timezone=Australia/Brisbane
# P1.PL FILE LOCATION# This value determines where the p1.pl perl script (used by the# embedded Perl interpreter) is located. If you didn't compile# Nagios with embedded Perl support, this option has no effect.
p1_file=/usr/bin/p1.pl
# EMBEDDED PERL INTERPRETER OPTION# This option determines whether or not the embedded Perl interpreter# will be enabled during runtime. This option has no effect if Nagios# has not been compiled with support for embedded Perl.# Values: 0 = disable interpreter, 1 = enable interpreter
enable_embedded_perl=1
# EMBEDDED PERL USAGE OPTION# This option determines whether or not Nagios will process Perl plugins# and scripts with the embedded Perl interpreter if the plugins/scripts# do not explicitly indicate whether or not it is okay to do so. Read# the HTML documentation on the embedded Perl interpreter for more # information on how this option works.
use_embedded_perl_implicitly=1
# ILLEGAL OBJECT NAME CHARACTERS# This option allows you to specify illegal characters that cannot# be used in host names, service descriptions, or names of other# object types.
illegal_object_name_chars=`~!$%^&*|'"<>?,()=
# ILLEGAL MACRO OUTPUT CHARACTERS# This option allows you to specify illegal characters that are# stripped from macros before being used in notifications, event# handlers, etc. This DOES NOT affect macros used in service or# host check commands.# The following macros are stripped of the characters you specify:# $HOSTOUTPUT$# $HOSTPERFDATA$# $HOSTACKAUTHOR$# $HOSTACKCOMMENT$# $SERVICEOUTPUT$# $SERVICEPERFDATA$# $SERVICEACKAUTHOR$# $SERVICEACKCOMMENT$
illegal_macro_output_chars=`~$&|'"<>
# REGULAR EXPRESSION MATCHING# This option controls whether or not regular expression matching# takes place in the object config files. Regular expression# matching is used to match host, hostgroup, service, and service# group names/descriptions in some fields of various object types.
61
# Values: 1 = enable regexp matching, 0 = disable regexp matching
use_regexp_matching=0
# "TRUE" REGULAR EXPRESSION MATCHING# This option controls whether or not "true" regular expression # matching takes place in the object config files. This option# only has an effect if regular expression matching is enabled# (see above). If this option is DISABLED, regular expression# matching only occurs if a string contains wildcard characters# (* and ?). If the option is ENABLED, regexp matching occurs# all the time (which can be annoying).# Values: 1 = enable true matching, 0 = disable true matching
use_true_regexp_matching=0
# ADMINISTRATOR EMAIL/PAGER ADDRESSES# The email and pager address of a global administrator (likely you).# Nagios never uses these values itself, but you can access them by# using the $ADMINEMAIL$ and $ADMINPAGER$ macros in your notification# commands.
admin_email=nagios@localhostadmin_pager=pagenagios@localhost
# DAEMON CORE DUMP OPTION# This option determines whether or not Nagios is allowed to create# a core dump when it runs as a daemon. Note that it is generally# considered bad form to allow this, but it may be useful for# debugging purposes. Enabling this option doesn't guarantee that# a core file will be produced, but that's just life...# Values: 1 - Allow core dumps# 0 - Do not allow core dumps (default)
daemon_dumps_core=0
# LARGE INSTALLATION TWEAKS OPTION# This option determines whether or not Nagios will take some shortcuts# which can save on memory and CPU usage in large Nagios installations.# Read the documentation for more information on the benefits/tradeoffs# of enabling this option.# Values: 1 - Enabled tweaks# 0 - Disable tweaks (default)
use_large_installation_tweaks=0
# ENABLE ENVIRONMENT MACROS# This option determines whether or not Nagios will make all standard# macros available as environment variables when host/service checks# and system commands (event handlers, notifications, etc.) are# executed. Enabling this option can cause performance issues in # large installations, as it will consume a bit more memory and (more# importantly) consume more CPU.# Values: 1 - Enable environment variable macros (default)# 0 - Disable environment variable macros
enable_environment_macros=1
# CHILD PROCESS MEMORY OPTION# This option determines whether or not Nagios will free memory in# child processes (processed used to execute system commands and host/# service checks). If you specify a value here, it will override# program defaults.
62
# Value: 1 - Free memory in child processes# 0 - Do not free memory in child processes
#free_child_process_memory=1
# CHILD PROCESS FORKING BEHAVIOR# This option determines how Nagios will fork child processes# (used to execute system commands and host/service checks). Normally# child processes are fork()ed twice, which provides a very high level# of isolation from problems. Fork()ing once is probably enough and will# save a great deal on CPU usage (in large installs), so you might# want to consider using this. If you specify a value here, it will# program defaults.# Value: 1 - Child processes fork() twice# 0 - Child processes fork() just once
#child_processes_fork_twice=1
# DEBUG LEVEL# This option determines how much (if any) debugging information will# be written to the debug file. OR values together to log multiple# types of information.# Values: # -1 = Everything# 0 = Nothing# 1 = Functions# 2 = Configuration# 4 = Process information# 8 = Scheduled events# 16 = Host/service checks# 32 = Notifications# 64 = Event broker# 128 = External commands# 256 = Commands# 512 = Scheduled downtime# 1024 = Comments# 2048 = Macros
debug_level=0
# DEBUG VERBOSITY# This option determines how verbose the debug log out will be.# Values: 0 = Brief output# 1 = More detailed# 2 = Very detailed
debug_verbosity=1
# DEBUG FILE# This option determines where Nagios should write debugging information.
debug_file=/var/log/nagios/nagios.debug
# MAX DEBUG FILE SIZE# This option determines the maximum size (in bytes) of the debug file. If# the file grows larger than this size, it will be renamed with a .old# extension. If a file already exists with a .old extension it will# automatically be deleted. This helps ensure your disk space usage doesn't# get out of control when debugging Nagios.
max_debug_file_size=1000000
63
nicrutnet.cfg
define host{ use linux-server ; Inherit default values from a template host_name NicrutNet-Host ; The name we're giving to this server alias NicrutNet ; A longer name for the server address nicrutnet.com ; IP address of the server }
define service{ use generic-service host_name NicrutNet-Host service_description CPU Load check_command check_nrpe!check_load }define service{ use generic-service host_name NicrutNet-Host service_description Current Users check_command check_nrpe!check_users }define service{ use generic-service host_name NicrutNet-Host service_description / Free Space Root check_command check_nrpe!check_hda1 }define service{ use generic-service host_name NicrutNet-Host service_description Total Processes check_command check_nrpe!check_total_procs }define service{ use generic-service host_name NicrutNet-Host service_description Zombie Processes check_command check_nrpe!check_zombie_procs }
define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description DNS check_command check_tcp!53 notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description MySQL check_command check_nrpe!check_mysql notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description NRPE check_command check_tcp!5666 notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description Http check_command check_tcp!80 notifications_enabled 0 }#define service{
64
# use local-service ; Name of service template to use# host_name NicrutNet-Host# service_description SSH# check_command check_tcp!2048# notifications_enabled 0# }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description FTP check_command check_tcp!21 notifications_enabled 0 }#define service{# use local-service ; Name of service template to use# host_name NicrutNet-Host# service_description Squid# check_command check_tcp!3128# notifications_enabled 0# }#define service{# use generic-service ; Name of service template to use# host_name NicrutNet-Host# service_description Ping Server# check_period 24x7# check_command check_ping!100.0,50%!200.0,60%# notifications_enabled 0# }
define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description SMTP check_command check_tcp!25 notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description PoP3 check_command check_tcp!110 notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-Host service_description IMAP check_command check_tcp!143 notifications_enabled 0 }
Or-nicrutnet.cfg
define host{ use linux-server ; Inherit default values from a template host_name NicrutNet-OR ; The name we're giving to this server alias NicrutNet ; A longer name for the server address bsd.nicrutnet.com ; IP address of the server parents NicrutNet-Host }
define service{
65
use generic-service host_name NicrutNet-OR service_description CPU Load check_command check_nrpe!check_load }define service{ use generic-service host_name NicrutNet-OR service_description Current Users check_command check_nrpe!check_users }define service{ use generic-service host_name NicrutNet-OR service_description /dev/hda1 Free Space check_command check_nrpe!check_hda1 }define service{ use generic-service host_name NicrutNet-OR service_description Total Processes check_command check_nrpe!check_total_procs }define service{ use generic-service host_name NicrutNet-OR service_description Zombie Processes check_command check_nrpe!check_zombie_procs }
define service{ use local-service ; Name of service template to use host_name NicrutNet-OR service_description NRPE check_command check_tcp!5666 notifications_enabled 0 }define service{ use local-service ; Name of service template to use host_name NicrutNet-OR service_description SSH check_command check_tcp!2048 notifications_enabled 0 }define service{ use generic-service ; Name of service template to use host_name NicrutNet-OR service_description Ping Server check_period 24x7 check_command check_ping!100.0,50%!200.0,60% notifications_enabled 0 }
66