[dev.icinga.com #378] collect re-design ideas for core

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/378

Created by mfriedrich on 2010-04-24 20:06:10 +00:00

Assignee: (none)
Status: Closed (closed on 2010-11-09 16:21:12 +00:00)
Target Version: (none)
Last Update: 2010-11-09 16:21:12 +00:00 (in Redmine)

---

started the discussion on the mailinglists, now it is time to collect ideas and implementation proposals.

http://sourceforge.net/mailarchive/forum.php?thread\_name=4BD1A744.2000500%40univie.ac.at&forum\_name=icinga-devel

---

Relations:

• relates #378

[icinga-migration]

Updated by mfriedrich on 2010-05-18 06:32:36 +00:00

[13:14:15]  zeromq.org
[13:14:36]  may be we can discuss if we can use it on the new core
[13:15:10]  may be for messages between the micro kernel (C) and the modules (python) :)

[icinga-migration]

Updated by mfriedrich on 2010-05-19 21:43:32 +00:00

Some Quotations from the Mailinglists, collected altogether:

• Configuration

-------- Original Message --------
Subject:    Re: [Icinga-users] Thanks for the fork! Good luck.
Date:   Fri, 15 May 2009 17:26:53 -0400
From:   Paul M. Dubuc 
Reply-To:   icinga-users@lists.sourceforge.net
To:     icinga-users@lists.sourceforge.net


Max wrote:
> On Fri, May 15, 2009 at 3:03 PM, Chuck Bredestege  wrote:
>> Perhaps something that everyone might appreciate is an option for XML
>> object deffinitions
> 
> Maybe JSON?  Config language is already very close to JSON.
> 
> http://www.yannj.fr/nagios2json
> 
> Yann made a very good start on this with the external JSON interface,
> he also at one point had converted (Nagios 2 I think) to use JSON for
> retention.dat and objects.cache.
> 
> JSON everywhere would be a very good fit as there are lots of
> libraries to parse and generate it.

... or YAML? http://www.yaml.org/

-------- Original Message --------
Subject:    [Icinga-users] Thanks for the fork! Good luck.
Date:   Thu, 14 May 2009 00:06:49 -0700
From:   Jesse Molina 
Reply-To:   icinga-users@lists.sourceforge.net
To:     icinga-users@lists.sourceforge.net


Nagios is just not scalable to mid to large size organizations (>40 
hosts).  I can't afford putting >30% of my time into configuring and 
maintaining Nagios -- I have systems/networks to manage.

Development has been very slow.  There has been very little feature 
advancement, improvements in ease-of-use, functionality, and reliability 
over the years.  It's clear that something has been holding this very 
important project back, and I don't think it's lack of interest.

Limited (almost none) ability to manage the system through the web UI. 
While I would not want to depend entirely upon a web UI, it is 
frustrating to be able to put a host into scheduled downtime, and also 
NOT be able to cancel that scheduled downtime.  The UI, in general, 
could use some improvement.  I have many junior sysadmins that need to 
be able to put systems into maintenance time and otherwise do some basic 
twiddling of their individual hosts.  It would be great if they could do 
that through the web UI better than what is already possible.

Configuration via text files is extremely complicated due to the 
inter-relationship between areas of configuration.  It screams the need 
for a relational database, but the primary Nagios developer has shunned 
the use of a database for configuration, citing "ease of use" of 
configuration files.  I strongly disagree with that assertion.

Nagios has been plagued with a variety of "stupid" bugs, such as 
white-space prepending hash(#) comments causing configuration errors, 
random crashes, poor handling of the PID file via the startup script, 
failure to use DNS, and blatant logic errors causing false-positive 
notifications and false-negatives.  Many of these specific items have 
been fixed over time, but they should have never existed in the first place.

Nagios monitoring clients, such as NRPE, NRPE_NT, NSClient, and 
NSClient++, generally "suck".  There have been many different iterations 
by different authors because each client tends to leave much wanted in 
terms of features and functionality.  Their configuration is difficult, 
clients can't use DNS lookups for their configuration, plugin modules 
are unreliable, the clients have had a history of crashing or causing 
unreasonable host load, and a variety of other issues.  To this day, I 
am under the impression that the NSClient++ configuration file can't use 
DNS in it's settings file (example: allowed_hosts).  I realize that 
NSClient++ isn't a part of the larger Nagios project, but pretending 
that Windows servers don't exist isn't acceptable in the real world work 
environment.  It's VITAL to monitoring services.


-------- Original Message --------
Subject:    Re: [Icinga-users] Thanks for the fork! Good luck.
Date:   Thu, 14 May 2009 14:10:30 -0400
From:   Chuck Bredestege 
Reply-To:   icinga-users@lists.sourceforge.net
To:     icinga-users@lists.sourceforge.net


I didn't make any changes to the code itself - and we're also not recording historical data.

the broker filter we're using is event_broker_options=203585 which breaks down to 1 4096 64 256 512 2048 65536 131072

I've added indexes to many of the tables, some foreign relations,  I added many stored functions to make querying much easier.  such as 'host2objectid' which returns the object id of a given hostname, and 'object_name1' which pulls the name1 field of an object ID.  That is only to name a few.  I added another table for some data that is only mentioned in the documentation.  Keep in mind that my table modications are still a work in progress.


DROP TABLE IF EXISTS nagios_objecttypes;
CREATE TABLE `nagios_objecttypes` (
  `object_typeid` SMALLINT NOT NULL ,
  `object_typename` VARCHAR( 32 ) NOT NULL ,
  PRIMARY KEY ( `object_typeid` )
  ) ENGINE = innodb;

INSERT INTO nagios_objecttypes (`object_typeid`,`object_typename`)
VALUES
  (1, 'Host'),
  (2, 'Service'),
  (3, 'Host group'),
  (4, 'Service group'),
  (5, 'Host Escalation'),
  (6, 'Service Escalation'),
  (7, 'Host dependency'),
  (8, 'Service dependency'),
  (9, 'Timeperiod'),
  (10, 'Contact'),
  (11, 'Contact group'),
  (12, 'Command');

-------- Original Message --------
Subject:    Re: [Icinga-users] Thanks for the fork! Good luck.
Date:   Tue, 19 May 2009 12:19:30 +0100
From:   Chris Cowley 
Reply-To:   icinga-users@lists.sourceforge.net
To:     


One thing I would love to see as a base feature would be for reminders
to be sent out periodically about acknowledged problems. It is easy to
forget about a server running out of disk space for example.

-------- Original Message --------
Subject:    [icinga-users] What will be the baseline integrations planned for Icinga?
Date:   Mon, 25 May 2009 23:05:24 +0800
From:   Chua, Choon Hian 
Reply-To:   icinga-users@lists.sourceforge.net
To:     icinga-users@lists.sourceforge.net


Will good stuff like Simple Event Correlator be part of it?
Will standard agents with centralize threshold configuration but passive monitoring be part of it?

-------- Original Message --------
Subject:    [icinga-users] [Feature request/proposal] Hiding (host|service)groups in Web interface
Date:   Thu, 27 Aug 2009 14:23:39 +0400
From:   Aleksei Miheev 
Reply-To:   icinga-users@lists.sourceforge.net
To:     icinga-users@lists.sourceforge.net


Hello!

I've been using nagios for monitoring a small ISP/HSP network for few
years. Now I'm considering switching to icinga and wondering if anyone
but me needs this feature. Let me explain briefly.

I have about 30 hostgroups now and looks like I need about 20-30 more.
Some of them are "organizational" and group hosts by their role,
location, people responsible for, etc. And some are used only to
bulk-attach services to hosts. 

This results in unusably long Hostgroup Overview/Hostgroup Grid pages,
so I would like to be able to hide some groups from this output. I see
that as setting some parameter in group config:

hostgroup hostgroup{
    hostgroup_name  8-core-servers
    members     john,paul,george,ringo
    display     no
    }

I'm going to try to implement it myself anyway, but I want to ask if
anybody needs this, too, or probably something more than this, and if
there are any comments/recommendations from anyone.

[icinga-migration]

Updated by Meier on 2010-07-05 08:54:01 +00:00

Imlicit servicegroups: automatically create a servicegroup for each service description

more Abstractation for executions, the code in base/checks.c is way too long/spaghetti

[icinga-migration]

Updated by mfriedrich on 2010-11-09 16:21:12 +00:00

• Status changed from New to Closed