Apologies for the delay - hope comments are still useful!
I totally agree with Leslie and Francois. Some extra comments I would add:
1) An overhall of netview.baroc and netview.rls would be good. I have a
feeling that by redesigning some of the TEC class attributes, the rule
scould be made simpler and more effective.
2) There are no rules that test for duplicates - they all test for
instances - rules could be made much more effective with a review in
this area
3) Events and classes relevant to NetView detecting services, are very
confusing. The default baroc and rls files only operate on the events
generated out of the itmquery/servmon integration (ie. TEC_ITS_NODE /
SERVICE_IMPACT). I have not yet found anyone who uses this servmon
functionality but I do find people who use servmon to monitor services
based on port sniffing / custom scripts. By default, these NetView
events (TEC_ITS_SERVICE_STATUS) are NOT forwarded to TEC by TEC_ITS.rs
and there are no rules in netview.rls to handle these events.
4) The synchronization rules are great - my only disappointment is that
the script that actually generates a TRAP from TEC back to NetView, ends
up in a Java "black-hole". I would like to see a Perl or shellscript
implementation so that people can modify this and/or use it as a sample
on which to base other automation.
5) All the stuff to do with TEC_ITS_NODE / SERVICE_IMPACT events could
be dropped (IMHO). I know no-one who uses it and it adds lots of
complexity. With the advent of ITM 6.1, I suspect that anything to do
with NetView's itmquery is going to become past history. This has a
much wider impact in that it would remove the need for the SCE in the
NetView TEC adapter (as the only thing it does today is lookup DB2, WAS
and MQ services as detected by itmquery) and again simplify things
significantly in the TEC adapter.
6) The nv_latency parameter defining time to search for similar events
in the rules cache, is the same for all rules. I often want different
values for different rules. How about defining nv_latency300,
nv_latency_600, nv_latency_1200 etcetera in the initialisation section
and using them more appropriately - folk can then easily change the
search time if they want to.
7) I totally agree with Leslie's point about the interface event being
causal when a router is unreachable. I usually modify
interface_correlate_router and router_correlate_interface to make the
router_unreachable event causal to the interface_unreachable effect.
8) I have had a bit of a go at re-writing some of netview.rls with
correlation primitives to define sequences of events. Once I had the
syntax right, it made the code MUCH shorter and a bit more
intelligible. I have not done this for more than a couple of sample
rules, but Francois's comment about the size and complexity of
netview.rls is very apt.
I think that's my 2-penn'orth.
Cheers,
Jane
James Shanks wrote:
Hello everyone,
I've been asked whether anyone has any comments he or she would luike to
make on the default NetView TEC rules in 7.1.4.
Are they useful or not? If you wrote your own did you use them as a
sample? Or did they just get in the way?
Anyone care to comment?
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2005 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
|