Questions - Features

[Jeremy Kister]

On 4/5/2005 1:37 PM, Francois Mikus wrote:
> - support for remote agent running on various platforms which return 
> information like: state, service, message
> Similar to big brother agents, nagios agents. An easy way to extend 
> things without re-inventing the wheel is supporting nagios and/or Big 
> brother agent communications. Supporting multiple event messages per 
> message is also very nice(bulk messages), this avoids the event bloat 
> associated with Nagios.

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.

so long as the Big brother or nagios agent talks over IP, Argus can
communicate with it.  I cant think of a time I'd rather have a daemon
besides SNMP on the remote machines, though.

Argus supports summary messages ("multiple event messages per message")

> - using queue-ing for receiving events. This insures that events from 
> remote agents are never lost when the computer is too busy to process 
> incoming events . This enables better uses of processing ressources, 
> resiliency, possibility of dropping low priority events. I do not know 
> any open-source nms's that really support sophisticated level queuing.

Argus doesnt receive any events.  It proactively polls things.  One
could easily write a daemon to listen for traps, and have argus monitor
that daemon, though.

When you receive a trap, you are depending on everything working
correctly, which [for anything besides informational purposes] is silly.
 When you proactively poll a service, you're sure.

> - correlation engine that supports all service checks and events with 
> hierarchies, circular and other types. This seems to be supported!

..

> - support for maintenance periods in alerts and reporting. This would 
> include recurring periods, one time scheduled periods, administrative 
> reason, contact name.

yep.  docs on "cron" are included.

> - flapping alert recognition events, alert acknowledgment, with 
> administrative reason, contact name. Acknowledgement via web, email, etc.

no flapping recognition that i know of.  I'm not sure how that could be
implemented correctly (I can obviously think of a few ways to implement
it _incorrectly_).

In addition to your other prerequisites, you can ack via AIM.  acking
via AIM and email doesnt come out-of-the-box, but it's trivial to
implement.  note unless you set up PGP, ACKing via email or AIM is
terribly insecure.

> - pager blackout periods based on support criteria.
> Example: Where for some checks, if the service goes down, do not page 
> between midnight and 8am. Send an email(or other type of non-intrusive 
> alert) and queue the page until 8am.

not paging between certain hours is easy.  See "cron" in the docs.

Queuing pages is not supported without your own code.

This can be overcome by creating a 'Log' method that will log all the
status changes to a text file, or to sql database or [...], and looking
at the log in the morning.

> - generating a unique ticket number for alerts so that they can be 
> tracked by helpdesk applications or easily referred to by technical 
> support team.

each notification has it's own unique* id.

* these id's will not be unique for ever.

> - support for external actions on events. The external script should be 
> user provided.

yep.  see 'Method' in the docs.

> - 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.

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.

> 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.

> I think argus is very interesting, it would gain from exposure, but I am 
> still not clear if it is ready for replacing nagios based systems?

argus.tcp4me.com contains multiple testimonials about dumping nagios for
argus.


-- 

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