Hi Michael,

after some research I found out that the mysql-node (yes, active-active 
cluster) had a problem with bin-log cleanup.
This caused us to believe that this was caused by icinga update, since the disk 
usage growed short after the update.
In short, no problem at icinga, false alert. I will try to give some more 
details next time.

Greets
Marco

Am 20.03.2014 um 20:40 schrieb Michael Friedrich <michael.friedr...@gmail.com>:

> 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 massively increased amount of db changes,
> 
> That means in terms of
> 
> - query count
> - logs
> - load
> - top queries
> 
> ?
> 
>> blowing up the bin-log of our mysql instance.
> 
> Some details?
> 
>> The database itself has a size of 4,3GB, which increased a bit since the 
>> update.
> 
> 1.11 adds additional columns required for Icinga 2 schema extensions, but 
> they are all set to NULL by default.
> 
>> We have something like 1k hosts with 18k services in the corresponding 
>> datacenter.
> 
> Which MySQL version is involved, which distribution, and is that presumingly 
> an active/passive cluster?
> 
>> Looking at the mysql schema-update file shipped with latest update, there 
>> were some new columns and two tables. I’m not sure if this behavior is 
>> caused by that.
> 
> commenthistory got a missing index which will increase performance during 
> reload when updating commenthistory.
> 
>> Is there anybody having an idea about this. I’m a little bit scared and hope 
>> that the growth will stop some time.
> 
> Given that there were no essential changes in IDOUtils with 1.11 (except the 
> config_dump_in_progress), no. But you're leaving plenty of details to 
> reader's imagination, so please share them.
> 
> kind regards,
> Michael
> 
>> 
>> Kind regards,
>> Marco
>> 
>> Am 20.03.2014 um 10:18 schrieb Serge Noiraud <serge.noir...@bull.net 
>> <mailto:serge.noir...@bull.net>>:
>> 
>>> Le 19/03/2014 20:05, Michael Friedrich a écrit :
>>>> On 13.03.2014 11:48, Serge Noiraud wrote:
>>>>> Le 13/03/2014 09:42, Michael Friedrich a écrit :
>>>>>> On 12.03.2014 09:36, Serge Noiraud wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I found something strange.
>>>>>>> 
>>>>>>> I have four services in passive mode. Nothing will change their states.
>>>>>>> The only way to test them was to force one reschedule.
>>>>>>> It doesn't work anymore.
>>>>>> 
>>>>>> Logs? Configs? Exact versions?
>>>>> versions :
>>>>> the old was 1.8.4
>>>>> the new one : 1.10.3
>>>>> 
>>>>> My icinga config :
>>>>> 
>>>>> The only parameter which is different between the two configs is 
>>>>> passive_host_checks_are_soft : 0 in 1.8 and 0 in 1.10
>>>> 
>>>> I'm also interested in the service object config extracted from 
>>>> objects.cache
>>>> 
>>>> 'passive_host_checks_are_soft' seems not to be different, but since that 
>>>> affects hosts only, it shouldn't matter.
>>> This was an error in the mail : 0 in 1.8 and 1 in 1.10
>>>> 
>>>>> 
>>>>> From the icinga page, I click on "select command" then "Re-schedule Next 
>>>>> Service check" then submit.
>>>>> I continue with force check and commit.
>>>>> Nothing in the LOGs and nothing appends.
>>>> 
>>>> Debug log with events/checks/commands tells what?
>>> The only thing I see with debug=-1 and verbosity=2 is :
>>> 
>>> [1395304966.842148] [008.2] [pid=2224] Service 'Verify_appli1' on host 
>>> 'int:srv:icinga'
>>> [1395304966.842152] [008.2] [pid=2224] Service check should not be 
>>> scheduled.
>>> 
>>> The service is configured :
>>> define service{
>>> service_description Verify_appli1
>>> host_name int:srv:icinga
>>> check_command check_appels!nombre
>>> is_volatile 1
>>> normal_check_interval 600000 ; 416 days. This is to avoid the pb for 
>>> passive rescheduling check
>>> retry_check_interval 1440 ; once a day
>>> max_check_attempts 1
>>> active_checks_enabled 0
>>> check_period workhours
>>> notification_interval 0
>>> notification_period workhours
>>> notification_options c
>>> notifications_enabled 1
>>> flap_detection_enabled 0
>>> }
>>> 
>>> For info , we use that possibility for resetting the error on some 
>>> services. Rescheduling the passive service use in this case a check_dummy!0 
>>> command.
>>> 
>>>> 
>>>> PS: Please use "reply to list" in your preferred mail client, not "reply 
>>>> to all".
>>> OK. I used to do that on other lists. So I did the same here.
>>> 
>>>> 
>>>>> 
>>>>> I found a workaround, but it's not very user's friendly
>>>>> I must "enable active check of checked service(s)" then do the 
>>>>> "re-schedule next service check" then "disable active check of checked 
>>>>> service(s)"
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Is it a new bug or some volontary change?
>>>>>> 
>>>>>> Dunno. Which external command is used?
>>>>>> 
>>>>>>> 
>>>>>>> I don't want to set them active because I have no periodicity on this
>>>>>>> services : it can be one day or three weeks.
>>>>>>> If it can't be possible anymore, can we set those service in active mode
>>>>>>> without automatic check ?
>>>>>>> 
>>>>>>> Serge
>>> 
>>> 
>>> --
>>> Serge Noiraud
>>> Les logiciels libre, c'est mieux : Debian, Firefox, LibreOffice, ...
>>> Tout ce qui n'est pas gratuit ou libre sera perdu définitivement.
>>> 
>>> Développeur projet gramps :http://gramps-project.org/et osm-gps-map 
>>> :http://nzjrs.github.com/osm-gps-map
>>> _______________________________________________
>>> icinga-users mailing list
>>> icinga-users@lists.icinga.org <mailto:icinga-users@lists.icinga.org>
>>> https://lists.icinga.org/mailman/listinfo/icinga-users
>> 
>> 
>> 
>> _______________________________________________
>> icinga-users mailing list
>> icinga-users@lists.icinga.org
>> https://lists.icinga.org/mailman/listinfo/icinga-users
> 
> 
> -- 
> DI (FH) Michael Friedrich
> 
> michael.friedr...@gmail.com  || icinga open source monitoring
> https://twitter.com/dnsmichi || lead core developer
> dnsmi...@jabber.ccc.de       || https://www.icinga.org/team
> irc.freenode.net/icinga      || dnsmichi
> 
> _______________________________________________
> icinga-users mailing list
> icinga-users@lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users

_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Reply via email to