What follows is a delinquent response to the HP request
for feedback on this subject; been working for awhile and
finally finished. Post in case still of pre-IPROF interest,
and to allow the usual throwing of rocks if I said something
that doesn't seem to make sense...... ~135 lines total......
Ken Sletten
=========================================
The "Who's Connected to the 3000 Project":
We would especially like to concur with the inputs HP
already received from Kirby Joss and Chris Bartram; they
both did a good job of stating what they said; Chris did a
particularly nice job of laying out detailed suggestions.
Rather than try and say what Chris did in other words, I'm
going to take it upon myself to provide some additional
comments and variations, in a slightly different format than
the example layout you posted to the list (I tend to interpret
instructions liberally in most cases...). So here goes:
=========================================
USERS: SM, OP, and Image/SQL database admininstrators.
GOALS:
(1) Prevent unauthorized system access.
(2) Be able to efficiently monitor system access and activity
by all users. Zero in on users who are having problems, and
also on users who are causing problems (not quite the same).
(3) Be able to gracefully get rid of *all* hung/ghost net sessions,
WITHOUT having to reboot the system (maybe this is out of
scope for the project in question, but recent problems we
have had with this cause me to mention it every chance
I get (but we just went to 5.0 PUSH last Friday, and I am
told some of the problems in this area have been fixed (??))).
.... Then again, you did list "SM or OP can easily *resolve*
problems" as one of your identified business goals......
(4) Increase visibility of *all* non-direct-DTC-connect access,
which currently tend to be more-or-less invisible.
(5) Except maybe for stuff like various exotic, obscure network
problems (for which you may need a network analyzer, etc.),
be able to do (1) through (4) above in an integrated fashion
directly on the 3000.
TASKS:
Kirby Joss, Chris Bartram, and others laid out some good
scenarios. Without trying to repeat the good points that have
already been raised, a couple more thoughts/refinements:
(1) Expanding on one of Chris Bartram's suggestions to be
able to configure lists of allowed originating IP addresses:
We would like to be able to configure both an ALLOW *and*
a DISALLOW list, and be able to do that using at least basic
wild card syntax. I.e: Be able to put in everything from one
or more specific IP entries, to something like [log in to unmask]@
(2) In any attempt to do a new SHOWCONN command or etc.
like Chris suggested, including the <hostname.domain.org>
or <[log in to unmask]> whenever possible
is important. And leave plenty of space for this; some (like
mine) are really long (hmmm..... admit I don't know what the
the theoretical or practical max is.....).
(3) We would like to be able to set variable trigger values for
various network access (or should I say "excess") activities,
and automatically log "problem" events. Details of just how
this logging should be done I won't try and speculate on. The
key is being able to effectively filter problem events out of the
massive volume of "normal" net activity. Example: If someone
out there is continually sending or receiving huge numbers of
TCP packets for an extended period, we would like to have a
record...... Actually, we would also like some kind of an "alarm"
to go off...... We might even want to be able to configure a
level-dependent "freeze" (or dump to ES queue) of net users
that appear to be running totally amuck (we have had some).
....... Maybe we are getting a bit out of project scope again, but
as before: The "SM or OP can easily resolve problems" goal.....
FREQUENCY: We monitor daily as best we can now. Real crises
is when system starts going south and we can't figure it
out.
IMPACT: All of the comments by other users who have already
responded apply.
TODAY: What we would like to be able to do is either not possible,
or requires an inordinate amount of time stumbling
around.
TOMORROW:
Second the motion on bunch of good ideas already mentioned
by others. PLUS: Considering all of the above, it seems like
one thing we should definitely have as part of a solution
in this area is a "NETWORK" screen in GLANCE, where
all the neat things you have done and are going to do could
be coalesced and integrated. Even though Glance is not
part of FOS, it seems like one obvious place to do this.
ONE MORE IDEA on GLANCE: How about adding some
basic user-defined scripting and logic capability to
GLANCE; for ex., something like (many possible variations):
IF (# of TCP packets) IN ( { 'x'-seconds | refresh interval } )
> (pick a #) THEN { CS | DS | ES | SUSPEND }
This would allow us to automatically put sessions that might try
and download 400 MBtyes to their PC or etc. during the busy
part of the day into the ES queue..... Of course we would want
any such type of IF-THEN logic to apply not just to network
parameters, but also to CPU usage and maybe disc I/O.....
....Suppose now I've *really* gotten off project scope...... In any
case, another reason logic like above would be nice is that we
don't have time to monitor GLANCE continually during the day;
sometimes before we notice and/or user(s) start complaining,
the problem may have been going on for a long time. So all this
would come under the "avoid/fix the problem before they notice"
heading.
PLUS: Since GLANCE runs in the 'B' queue, if the system is
really starting to go south sometimes GLANCE is the last thing
we can talk to; one more reason to put things like this there.....
==========================================
Thank you to HP for the opportunity to comment.
See y'all at IPROF..... Over 50 users signed up for
SIGNETWORKING on Saturday, at last count....
===========================================
Ken Sletten ** Tel: 360-396-2525
NUWC Division Keyport ** Fax: 360-396-7861
Code 3311, Building 894
Keyport, WA 98345
[log in to unmask]
===========================================
** Yes, area code is changing: 360 instead of 206.
|
