Re: [Nagios-devel] Automatically acknowledge services of an
Posted: Wed Dec 08, 2010 10:09 pm
--00163628444021f1280496ed5f6e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Andreas,
On Wed, Dec 8, 2010 at 5:24 PM, Andreas Ericsson wrote:
> [...]
>
> I think it's a poorly thought out patch. This will indiscriminately ack
> everything that's on a downed host, no matter if the service problem
> is related to the host being down or not. If a plugin returns CRITICAL
> when it can't connect, and then continues returning CRITICAL after the
> host goes up due to a real problem, that real problem would be hidden
> by this patch, since it would appear to be acknowledged even though it
> would actually be the host that's acked.
>
>
I don't see why this patch is poorly designed. Basically, we wanted to add =
a
parameter in services or service models, but we thought that "Nagios
Fathers" would never accept it, because the change was too big. Thus, we
chose to put a global option for this feature, which makes the patch easier
to integrate and therefore easier to be accepted.
Moreover I think you should reconsider your plugins. Is it normal for a
plugin to returns the CRITICAL status when it can not connect? Wouldn't it
be more appropriate with the UNKNOWN status? When a real CRITICAL Status
occurs, the status would change and the service would be disacknowledged
because the user did not use the field "sticky". No?
Nevertheless, this feature answers to many large companies and clients'need=
s
and thus seems to be useful. Morover, if you don't want to enable this
feature enabled, you can always disable it. Free choice to users.
As any open source project, we want to share our patches with other users. =
I
think it's the better way to helps opensource project
I hope we will find a solution to integrate this feature.
Best regards,
--
Julien MATHIS | CTO
[email protected]
T=E9l : +33(0)1.78.12.00.23
Mobile : +33(0)6.85.43.88.38
MERETHIS est =E9diteur du logiciel Centreon.
--00163628444021f1280496ed5f6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Andreas,
On Wed, Dec 8, 2010 at 5:24 PM, Andreas Ericsson=
<[email protected]> wrote:
[...]
I think it's a poorly thought out patch. This will indiscriminate=
ly ack
everything that's on a downed host, no matter if the service problem
is related to the host being down or not. If a plugin returns CRITICAL
when it can't connect, and then continues returning CRITICAL after the
host goes up due to a real problem, that real problem would be hidden
by this patch, since it would appear to be acknowledged even though it
would actually be the host that's acked.
I don't see why this patch is poorly designed. Basically, we wanted to=
=20
add a parameter in services or service models, but we thought that=20
"Nagios Fathers" would never accept it, because the change was to=
o big.=20
Thus, we chose to put a global option for this feature, which makes the=20
patch easier to integrate and therefore easier to be accepted.
Moreover I think you should reconsider your plugins. Is it normal for a=20
plugin to returns the CRITICAL status when it can not connect? Wouldn't=
=20
it be more appropriate with the UNKNOWN status? When a real CRITICAL=20
Status occurs, the status would change and the service would be=20
disacknowledged because the user did not use the field "sticky". =
No?
Nevertheless, this feature answers to many large companies and=20
clients'needs and thus seems to be useful. Morover, if you don't wa=
nt to
enable this feature enabled, you can always disable it. Free choice to=20
users.
As any open source project, we want to share our patches with other=20
users. I think it&#
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Andreas,
On Wed, Dec 8, 2010 at 5:24 PM, Andreas Ericsson wrote:
> [...]
>
> I think it's a poorly thought out patch. This will indiscriminately ack
> everything that's on a downed host, no matter if the service problem
> is related to the host being down or not. If a plugin returns CRITICAL
> when it can't connect, and then continues returning CRITICAL after the
> host goes up due to a real problem, that real problem would be hidden
> by this patch, since it would appear to be acknowledged even though it
> would actually be the host that's acked.
>
>
I don't see why this patch is poorly designed. Basically, we wanted to add =
a
parameter in services or service models, but we thought that "Nagios
Fathers" would never accept it, because the change was too big. Thus, we
chose to put a global option for this feature, which makes the patch easier
to integrate and therefore easier to be accepted.
Moreover I think you should reconsider your plugins. Is it normal for a
plugin to returns the CRITICAL status when it can not connect? Wouldn't it
be more appropriate with the UNKNOWN status? When a real CRITICAL Status
occurs, the status would change and the service would be disacknowledged
because the user did not use the field "sticky". No?
Nevertheless, this feature answers to many large companies and clients'need=
s
and thus seems to be useful. Morover, if you don't want to enable this
feature enabled, you can always disable it. Free choice to users.
As any open source project, we want to share our patches with other users. =
I
think it's the better way to helps opensource project
I hope we will find a solution to integrate this feature.
Best regards,
--
Julien MATHIS | CTO
[email protected]
T=E9l : +33(0)1.78.12.00.23
Mobile : +33(0)6.85.43.88.38
MERETHIS est =E9diteur du logiciel Centreon.
--00163628444021f1280496ed5f6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Andreas,
On Wed, Dec 8, 2010 at 5:24 PM, Andreas Ericsson=
<[email protected]> wrote:
[...]
I think it's a poorly thought out patch. This will indiscriminate=
ly ack
everything that's on a downed host, no matter if the service problem
is related to the host being down or not. If a plugin returns CRITICAL
when it can't connect, and then continues returning CRITICAL after the
host goes up due to a real problem, that real problem would be hidden
by this patch, since it would appear to be acknowledged even though it
would actually be the host that's acked.
I don't see why this patch is poorly designed. Basically, we wanted to=
=20
add a parameter in services or service models, but we thought that=20
"Nagios Fathers" would never accept it, because the change was to=
o big.=20
Thus, we chose to put a global option for this feature, which makes the=20
patch easier to integrate and therefore easier to be accepted.
Moreover I think you should reconsider your plugins. Is it normal for a=20
plugin to returns the CRITICAL status when it can not connect? Wouldn't=
=20
it be more appropriate with the UNKNOWN status? When a real CRITICAL=20
Status occurs, the status would change and the service would be=20
disacknowledged because the user did not use the field "sticky". =
No?
Nevertheless, this feature answers to many large companies and=20
clients'needs and thus seems to be useful. Morover, if you don't wa=
nt to
enable this feature enabled, you can always disable it. Free choice to=20
users.
As any open source project, we want to share our patches with other=20
users. I think it&#
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]