От както бях администратор на LinkBG, аз използвам cacti и nagios за мониторинг системи.
С времето привикнах към плюсовете и минусите на cacti-то, и като цяло до ден днешен го използвам.
Обаче времената се менят и нуждите също…
Днес ще сравня cacti и Observium (Observium vs. Cacti) в няколко реда:
За разлика от cacti, observium има много готина функция auto-discovery – автоматично засича всички процеси и ресурси и започва да им прави графики. При cacti това се прави ръчно.
И двете имат подобен тип графики, но observium дава възможност за preview режим за всяка от графиките.
Observium се обновява значително по-бързо от cacti – observium – 1 секунда ; cacti – 5 минути :O
Cacti в действие
Observium в действие
Единственият минус който съм видял до сега в Observium, е изискването за валиден DNS запис – без него observium неможе да работи :/
От месец някъде, използвам и двете системи паралелно и следя приликите и разликите помежду им спрямо графиките.
Observium започна да ми харесва все повече и повече, и днес реших, че е време да спра да използвам cacti и да премина изцяло на него.!
Така че…. Благодаря ти cacti за всичките тези години вярна служба! Време е да продължим напред 🙂
PS.
За да се скрие досадната карта на observium в dashboard-а , е нужно да се добави следния ред в /opt/observium/config.php :
Тъй като използвам cacti за мониторинг на сървърите ми, исках да добавя и домашния рутер TP-LINK TL-WR841N/ND v7 който има инсталиран OpenWRT, да мога да следя трафика му. За целта инсталирах пакета mini-snmpd тъй като е доста малък на размери (сравнение със snmpd) а TP-Link-a като цяло няма кой знае колко място :
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
rootfs 1.1M 632.0K 456.0K 58% /
Използвах стандартния конфигурационен файл намиращ се в /etc/config/mini_snmpd като промених community, contact и location-a.
До тук всичко добре, обаче открих че през сървъра не виждам да е отворен порт-а на snmp-то (UDP 161), а през локалната мрежа си е ок.
Тук се досетих че имах наскоро подобен проблем със SSH демона, и тогава го оправих, като добавих SSH в /etc/config/firewall.
Ето как изглеждаха нещата на практика:
nmap от сървъра:
alpha:~# nmap -sU -p 161 192.168.168.101
Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-26 12:02 EET
Nmap scan report for wifi (192.168.168.101)
Host is up (0.00050s latency).
PORT STATE SERVICE
161/udp closed snmp
nmap от вътрешната мрежа:
laptop ~ # nmap -sU -p 161 10.0.2.1
Starting Nmap 6.40 ( http://nmap.org ) at 2014-01-26 12:03 EET
Nmap scan report for 10.0.2.1
Host is up (0.0012s latency).
PORT STATE SERVICE
161/udp open|filtered snmp
Ето и какво промених за да оправя проблема:
добавих това в /etc/config/firewall:
#Allow snmp
config rule
option src wan
option proto udp
option dest_port 161
option target ACCEPT
И така в крайна сметка от сървъра нещата изглеждат вече така:
alpha:~# nmap -sU -p 161 192.168.168.101
Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-26 12:18 EET
Nmap scan report for wifi (192.168.168.101)
Host is up (0.00061s latency).
PORT STATE SERVICE
161/udp open|filtered snmp
Тук идва и момента в настройката на cacti-то. Нямам идея дали това е от самия демон mini-snmp или от нещо друго, но при стандартни настройки за Downed Device Detection да бъде SNMP Uptime, Cacti-то казва : SNMP Information SNMP error.
Четох в нета че този проблем се оправя като се сменя от SNMP Uptime на Ping, и Ping Method се слага на ICMP Ping.
Така при пуснато Verbose Query, резултата е следния: Data Query Debug Information
+ Running data query [1].
+ Found type = '3' [SNMP Query].
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/interface.xml'
+ XML file parsed ok.
+ Executing SNMP get for num of indexes @ '.1.3.6.1.2.1.2.1.0' Index Count: 3
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.2.2.1.1' Index Count: 3
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.1' value: '1'
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.2' value: '2'
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.3' value: '3'
+ Located input field 'ifIndex' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.1'
+ Found item [ifIndex='1'] index: 1 [from value]
+ Found item [ifIndex='2'] index: 2 [from value]
+ Found item [ifIndex='3'] index: 3 [from value]
+ Located input field 'ifOperStatus' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.8'
+ Found item [ifOperStatus='Up'] index: 1 [from value]
+ Found item [ifOperStatus='Up'] index: 2 [from value]
+ Found item [ifOperStatus='Up'] index: 3 [from value]
+ Located input field 'ifDescr' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.2'
+ Found item [ifDescr='lo'] index: 1 [from value]
+ Found item [ifDescr='br-lan'] index: 2 [from value]
+ Found item [ifDescr='eth1'] index: 3 [from value]
+ Located input field 'ifName' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.1'
+ Located input field 'ifAlias' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.18'
+ Located input field 'ifType' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.3'
+ Located input field 'ifSpeed' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.5'
+ Located input field 'ifHighSpeed' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.15'
+ Located input field 'ifHwAddr' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.6'
+ Located input field 'ifIP' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.4.20.1.2'
Тъй като съм голям привърженик на доброто старо MRTG не исках и да чувам за други видове мониторинг на системата. В ЛинкБГ ползвахме повече cacti и по-малко MRTG , и от там знам доста трикове и неща за cacti-то. Хубаво е , но мен ме кефи като вляза да видя всичко на куп, не да цъкам като див по хостовете за да откривам проблеми и тн..
Отдавна съм хвърлил око на тази системка munin която за разлика от другите две , работи на принципа – сървър – клиент , като това позволява всеки клиент да има активирани отделни плугини и тн.
Това което ми допадна за сега е че адски лесно и бързо се инсталира и конфигурира. Просто елементарно..
Препоръчвам го за начинаещите в тази свера.