[dev.icinga.com #892] add multiple data sources

[icinga-migration]

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

Created by mfriedrich on 2010-10-14 07:54:10 +00:00

Assignee: jmosshammer
Status: Closed (closed on 2013-09-02 12:09:06 +00:00)
Target Version: (none)
Last Update: 2013-09-02 12:09:06 +00:00 (in Redmine)

---

http://feedback.icinga.org/forums/50329-general/suggestions/1120487-icinga-web-with-multiple-data-sources?ref=title

icinga-web should handle more than one datasources, so you can have autonomic icinga installations and one webinterface for an overlook over them all.

pls keep that in mind when integrating phpapi as webapi with doctrine.

Attachments

• icinga_web_multiple_backends_grid_dropdown.png mfriedrich - 2012-04-30 18:11:33 +00:00

---

Relations:

• relates #892
• relates #3392

[icinga-migration]

Updated by jmosshammer on 2011-09-13 12:06:22 +00:00

• Done % changed from 0 to 50

The backend already supports this since 1.5, but the frontend doesn't

[icinga-migration]

Updated by jmosshammer on 2011-09-26 15:35:46 +00:00

• Target Version set to 1.7

Front end support must be evaluated for 1.7

[icinga-migration]

Updated by mhein on 2012-01-19 17:10:16 +00:00

• Target Version deleted 1.7

[icinga-migration]

Updated by mfriedrich on 2012-03-15 22:30:48 +00:00

• Target Version set to 1.7

is it possible to raise severity and focus on that feature?

in the recent time i got ~5 users asking about DMZ hosts with their own icinga+ido+db as well as web. but their webs should share multiple database backends from the other nodes as well.

it would be great to integrate that in the existing web, as it now shows exactly the different instances.

[icinga-migration]

Updated by jhoblitt on 2012-03-15 22:42:48 +00:00

I may be user ~6. I have sites in opposite hemispheres that occasionally have poor connectivity between them. I have two completely separate icinga instances (which both send alerts locally), however I have a desire for a single dashboard that shows the state of both sites. I could do nsca without notifications between the sites but that seems painful to maintain. ido replication has been suggested but I think this would also be painful considering the network issues. -web being able to pull multiple ido backends and aggregating them into a single via ala thruk or multisite would be great.

[icinga-migration]

Updated by jmosshammer on 2012-03-16 09:35:12 +00:00

• Done % changed from 50 to 90

This is possible in my templateDQL branch, see https://wiki.icinga.org/display/Dev/Using+templates+to+write+your+own+grid+based+views#Usingtemplatestowriteyourowngridbasedviews-3Usingdatafromexternaldatabases where I include data completely unrelated to icinga.

But to be easier to use, I'm going to add a 'connection' tag to the templates so one can easily bind templates to different databases without having to create duplicated views.

[icinga-migration]

Updated by jmosshammer on 2012-04-02 15:40:54 +00:00

• Target Version changed from 1.7 to 1.8

At this time, if more than one connection is present, you have a drop down box in your grids to select the corresponding database.
This is a little bit basic at this time, but changing tactical overview, etc. would require extensive UI changes, so i'm going to postpone that to 1.8

[icinga-migration]

Updated by mfriedrich on 2012-04-02 15:44:35 +00:00

so this means this is somewhere ready to be tested for those actually waiting for it?

[icinga-migration]

Updated by mfriedrich on 2012-04-30 18:11:34 +00:00

• File added icinga_web_multiple_backends_grid_dropdown.png

        pgsql://icinga:icinga@localhost:5432/icinga
        icinga_
        utf8
        true
        YYYY-MM-DD HH24:MI:SS
        
            CONSERVATIVE
        
        %core.module_dir%/Api/lib/database/models/generated
        %core.module_dir%/Api/lib/database/models                          
          
            false
            apc
            true
        
  
    
  
    
        mysql://icinga:icinga@localhost:3306/icinga
        icinga_
        utf8
        true
        YYYY-MM-DD HH24:MI:SS
        
            CONSERVATIVE
        
        %core.module_dir%/Api/lib/database/models/generated
        %core.module_dir%/Api/lib/database/models                          
          
            false
            apc
            true
  

after that you will get the dropdown box on the grids, yes, based on the name attribute in the xml settings.

[icinga-migration]

Updated by mfriedrich on 2012-09-03 18:04:38 +00:00

what's the status of this? possible or should we reschedule it?

[icinga-migration]

Updated by jmosshammer on 2012-09-03 19:29:27 +00:00

• Target Version changed from 1.8 to 1.9

Reschedule, we need to discuss how to make the UI ready for multiple databases - the backend supports multiple databases yet.

[icinga-migration]

Updated by mfriedrich on 2012-10-24 17:01:35 +00:00

• Target Version changed from 1.9 to 1.10

we should discuss that even more, as the known model of "instances" will change in icinga2, so actually we need to add a different backend (e.g. icinga2 api), but also diverge from the "single instance" logic.

more input required.

[icinga-migration]

Updated by dmikulski on 2012-11-18 07:38:07 +00:00

Hello all,

We're currently evaluating icinga and icinga-web with different addons like inGraph, eventdb, lconf and so on. All we can say after we've tested icinga with icinga-web and it's possibilities you did a really impressive job.

We have multiple datacenters and want to use one or more icinga instances on each where data partially will be written by an icinga instance over ido into a dedicated database and partially by icinga instances into a shared database for multiple instances.
We have a central servicedesk where it is absolutely required to have an overview over all the states of these instances and their hosts and services.
It would be great if an operator would have the option to choose one instance instead of "all instances" on the top after which all (maybe newly or re~~) opened cronks would only show those data including the status cronk at the top (instances for already opened cronks maybe could be changed individually as it currently is or change with the general "choose instance" dropdown~~ maybe user-configuration relevant).
On the other side there maybe will be customers where it should be the option to define which host/service from which instance may be seen by this customer/user.

Best Regards

[icinga-migration]

Updated by mfriedrich on 2012-11-21 13:25:57 +00:00

your request is different from what this feature request is speaking of.

your central database with multiple idoutils writing into it, seperated by instance_id plus put upon icinga web is already working with multiple instances to be filtered and shown within the web grid views.

you can even created custom cronks where only a single instance is being filtered, and share them amongst those users only needing to see their instance. furthermore, you can enable that column "instance" in the cronk grid in order to see which host/service is attached to which instance.

so basically put, you already got everything in place.

this feature request demands the capabilities of adding multiple datasources (such as multiple databases) into icinga web, and is therefore rather special, as the common setup is likely one shared database for all instances, with one icinga web on top.

[icinga-migration]

Updated by dmikulski on 2012-12-10 14:13:04 +00:00

Thanks for your response. This is exactly what I'm talking about. We will have multiple instances in one database and know that there are these possibilities as you described.
The thing is that we have a customer which will get an own icinga instance writing in his own database. Our company will only do the monitoring for his services and open tickets toward the suppliers after first analysis.
We tested the possibility of multiple datasources and included a additional datasource to our default datasource in databases.xml and figured out that there are only status shown for the main instance on top of icinga-web (in the overall status frame), and not those for all instances alltogether.
Solving this would lead to another problem. Our network team will use icinga for monitoring, too, but they're not interested in monitoring the systems and services coming out of the customers dedicated icinga-database.
There is an option needed to restrict users/groups to view those sources, isn't it?

[icinga-migration]

Updated by mfrosch on 2013-09-02 12:09:06 +00:00

• Status changed from Assigned to Closed
• Target Version deleted 1.10