Re: which monitoring do you use (on OpenBSD)

2010-10-14 Thread Toni Mueller
Hi,

On Sat, 14.08.2010 at 23:49:49 -0700, Bryan Irvine sparcta...@gmail.com wrote:
 understand.  Also, the OP wanted something that he can run on OpenBSD
 and Zenoss runs on Linux.

hmmm from my perspective, Zenoss looks like an ordinary Zope
application, and should therefore run on OpenBSD as well.


Kind regards,
--Toni++



Re: which monitoring do you use (on OpenBSD)

2010-08-15 Thread Bryan Irvine
I like Zenoss, though the new interface is a little difficult to
understand.  Also, the OP wanted something that he can run on OpenBSD
and Zenoss runs on Linux.  I like splunk a lot as well.  I use splunk
to send events to Zenoss.

-B



On Sat, Aug 14, 2010 at 2:21 AM, Toni Mueller openbsd-m...@oeko.net wrote:
 On Fri, 13.08.2010 at 14:36:21 +0100, Kevin Chadwick ma1l1i...@yahoo.co.uk 
 wrote:
 What do people think of monit.

 Ok, I'll chime in: What do people think of Zenoss and splunk?

 I'm so far leaning twoards trying Zenoss, but it surely has a high
 barrier-of-entry, and I'm only interested in splunk for comparison.


 Kind regards,
 --Toni++



Re: which monitoring do you use (on OpenBSD)

2010-08-15 Thread viq
On Tue, Aug 10, 2010 at 06:05:51PM -0400, Jason Dixon wrote:
 On Tue, Aug 10, 2010 at 01:11:41PM -0700, James Peltier wrote:
  
  Being as I have never used Reconnoiter or Circonus, would you care to 
  elaborate 
  as to where these products suck less then Nagios or other solutions?  I 
  am 
  looking into replacing out very aged monitoring system now and Nagios is 
  the one 
  that seems to stand out the most, although Zabbix and Munin look good in 
  their 
  own rights.
 
 Theo Schlossnagle (our CEO and the architect of Reconnoiter) answers it
 pretty well in his talk from OSCON (requires flash, sorry).
 
 http://omniti.com/video/noit-oscon-demo
  
 In my words, Reconnoiter was designed to overcome a lot of the
 performance and design problems native in Nagios and Cacti.  It does a
 lot of the things that either of those do, although it was designed
 foremost as a highly scalable metrics collection engine.  Like Nagios,
 the types of checks it can perform is virtually limitless.  Unlike
 Nagios, it is highly performant by design.  Checks are deployed across
 scout agents in your network, giving you both perspective and
 non-persective collection points.
 
 The web UI in Reconnoiter is adequate.  One of its really nice features
 is the cli console, allowing you to configure checks and metrics in an
 environment familiar to Cisco admins.

Though from cli you can't reuse templates, which are very handy - thus
for me checks are added in config file. Admittedly reloading of it is
pretty painless.

 That said, the bread-and-butter
 in Reconnoiter is the sort of graphs which you can create and recreate
 with ease.  Unlike trending tools like Cacti, you can easily correlate
 dissimilar metrics in a single graph, with just a few clicks.  Stack
 sets, composite datapoints and RPN conversion of source and display
 values are just a few of the other features that are easy to implement
 within Reconnoiter.

Well, for this it would be highly appreciated if you would expand on the
templating system that there are seeds of present ;) Clicking through
creating graphs for those 20 metrics each on 20 machines is a pain...

  Guidance is always appreciated. :)
 
 Reconnoiter is not for everyone.  It's a very powerful system, but it's
 not intended to be a drop-in replacement for other ECA/Trending systems.
 It takes time and effort to get value out of it, but it offers some
 Capacity Planning and Root Cause Analysis capabilities that aren't
 available or usable in the alternatives.

Agreed, it takes a while to figure out how to set it up, but the graphs
are pretty impressive. And I already at least once post-factum created a
set of graphs showing correlation between various metrics on multiple
machines, showing where possibly the problem came from.

 -- 
 Jason Dixon
 DixonGroup Consulting
 http://www.dixongroup.net/

-- 
viq



Re: which monitoring do you use (on OpenBSD)

2010-08-15 Thread viq
On Sun, Aug 15, 2010 at 12:01:27AM -0400, Jason Dixon wrote:
 On Wed, Aug 11, 2010 at 10:07:53PM +0200, Jiri B. wrote:
  On Tue, 10 Aug 2010 18:05:51 -0400
  Jason Dixon ja...@dixongroup.net wrote:
  
   http://omniti.com/video/noit-oscon-demo
  
  Sorry no flash :)
  
  Some screenshots should be sufficient for this products, interesting is
  there are no screenshots except that architecture picture.
 
 Here's a quick one I just grabbed.  We don't actively use Reconnoiter
 these days as much as we do Circonus.
 
 http://www.flickr.com/photos/78527...@n00/4892326857/
  
  Does it have some event console? So an operator can watch it 24x7 and
  see if something goes wrong and do a repair action?
 
 It has support for alerting in stratcon (iirc), but no fault detection
 functionality is exposed in Reconnoiter's current web UI.

Well, yes and no. There is the whole esper stuff that indeed is in
there, but is described even by the creator as a bit of black magic ;)
Another thing is that you can use for example curl to periodically query
values of the metrics gathered, and for example feed them to nagios, and
have it react to them changing.

In short - it is an infrastructure to gather metrics from a lot of
places, in various ways. And a web interface that allows you to make
pretty graphs of them. For anything more, there are proper pieces in it,
but you need to figure out yourself how to operate them and write
something that will plug into them.
  
  It's nice it can act as snmp trap daemon... A lot of SAN devices have
  SNMP and Vmware ESXes can make good monitoring via SNMP as well.
  
  In our enterprise environment we have huge operators centers which
  watch 24x7 Tivoli Enteprise Console (yeah, ld shite), but what I
  saw is that one can right client on an event and run an action directly
  from event console (OK, it is not used at all but nice feature and you
  exclude possibility to fuck up something just with a similar but bad
  commmand).
 
 P.S. Sorry for the slow response, been enjoying my vacation.  :)
 
 -- 
 Jason Dixon
 DixonGroup Consulting
 http://www.dixongroup.net/

-- 
viq



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Toni Mueller
On Fri, 13.08.2010 at 14:36:21 +0100, Kevin Chadwick ma1l1i...@yahoo.co.uk 
wrote:
 What do people think of monit.

Ok, I'll chime in: What do people think of Zenoss and splunk?

I'm so far leaning twoards trying Zenoss, but it surely has a high
barrier-of-entry, and I'm only interested in splunk for comparison.


Kind regards,
--Toni++



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Stuart Henderson
On 2010-08-14, Toni Mueller openbsd-m...@oeko.net wrote:
 On Fri, 13.08.2010 at 14:36:21 +0100, Kevin Chadwick ma1l1i...@yahoo.co.uk 
 wrote:
 What do people think of monit.

 Ok, I'll chime in: What do people think of Zenoss and splunk?

I haven't looked at splunk, but zenoss looks fiddly to install on OpenBSD,
they provide a mega-tarball including tar.gz of all dependencies which they
expect you to use. On OS which are fully-supported by the various projects
I see some benefit from this (though I think it's still a pain), it's
really annoying on OS where you really want to use packages for the
dependencies which are already tested and have had various portability
problems fixed. (freeswitch has a similar problem and this is one of
the main reasons why there is no freeswitch port; it's even worse for
zenoss as they repackage even more pointless stuff; python, rrdtool,
gettext, glib, pixman, ...).

I'm occasionally working on a port of icinga which looks quite
interesting (forked from nagios a while ago, it's still compatible
but has diverged quite a bit now - many problems have been fixed
and improvements made, in particular the UI has been totally
replaced). Would have been done sooner, but despite its
general crappiness and the many improvements that could be made,
nagios actually works surprisingly well...

OpenNMS also looks pretty interesting, but unless they've worked
around it by now, it doesn't work with snmpd(8) due to PR 6071.



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Jiri B.
On Sat, 14 Aug 2010 13:08:57 + (UTC)
Stuart Henderson s...@spacehopper.org wrote:

 I'm occasionally working on a port of icinga which looks quite
 interesting (forked from nagios a while ago, it's still compatible
 but has diverged quite a bit now - many problems have been fixed
 and improvements made, in particular the UI has been totally
 replaced). Would have been done sooner, but despite its
 general crappiness and the many improvements that could be made,
 nagios actually works surprisingly well...

There's another fork of Nagios - http://opsview.com/ - which looks they
gets huge list of enterprise users (just checking the web only).

jirib



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Eugene Yunak
On 15 August 2010 00:16, Jiri B. ji...@live.com wrote:
 On Sat, 14 Aug 2010 13:08:57 + (UTC)
 Stuart Henderson s...@spacehopper.org wrote:

 I'm occasionally working on a port of icinga which looks quite
 interesting (forked from nagios a while ago, it's still compatible
 but has diverged quite a bit now - many problems have been fixed
 and improvements made, in particular the UI has been totally
 replaced). Would have been done sooner, but despite its
 general crappiness and the many improvements that could be made,
 nagios actually works surprisingly well...

 There's another fork of Nagios - http://opsview.com/ - which looks they
 gets huge list of enterprise users (just checking the web only).

 jirib



Don't even bother to try - it's basically just a shitty web-frontend
for nagios. It does not sort any of it's problems, and brings new
ones. Did i mention it's shit and brings a lot of configuration and
performance pain?
Our monitoring solutions team wanted to switch to it from nagios
(after all the pain of going to nagios from BigBrother), thanks god
we've convinced them not to do that. But it does have nice support.

-- 
The best the little guy can do is what
the little guy does right



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread bofh
Friends who are using splunk strictly as a logger liked it.  We had
hell of a lot of pain implementing 4.0.  They don't understand the
concept of dropping privs, so it has to run as root.  My company does
not allow the non-os team to have root.  So endless fucking around
with permissions and hey unix team, can you please do this so that we
can continue troubleshooting.

And to top that, 4.0 through about 4.09 were feature *and* bug rich.

They have agents which have to be installed and upgraded manually each
time.  Few hundred servers and that starts to get a bit old.

And sux on aix (ok, that's our fault - the asshole who bought it
bought a p520 instead of a x86 box.  Before a solution/product was
even finalized).

And some kind of buffer overflow issue which I think is fixed now.

So, if you're looking for something to sit on 512 and other assorted
ports to receive logs, and index them, and give you a pretty interface
to do searches on non-normalized data on linux, splunk's pretty nice.

If you need to use some of their additional features (agents, etc)
test it out first before doing it.  Fortunately, you can get an annual
500meg/day license for free by just asking.


On 8/14/10, Toni Mueller openbsd-m...@oeko.net wrote:
 On Fri, 13.08.2010 at 14:36:21 +0100, Kevin Chadwick ma1l1i...@yahoo.co.uk
 wrote:
 What do people think of monit.

 Ok, I'll chime in: What do people think of Zenoss and splunk?

 I'm so far leaning twoards trying Zenoss, but it surely has a high
 barrier-of-entry, and I'm only interested in splunk for comparison.


 Kind regards,
 --Toni++



-- 
Sent from my mobile device

http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
This officer's men seem to follow him merely out of idle curiosity.
-- Sandhurst officer cadet evaluation.
Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted.  -- Gene Spafford
learn french:  http://www.youtube.com/watch?v=30v_g83VHK4



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Eugene Yunak
On 15 August 2010 01:06, Stuart Henderson s...@spacehopper.org wrote:
 On 2010/08/14 23:59, Eugene Yunak wrote:
 On 15 August 2010 00:16, Jiri B. ji...@live.com wrote:
  On Sat, 14 Aug 2010 13:08:57 + (UTC)
  Stuart Henderson s...@spacehopper.org wrote:
 
  I'm occasionally working on a port of icinga which looks quite
  interesting (forked from nagios a while ago, it's still compatible
  but has diverged quite a bit now - many problems have been fixed
  and improvements made, in particular the UI has been totally
  replaced). Would have been done sooner, but despite its
  general crappiness and the many improvements that could be made,
  nagios actually works surprisingly well...
 
  There's another fork of Nagios - http://opsview.com/ - which looks they
  gets huge list of enterprise users (just checking the web only).
 
  jirib
 
 

 Don't even bother to try - it's basically just a shitty web-frontend
 for nagios. It does not sort any of it's problems, and brings new
 ones. Did i mention it's shit and brings a lot of configuration and
 performance pain?

 heh, it wouldn't be the first time... icinga looks quite a different
 thing, they do actually appear to be improving things.


Sorry for the confusion, i was talking about opsview. As to icinga, i
haven;t tried it myself but heard some positive feedback from a
colleague of mine.

-- 
The best the little guy can do is what
the little guy does right



Re: which monitoring do you use (on OpenBSD)

2010-08-14 Thread Jason Dixon
On Wed, Aug 11, 2010 at 10:07:53PM +0200, Jiri B. wrote:
 On Tue, 10 Aug 2010 18:05:51 -0400
 Jason Dixon ja...@dixongroup.net wrote:
 
  http://omniti.com/video/noit-oscon-demo
 
 Sorry no flash :)
 
 Some screenshots should be sufficient for this products, interesting is
 there are no screenshots except that architecture picture.

Here's a quick one I just grabbed.  We don't actively use Reconnoiter
these days as much as we do Circonus.

http://www.flickr.com/photos/78527...@n00/4892326857/
 
 Does it have some event console? So an operator can watch it 24x7 and
 see if something goes wrong and do a repair action?

It has support for alerting in stratcon (iirc), but no fault detection
functionality is exposed in Reconnoiter's current web UI.
 
 It's nice it can act as snmp trap daemon... A lot of SAN devices have
 SNMP and Vmware ESXes can make good monitoring via SNMP as well.
 
 In our enterprise environment we have huge operators centers which
 watch 24x7 Tivoli Enteprise Console (yeah, ld shite), but what I
 saw is that one can right client on an event and run an action directly
 from event console (OK, it is not used at all but nice feature and you
 exclude possibility to fuck up something just with a similar but bad
 commmand).

P.S. Sorry for the slow response, been enjoying my vacation.  :)

-- 
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/



Re: which monitoring do you use (on OpenBSD)

2010-08-13 Thread Kevin Chadwick
What do people think of monit.



Re: which monitoring do you use (on OpenBSD)

2010-08-11 Thread Joachim Schipper
On Tue, Aug 10, 2010 at 07:00:37PM +0200, Martin Schrvder wrote:
 2010/8/10 Iqigo Ortiz de Urbina inigoortizdeurb...@gmail.com:
  Mainstream open source monitoring is pretty much about munin, cacti,
  nagios, zabbix. You can make any of these run on openbsd, AFAIK.
 
 A munin port would be highly appreciated. :-)

net/munin has been present since 4.7.

Joachim

-- 
TFMotD: ssm (4/SPARC64) - Scalable Shared Memory



Re: which monitoring do you use (on OpenBSD)

2010-08-11 Thread Jiri B.
On Tue, 10 Aug 2010 18:05:51 -0400
Jason Dixon ja...@dixongroup.net wrote:

 http://omniti.com/video/noit-oscon-demo

Sorry no flash :)

Some screenshots should be sufficient for this products, interesting is
there are no screenshots except that architecture picture.

Does it have some event console? So an operator can watch it 24x7 and
see if something goes wrong and do a repair action?

It's nice it can act as snmp trap daemon... A lot of SAN devices have
SNMP and Vmware ESXes can make good monitoring via SNMP as well.

In our enterprise environment we have huge operators centers which
watch 24x7 Tivoli Enteprise Console (yeah, ld shite), but what I
saw is that one can right client on an event and run an action directly
from event console (OK, it is not used at all but nice feature and you
exclude possibility to fuck up something just with a similar but bad
commmand).

jirib



Re: which monitoring do you use (on OpenBSD)

2010-08-11 Thread Brynet
Jiri B. wrote:
 Sorry no flash :)

Hello,

The follow was embedded on the page linked by jdixon, near the bottom
you'll find this:

http://s.omniti.net/video/noit-oscon-demo/flash/playlist.xml

The direct link is inside.

Without flash, manually forging for direct links is part of life..

-Bryan.



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Eugene Yunak
On 10 August 2010 02:28, Jiri B. ji...@live.com wrote:
 Hello,

 I'm thinking to choose a monitoring tool which would run on OpenBSD
 of course.

 I have been working with Tivoli and Netview for couple of years so my
 idea is:

 * clients

 - heartbeats of course
 - simple interface to give a client some input as alert
 - text configuration on client node (can be pushed from central repo)
 - light

 * infrastructure nodes

 - proxy feature for far networks or dmz
 - filtering rules (thresholds, time filters ...)
 - text configuration
 - light

 * main server(s)

 - good filtering
 - surveillance console for monitoring center
 - be able to change status of an alert (acknowledge, closed, solved...)
 - be able to have some categories of clients based on roles

 I'm watching zabbix... not sure...

 If I wouldn't want event console I would probably check snmp - sec -
 snmptt.

 jirib



Definitely nagios/cacti pair or zabbix. Having used nagios for a year
or so, i would never want to get back to Tivoli. It also gives you
lots of flexibility in how you setup your monitoring, and can neatly
work with snmp as well.

Eugene

-- 
The best the little guy can do is what
the little guy does right



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Iñigo Ortiz de Urbina
Mainstream open source monitoring is pretty much about munin, cacti,
nagios, zabbix. You can make any of these run on openbsd, AFAIK.

Even though they serve different purposes, my favourite (if no custom,
tailored solution is crafted) between these is cacti.

However, its pretty disappointing the lack of support for alternative
(see psql) backends :( /rant

On 8/10/10, Eugene Yunak e.yu...@gmail.com wrote:
 On 10 August 2010 02:28, Jiri B. ji...@live.com wrote:
 Hello,

 I'm thinking to choose a monitoring tool which would run on OpenBSD
 of course.

 I have been working with Tivoli and Netview for couple of years so my
 idea is:

 * clients

 - heartbeats of course
 - simple interface to give a client some input as alert
 - text configuration on client node (can be pushed from central repo)
 - light

 * infrastructure nodes

 - proxy feature for far networks or dmz
 - filtering rules (thresholds, time filters ...)
 - text configuration
 - light

 * main server(s)

 - good filtering
 - surveillance console for monitoring center
 - be able to change status of an alert (acknowledge, closed, solved...)
 - be able to have some categories of clients based on roles

 I'm watching zabbix... not sure...

 If I wouldn't want event console I would probably check snmp - sec -
 snmptt.

 jirib



 Definitely nagios/cacti pair or zabbix. Having used nagios for a year
 or so, i would never want to get back to Tivoli. It also gives you
 lots of flexibility in how you setup your monitoring, and can neatly
 work with snmp as well.

 Eugene

 --
 The best the little guy can do is what
 the little guy does right



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Henning Brauer
* Eugene Yunak e.yu...@gmail.com [2010-08-10 15:05]:
 Definitely nagios/cacti pair or zabbix. Having used nagios for a year
 or so, i would never want to get back to Tivoli. It also gives you
 lots of flexibility in how you setup your monitoring, and can neatly
 work with snmp as well.

anyone using nagios and neat in the same sentence without negation
must also enjoy beating his head against a wall.

nagios is shit. misdesigned, horrible code, and someone who obviously
doesn't understand blocking semantics of sockets writing that part of
the code...

that said, I use it, too. and as almost every other serious user with
at least a little bit of standards left I hate it.

the old, trivial, mon package we used before just didn't cut it any
more, had its own share of problems and wasn't fix- and extendable
with reasonable effort, and there were no other options but nagios
back then. and since it took us almost a year to switch over I am not
looking forward to do it again. I am not even sure there is anything
at least halfway good out there today.


-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Martin Schröder
2010/8/10 Iqigo Ortiz de Urbina inigoortizdeurb...@gmail.com:
 Mainstream open source monitoring is pretty much about munin, cacti,
 nagios, zabbix. You can make any of these run on openbsd, AFAIK.

A munin port would be highly appreciated. :-)

Best
   Martin



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread C. Bensend
 nagios is shit. misdesigned, horrible code, and someone who obviously
 doesn't understand blocking semantics of sockets writing that part of
 the code...

 that said, I use it, too. and as almost every other serious user with
 at least a little bit of standards left I hate it.

I cannot speak to the quality of code; I couldn't code my way out of
a wet paper bag and am horribly unqualified to comment.

However, this is a majority of my job where I am now, and I don't
dislike it.  It's infinitely extensible, makes it simple to write
plugins for stuff that you can't already find one for, and has a
fairly large community.

It's a *helluva* lot better than Mon or Big Brother, both of which
I've used in the past, and both of which made me weep tears of
blood.

Benny


-- 
Something's going on in this house - last night, I saw a face!
Did it have a nose?
Yes!
That sounds like a face all right.
  -- Scary Movie 4



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Jason Dixon
On Tue, Aug 10, 2010 at 12:41:26PM -0500, C. Bensend wrote:
  nagios is shit. misdesigned, horrible code, and someone who obviously
  doesn't understand blocking semantics of sockets writing that part of
  the code...
 
  that said, I use it, too. and as almost every other serious user with
  at least a little bit of standards left I hate it.
 
 I cannot speak to the quality of code; I couldn't code my way out of
 a wet paper bag and am horribly unqualified to comment.

Henning is completely accurate (*).  Nagios code is shite and reflects
poorly on the engineering skills of the creator.  Its near-monopoly
position in the community is based on two factors:

1) Price.  Although you pay dearly in time spent setting it up,
maintaining it, and in outages caused by it (keep reading).

2) It's the least crappy of all crappy open-source monitoring options.
 
 However, this is a majority of my job where I am now, and I don't
 dislike it.  It's infinitely extensible, makes it simple to write
 plugins for stuff that you can't already find one for, and has a
 fairly large community.

We used it for a very long time on a very large scale.  While it is
extensible, it promotes poor design choices and puts no limitations on
the style or number of shite extensions.  But my biggest beef is on some
of the design choices that allow you to shoot yourself in the foot.  As
my therapist would say, Nagios is an enabler.

Take for example, Nagios acknowledgments.  They never expire, so it's
very easy to ack something and forget about it.  For days.  Or better
yet, the idea of flapping.  At face value, this seems like a good
idea.  But whatever happened to actually *responding* to an alert when
something goes wrong.  Let me get this straight... you WANT your
monitoring system to stop alerting you when your shit goes down?  What
am I missing here?

 It's a *helluva* lot better than Mon or Big Brother, both of which
 I've used in the past, and both of which made me weep tears of
 blood.

See above.

(*) I should disclose that I'm the Prod. Mgr. for Circonus, a SaaS
version of Reconnoiter with trending, fault detection and notifications.
Circonus is not free, but is based on Reconnoiter which is actively
developed as an open-source BSD-licensed project.  Both were engineered
to directly address the pain we've experienced over the years working
with solutions like Nagios and Cacti.  So although it's fair to
consider me biased towards our software, suffice it to say that if
Nagios didn't suck so badly we never would have developed either
Reconnoiter or Circonus.  There are some OpenBSD-Reconnoiter users in
the community;  if you're interested in finding out more about
Reconnoiter, ask around or check out the project website.

http://labs.omniti.com/labs/reconnoiter

-- 
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread James Peltier
- Original Message 

 From: Jason Dixon ja...@dixongroup.net
 To: C. Bensend be...@bennyvision.com
 Cc: misc@openbsd.org
 Sent: Tue, August 10, 2010 12:58:50 PM
 Subject: Re: which monitoring do you use (on OpenBSD)
 
 On Tue, Aug 10, 2010 at 12:41:26PM -0500, C. Bensend wrote:
   nagios  is shit. misdesigned, horrible code, and someone who obviously
doesn't understand blocking semantics of sockets writing that part of
the code...
  
   that said, I use it, too. and as  almost every other serious user with
   at least a little bit of  standards left I hate it.
  
  I cannot speak to the quality of  code; I couldn't code my way out of
  a wet paper bag and am horribly  unqualified to comment.
 
 Henning is completely accurate (*).  Nagios  code is shite and reflects
 poorly on the engineering skills of the  creator.  Its near-monopoly
 position in the community is based on two  factors:
 
 1) Price.  Although you pay dearly in time spent setting it  up,
 maintaining it, and in outages caused by it (keep reading).
 
 2)  It's the least crappy of all crappy open-source monitoring options.
 
   However, this is a majority of my job where I am now, and I don't
   dislike it.  It's infinitely extensible, makes it simple to write
   plugins for stuff that you can't already find one for, and has a
  fairly  large community.
 
 We used it for a very long time on a very large  scale.  While it is
 extensible, it promotes poor design choices and puts  no limitations on
 the style or number of shite extensions.  But my  biggest beef is on some
 of the design choices that allow you to shoot  yourself in the foot.  As
 my therapist would say, Nagios is an  enabler.
 
 Take for example, Nagios acknowledgments.  They never  expire, so it's
 very easy to ack something and forget about it.  For  days.  Or better
 yet, the idea of flapping.  At face value, this  seems like a good
 idea.  But whatever happened to actually *responding*  to an alert when
 something goes wrong.  Let me get this straight... you  WANT your
 monitoring system to stop alerting you when your shit goes  down?  What
 am I missing here?
 
  It's a *helluva* lot better  than Mon or Big Brother, both of which
  I've used in the past, and both  of which made me weep tears of
  blood.
 
 See above.
 
 (*) I  should disclose that I'm the Prod. Mgr. for Circonus, a SaaS
 version of  Reconnoiter with trending, fault detection and notifications.
 Circonus is not  free, but is based on Reconnoiter which is actively
 developed as an  open-source BSD-licensed project.  Both were engineered
 to directly  address the pain we've experienced over the years working
 with solutions  like Nagios and Cacti.  So although it's fair to
 consider me biased  towards our software, suffice it to say that if
 Nagios didn't suck so badly  we never would have developed either
 Reconnoiter or Circonus.  There are  some OpenBSD-Reconnoiter users in
 the community;  if you're interested  in finding out more about
 Reconnoiter, ask around or check out the project  website.
 
 http://labs.omniti.com/labs/reconnoiter
 
 -- 
 Jason  Dixon
 DixonGroup Consulting
 http://www.dixongroup.net/


Being as I have never used Reconnoiter or Circonus, would you care to elaborate 
as to where these products suck less then Nagios or other solutions?  I am 
looking into replacing out very aged monitoring system now and Nagios is the 
one 
that seems to stand out the most, although Zabbix and Munin look good in their 
own rights.

Guidance is always appreciated. :)



Re: which monitoring do you use (on OpenBSD)

2010-08-10 Thread Jason Dixon
On Tue, Aug 10, 2010 at 01:11:41PM -0700, James Peltier wrote:
 
 Being as I have never used Reconnoiter or Circonus, would you care to 
 elaborate 
 as to where these products suck less then Nagios or other solutions?  I am 
 looking into replacing out very aged monitoring system now and Nagios is the 
 one 
 that seems to stand out the most, although Zabbix and Munin look good in 
 their 
 own rights.

Theo Schlossnagle (our CEO and the architect of Reconnoiter) answers it
pretty well in his talk from OSCON (requires flash, sorry).

http://omniti.com/video/noit-oscon-demo
 
In my words, Reconnoiter was designed to overcome a lot of the
performance and design problems native in Nagios and Cacti.  It does a
lot of the things that either of those do, although it was designed
foremost as a highly scalable metrics collection engine.  Like Nagios,
the types of checks it can perform is virtually limitless.  Unlike
Nagios, it is highly performant by design.  Checks are deployed across
scout agents in your network, giving you both perspective and
non-persective collection points.

The web UI in Reconnoiter is adequate.  One of its really nice features
is the cli console, allowing you to configure checks and metrics in an
environment familiar to Cisco admins.  That said, the bread-and-butter
in Reconnoiter is the sort of graphs which you can create and recreate
with ease.  Unlike trending tools like Cacti, you can easily correlate
dissimilar metrics in a single graph, with just a few clicks.  Stack
sets, composite datapoints and RPN conversion of source and display
values are just a few of the other features that are easy to implement
within Reconnoiter.

 Guidance is always appreciated. :)

Reconnoiter is not for everyone.  It's a very powerful system, but it's
not intended to be a drop-in replacement for other ECA/Trending systems.
It takes time and effort to get value out of it, but it offers some
Capacity Planning and Root Cause Analysis capabilities that aren't
available or usable in the alternatives.

-- 
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/



which monitoring do you use (on OpenBSD)

2010-08-09 Thread Jiri B.
Hello,

I'm thinking to choose a monitoring tool which would run on OpenBSD
of course.

I have been working with Tivoli and Netview for couple of years so my
idea is:

* clients

- heartbeats of course
- simple interface to give a client some input as alert
- text configuration on client node (can be pushed from central repo)
- light

* infrastructure nodes

- proxy feature for far networks or dmz
- filtering rules (thresholds, time filters ...)
- text configuration
- light

* main server(s)

- good filtering
- surveillance console for monitoring center
- be able to change status of an alert (acknowledge, closed, solved...)
- be able to have some categories of clients based on roles

I'm watching zabbix... not sure...

If I wouldn't want event console I would probably check snmp - sec -
snmptt.

jirib



Re: which monitoring do you use (on OpenBSD)

2010-08-09 Thread Robert
On Tue, 10 Aug 2010 01:28:09 +0200
Jiri B. ji...@live.com wrote:
 I'm thinking to choose a monitoring tool which would run on OpenBSD
 of course.

*) Nagios to monitor for problems
*) Cacti for performance logs

Nfsen, smokeping and pfstat are also handy sometimes.

Don't expect exact Tivoli/Netview clones; it's just important that you
get the required *information* from your tools, not the same
interface...

regards,
Robert