A few other ideas for this DB based NOCOL...
1. add a PHYS_ID and LOGICAL_ID field. the physical id field could be
something like a circuit id, and the logical id field can contain a
customer id...this will allow those of us who need to to integrate
nocol/snips with financial and billing systems such as SAP and Infranet.
2. add PARENT_IP field. this will allow us to instill logical
dependencies to hide fields and generate maps and groupings based on
ip_address and parent_ip
3. add PARENT_FAIL_VAR field. this will allow us to stop monitoring
the 2,000 children behind the parent if the parent goes down (until it
comes back up) on the variable specified. some would be set to the same
variable as their service, others would be set to 'ICMP' for example.
4. add a SERVICE field.. it would be for example 'ippingmon'... so when
in perl you do soemthing like this (after we convert to an OOP module)...
$instance = new SNIPS('ippingmon');
then we can remove services from the database if the PID dies and promote
proper cleanup by use of $instance->initialize or $instance->cleanup.
5. set up a graphical interface with collapseable parent/child
relationships so you could see as much or as little as you want.
6. rather than have a 'query based view console' like i suggested, have a
'query based filter' on that view console. for example, create a filter
called 'Chicago' where the query is 'device_host LIKE '%.chi.netrail.net'
and add that query to all view queries...this way we can set up several
filters for different cities, logical groupings, or even set up views for
the customers to see their limited portion of the network.
7. use of some graphics library (or HTML coding) to create maps. openview
integration would be real nice, but i doubt anyone would be willing to do
that for free.
Thank you,
Jonathan A. Zdziarski
Sr. Systems Administrator
Netrail, inc.
888.NET.RAIL x240
http://www.netrail.net
|