Macro values don't seem to be consistent
Claudio Kuenzler
ck at claudiokuenzler.com
Tue Jul 19 17:05:40 CEST 2011
A manual correction in retention.dat didn't work - from somewhere the wrong
alias entries came back. I still don't know from where though.
After deleting the retention.dat file and restarting Nagios, the correct
alias values were shown and now the notifications of the affected servers
are correct again. This is a dirty workaround though, as Nagios needs to
recheck every server and services and looses scheduled host downtimes,
acknowledged states, etc.
It would be great if someone knew from where exactly the alias values came
back into the retention.dat file. It can't be the host definition and
neither objects.cache (as you can see in previous mails).
On Tue, Jul 19, 2011 at 2:07 PM, Claudio Kuenzler <ck at claudiokuenzler.com>wrote:
> To follow up on this, I have once more this problem (this time with another
> server though) and I activated debugging and started to do some deeper
> research.
>
> This time the service 'Disk Space /' on *SERVER21* is in state warning.
> The host alias for SERVER21 is SERVER21-DEVL.
> The notification looks like this though:
>
> *Service: Disk Space /*
> * *
>
> *Host: SERVER31-UAT*
> * *
>
> *Address: 10.x.x.x*
> * *
>
> *State: WARNING*
>
> As you see, the alias for SERVER31 was taken, instead of SERVER21.
>
>
> Now if I take a look at *var/objects.cache* the correct alias is used:
>
> define host {
> host_name SERVER21
> alias SERVER21-DEVL
>
>
> If I take a look at *var/retention.dat* I see something strange:
>
> host {
> host_name=SERVER21
> alias=SERVER31-UAT
> display_name=SERVER21
> Taking a further look at retention.dat reveils, that another host took the
> alias for SERVER31-UAT:
>
> host {
> host_name=SERVER33
> alias=SERVER31-UAT
> display_name=SERVER33
>
>
> I am sure the problem comes from here (retention.dat). But can somebody
> explain, how such wrong entries are created in retention.dat ?
>
>
>
> On Mon, Jul 11, 2011 at 5:14 PM, Claudio Kuenzler <ck at claudiokuenzler.com>wrote:
>
>> This particular one:
>>
>> define service{
>> use normal-service-trading
>> host_name server14
>> service_description Service Check
>> check_command check_nrpe!proxy_bs_connections
>> }
>>
>> So there's no alias entry either.
>>
>> It's the very first time that this happens, and it continues. The service
>> is still down (in maintenance) but Nagios continues to send the notification
>> with a wrong HOSTALIAS.
>>
>> On Mon, Jul 11, 2011 at 4:50 PM, Terry Carmen <terry at cnysupport.com>wrote:
>>
>>> Quoting Claudio Kuenzler <ck at claudiokuenzler.com>:
>>>
>>> > Hello,
>>> >
>>> > Since today I have almost the same problem as Jim.
>>> > The $HOSTALIAS$ macro works fine for all the checks, except one host
>>> alias
>>> > is wrong. I got aware of it today.
>>> >
>>> > Same version as Jim's, 3.2.3, compiled from source as well.
>>> >
>>> > Host config:
>>> >
>>> > define host{
>>> > use linux-platform-demo ; Name of host
>>> > template to use
>>> > ; This host
>>> > definition will inherit all variables that are defined
>>> > ; in (or
>>> inherited
>>> > by) the linux-server host template definition.
>>> > host_name server14
>>> > alias SERVER14-RANDOMDEMO
>>> > address 192.168.0.14
>>> > }
>>> >
>>>
>>> What does your service definition look like?
>>>
>>> Terry
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Nagios-users mailing list
>>> Nagios-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/nagios-users
>>> ::: Please include Nagios version, plugin version (-v) and OS when
>>> reporting any issue.
>>> ::: Messages without supporting info will risk being sent to /dev/null
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20110719/4332f2e4/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list