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 the corresponding
datacenter.
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.
Is there anybody having an idea about this. I’m a little bit scared and hope
that the growth will stop some time.
Kind regards,
Marco
Am 20.03.2014 um 10:18 schrieb Serge Noiraud <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
> 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
