Subject: Re: Questions - Features

From: Jeff Weisberg <[email-masked]>
Date: Tue, 5 Apr 2005 20:47:41 -0400 (EDT)

| > - support for remote agent running on various platforms which return 
| > information like: state, service, message
| 
| SNMP is a universal 'agent'.  I dont know of any other specifically
| written agents, but Argus will easily accommodate anything you can throw
| at it.

SNMP is the preferred remote agent. most SNMP servers can be configured
to report on disk use, processes, or run your own program.

argus also comes with a 'argus-agent' which can be run out
of inetd on remote machines to monitor disk use, cpu load, etc,
for people who for some reason don't want to use SNMP.

| We've requested a 'warning', but Argus' author is taking an "I dont know
| how to do it because I'm not that good" approach.

huh? requested what? do you mean something like:
	severity: warning

| > - same colour/event scheme as big brother. (colour for no data, red for 
| > alert, yellow for warning, colour for stale data) Also have color icons 
| > with a twist, for acknowledged alarms, or other special events. This 
| > makes it easy to see that someone is working on a problem.

definitely not. argus has no animated spinning icons.
argus does not have a disgusting jelly-bean-vomit color scheme.
just a simple clean look.

the author considers this a feature.

| > To win over people and developpers you need to support user hooks: 
| > Ability to create your own services checks, external actions, support 
| > for third party agents. A monitoring platform should be able to leverage 
| > external utilities and also *be* leveraged by external utilities. No 
| > system is in a vaccum.
| 
| it's clear you havent even tried Argus :) Argus is a good thing.
| 
| Argus plays well with external utilities.  Provided, is an 'argusctl'
| program, which lets external utilities play with Argus.

it is also trivial to run any program as a service test.

	--jeff

---

From: Francois Mikus <[email-masked]>
Date: Tue, 05 Apr 2005 21:29:27 -0400

> huh? requested what? do you mean something like:

For my part, what I meant was, that it would be nice to have a yellow 
colour for visualisation of alerts which are considered warnings. This 
way administrators know that they have to look at it, but not 
necessarely urgently.

> the author considers this a feature.
lol

I have to agree with you, spinning icons and other distractions have 
little place in serious web content. But, I have to acknowledge that the 
big brother interface was excellent at summarizing and displaying 
information much better than most other systems. Of course the system, I 
worked with was heavily customized by a collegue.. Even with it's 
animated icons.. That is not to say that BB was perfect, far from it, 
Big brother simply does not scale.

Back to the topic at hand!

Let me re-phrase.

You get an alert. The services goes red on the web interface. An alert 
goes to a sys admin. The admin looks at the issue, acknowledges that he 
is working on it. Great.

What is very useful is having a visual way of representing that, there 
is an alert, but someone is looking at it. This could be a check mark, etc.

A second thing. If argus has a display hierarchy for alerts, it is nice 
for this hierarchy to reflect that the alter was acknowledged. This way 
if another alert is triggered, it would be easy to notice that there was 
a new one, even from a hiearchical point of view. The is immense value 
in hiding complexity with hierarchical views with inhereted alert 
status. (Which is one reason things like big brother, netcool and others 
that use this type of display are so popular)

Maybe argus already has all this and I should just go try all the 
features and be done with it! :-)

In any case the project looks great.. look forward to testing in my lab 
network.

Francois Mikus

---

From: Jeremy Kister <[email-masked]>
Date: Wed, 06 Apr 2005 14:30:19 -0400

> huh? requested what? do you mean something like:

I mean a new object status that arguscgi can display

there could be a "degraded" status in addition to the current Up, Down,
and Override.

we've discussed it several times, but came to no consensus on how it
should be implemented.  As I recall, my last suggestion was:

if an 'up' object fails a probe, change it's state to 'degraded'

if a 'degraded' object fails (retries-1) times, change state to 'down'
if a 'degraded' object responds (retries-1) times, change state to 'up'.

if a 'down' object responds to a probe, change state to 'degraded'

-- 

Jeremy Kister
http://jeremy.kister.net/