Hi Florian,
we’re using a similar setup. There are f.e. four Icinga instances with their
own ido2db daemon running. In ido2db.cfg each of them is configured with its
own instance name. This results in the status data getting written in context
of the instance, preventing collisions. These four
this, hopefully released soon.
Kind regards,
Marco Hoyer
> Am 05.02.2014 um 18:20 schrieb "Brian O'Neill" :
>
> Bumping in case this got missed on the weekend. Appreciate any pointers to
> what I need to do where...
>
>
>> On 1/31/2014 10:31 AM, Brian O
will try to give some more
details next time.
Greets
Marco
Am 20.03.2014 um 20:40 schrieb Michael Friedrich :
> On 20.03.2014 11:41, Marco Hoyer wrote:
>> Hello all,
>>
>> we recently updated icinga to 1.11.0
>
> How?
>
>> and since then I face a mass
Sorry. My fault.
Am 20.03.2014 um 17:52 schrieb Wolfgang :
> Please create a new thread instead of hijacking an old one.
>
> Am 20.03.2014 11:41, schrieb Marco Hoyer:
>> Hello all,
>>
>> we recently updated icinga to 1.11.0 and since then I face a massively
>&g
Hello all,
we recently updated icinga to 1.11.0 and since then I face a massively
increased amount of db changes, blowing up the bin-log of our mysql instance.
The database itself has a size of 4,3GB, which increased a bit since the
update. We have something like 1k hosts with 18k services in th
Hello all,
while trying to install icingaweb2 rpm from
http://packages.icinga.org/epel/6/snapshot/noarch/, yum fails on resolving a
dependency to icingaweb2-doc rpm. I can’t find this package anywhere in
packages.icinga.org. Any idea about it?
[root@sandbox ~]# repoquery -qR icingaweb2
Name
I thought about the way having local ido2db instances on every icinga host
being more robust against outages of single components. I haven’t tested a
setup with single ido2db instance but I would say that both approaches are
possible. The key aspect is setting a unique instance name in idomod.cf
Hi Florian,
we’re using a similar setup. There are f.e. four Icinga instances with their
own ido2db daemon running. In ido2db.cfg each of them is configured with its
own instance name. This results in the status data getting written in context
of the instance, preventing collisions. These four
this, hopefully released soon.
Kind regards,
Marco Hoyer
Gesendet: Mittwoch, 05. Februar 2014 um 21:31 Uhr
Von: "Jannis Moßhammer"
An: "Icinga User's Corner"
Betreff: Re: [icinga-users] Using a customvar within icinga-web cronks XML
Hey,
The problem is that CVs
Hi Michael,
I also tried Icinga 2 and am actually building a rpm for icinga web 2. This is
absolutely amazing stuff. I’m really glad that Icinga will cut off some old
stuff for focus on new, cool things like nice clustering features. The new
Webinterface looked really great on presentation at t
transport commands from remote icinga-web instances to
multiple icinga instances (much better than SSH in our environment).
If you are interested:
http://mathias-kettner.de/checkmk_livestatus.html
https://github.com/ImmobilienScout24/livestatus_service
https://github.com/marco-hoyer/icinga-web-module
interested:
http://mathias-kettner.de/checkmk_livestatus.html
https://github.com/ImmobilienScout24/livestatus_service
https://github.com/marco-hoyer/icinga-web-module-http-console-connection
Kind regards,
Marco
Am 20.01.2014 um 11:55 schrieb Ferenc Stelcz
mailto:ferenc.ste...@gmail.com>>:
Hi
12 matches
Mail list logo