We are using Nav 3.0, and have a router that we monitor that went down on Friday night, and found out about it this morning when the remote location called. I am currently setup to receive notification on any box down, and received nothing via e-mail. Additionally, we monitor 24/7 on the Traffic Map, but it never showed the device as down/unreachable. What debug info would help troubleshoot this problem? What configuration settings can I verify to make sure this box is configured correctly?
Joshua Sidwell
From Ingeborg.Hellemo at cc.uit.no Tue Jan 10 10:53:53 2006
From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Tue Jan 10 10:54:00 2006 Subject: [Nav-users] Feature requests anyone? In-Reply-To: Your message of "Wed, 04 Jan 2006 14:01:44 +0100." Pine.LNX.4.64.0601041322380.18181@tyholt-ng.uninett.no Message-ID: 200601100953.k0A9rrTV049797@dis.cc.uit.no
Vidar.Faltinsen@uninett.no said:
We are currently working on a list of new features to implement. I could present the list, but at this stage I will rather ask the NAV community... what do you want?
The University og Troms? now proudly presents their wish list:
(Well Vidar, you asked for it...)
-----
Programming/packaging style:
* Fewer languages NAV of today is dependent of almost every scripting language known to man, except ruby (oops, I shouldn't have said that!). Please make sure that new features does not involve more languages and small packages (which must be of exactly version x.y-rc2) only found on obscure and badly connected websites.
* Less JAVA The first language we would like to say goodbye (and good riddance!) to is Java. It is a PIA to get to work on FreeBSD and a problem for all platforms to configure and get all paths etc. correct. Of course you still need Java for visualisation, but for the data collector we would like to see threaded python or even C as this would be more portable and easyer to maintain.
-----
Features:
* Please make today's features work before you put all your resources on new features.
* Please implement the features we have lost from earlier versions of NAV and the features you have promised us for the last years before you put all your resources on new features.
Some of the things we have noticed:
* The world is down NAVv3 does not recognice that it has lost connection to its switch and wrongly reports this as "the world is down!"
* Alert profile - Filters based on "Sub category" does not work. - Double messages/sms-es are sent out - Need more documentation
* Better sms-handling. We loose messages today during large outages.
* Traffic map - Same problems as reported by others
* cricket - We miss the zoom-in function fram NAVv2. Perhaps this is just a FreeBSD-loss, but we would really like this integrated into the main cricket-package so that we can upgrade cricket at will without having to wait for a NAV-patch.
* Larger fields in some database tables (we have problems with 'room' and 'location')
-----
When you have done all this we would please like to have:
* Support for boxes that NTNU does not use (i.e. 3750) and stacked switches.
* Support for weatherducks.
* Better handling of modules
* System for receiving alerts (and generating alarms) from other systems i.e. snmptraps, email, syslog.
* Support for data collection via http, telnet/ssh from systems that does not support snmp.
* Snapshot view of VLAN, duplex etc. of a port/interface
* cricket - Better cricket-integration for servers and UPS-es (and wireless). What we want is makecricketconfig.pl to automatic update a cricket-subtree for these devices. - sorted load statistics
* Better support for threshholds (responce time, filling of disks, cpu load etc.)
* We want to set individual threshholds for when a box/service is registered as down. (A well connected server is down if unreachable for 1 minute, a server behind a shaky radiolink is down if unreachable for 10 minutes)
* Better service monitoring - More services - Take into consideration that a service may have its own IP-address that runs on another server. I.e. box host.uit.no has IP-address 10.10.10.1 The host runs services smtp.uit.no with address 10.10.10.2 and web.uit.no with address 10.10.10.3. I only need _service_ monitoring on the two latter addresses (no need to ping them) and if I put host.uit.no on maintenance I do not want receive alarms about smtp.uit.no or web.uit.no (neither ip-addresses nor services)
* Maintenance - Must be able to put a service on maintenance. - Better user interface. - Be able to put "all" boxes and services at a given location on maintenance.
* Better "devicemanagement"/"IP Device Center". Should these perhaps merge? When we do a https://nav.uit.no/browse/some_box we also want to see info from devicemanagement like - IOS-version - upgraded when? - register comments about device - etc.
* RSS-feed
* Possibility to exclude subnet (in a config-file) that we don't want NAV to use. Eg. 127.0.0.1/8
-----
Regarding syslog:
Our view is first of all that syslog does not belong in a database. Period. (Prosessed and aggregated information from syslog may be put in a database, but only after you have identified what you are looking for.)
Syslog from Cisco is particularly difficult to parse because every type of device has its own syntax, and small configuration changes on the device will result in completely different syntax. This is why today's syslog module in NAV does not work for anyone besides those who implemented the parser.
There exist a number of syslog collecting/parsing systems out there, some good, some not so good. To put much effort into implementing syslog collection in NAV is to reinvent the weel. We think it would be better to implement a system that can receive alerts from an external syslog-parsing system.
What we would like to see in NAV is the ability to show normal syslog-files with moderate search/grep functionality. We are currently doing som work on this for our helpdesk so they can check the radius-syslog without having access to our main syslogserver.
------
Best wishes for the new NAV year...
Ingeborg and B?rge