[icinga-users] Icinga2 continues to impress
If anyone is curious to know what icinga2 can do in a large environment, all of these checks are being processed from 1, 16 core server with a load average of 10, across 2 coasts. It’s an amazing product! ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Scheduled downtimes are being removed every time Icinga2 is reloaded
Fantastic! On Feb 23, 2017, 5:01 PM -0500, Michael Martinez , wrote: > Hi Rob, thanks for the info. > Actually I was able to fix it by appending the following in icinga2.conf: > > include_recursive "/var/lib/icinga2/api/packages/_api/conf.d" > > > > On Thu, Feb 23, 2017 at 1:47 PM, Rob DeSanno wrote: > > I had this same exact problem too and the only way I found to resolve it was > > to blow the install / db away and reinstall from scratch. The only downside, > > aside from the time it takes to reinstall, was the loss of our history but > > that was acceptable compared to not having consistent downtimes. > > > > https://github.com/Icinga/icinga2/issues/4747 > > > > On Feb 23, 2017, 3:48 PM -0500, Michael Martinez , wrote: > > > > HEre are the contents of my /var/lib/icinga2/api directory: > > > > [root@ec2 icinga101 api]$ pwd > > /media/ephemeral0/icinga2/var/lib/icinga2/api > > [root@ec2 icinga101 api]$ !find > > find . -path '*downtimes*' -prune -o -path '*comments*' -prune -o -type f > > ./packages/_api/conf.d/downtimes > > ./packages/_api/conf.d/comments > > > > On Thu, Feb 23, 2017 at 12:30 PM, Michael Martinez wrote: > > > > Is there any way to make the scheduled Downtimes persistent between > > doing a reload? They disappear every time a reload occurs. > > > > -- > > --- > > Michael Martinez > > http://www.michael--martinez.com > > > > > > > > > > -- > > --- > > Michael Martinez > > http://www.michael--martinez.com > > ___ > > 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 > > > > > > -- > --- > Michael Martinez > http://www.michael--martinez.com > ___ > 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
Re: [icinga-users] Scheduled downtimes are being removed every time Icinga2 is reloaded
I had this same exact problem too and the only way I found to resolve it was to blow the install / db away and reinstall from scratch. The only downside, aside from the time it takes to reinstall, was the loss of our history but that was acceptable compared to not having consistent downtimes. https://github.com/Icinga/icinga2/issues/4747 On Feb 23, 2017, 3:48 PM -0500, Michael Martinez , wrote: > HEre are the contents of my /var/lib/icinga2/api directory: > > [root@ec2 icinga101 api]$ pwd > /media/ephemeral0/icinga2/var/lib/icinga2/api > [root@ec2 icinga101 api]$ !find > find . -path '*downtimes*' -prune -o -path '*comments*' -prune -o -type f > ./packages/_api/conf.d/downtimes > ./packages/_api/conf.d/comments > > On Thu, Feb 23, 2017 at 12:30 PM, Michael Martinez wrote: > > Is there any way to make the scheduled Downtimes persistent between > > doing a reload? They disappear every time a reload occurs. > > > > -- > > --- > > Michael Martinez > > http://www.michael--martinez.com > > > > -- > --- > Michael Martinez > http://www.michael--martinez.com > ___ > 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
[icinga-users] Non-NRPE command timeouts
I’m running into a problem in the office whereby some of my non-NRPE checks are taking more than 60 seconds to complete and icinga2 is killing them and returning the following status: So I have 2 questions: - Is there a way to increase the default, non-NRPE checks to run more than 60s without having to tweak each check? - Can I make non-nrpe checks that time out go into critical instead of unknown like you can with nrpe? The last question is more important than the first and can’t seem to find a way to do it. TIA! ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] by_ssh and force_command not working
Hey Dirk,
I don't know if this helps you any but this is how I have it implemented in
my shop and maybe there's something here that will put you on the right
track. I remember having issues with this check too until I stumbled upon
the -l and -o switches arguments, which made things much easier. Another
thing that was tripping me up, and wasn't obvious, were servers that were
configured MOTD/banners and worked around this by suppress them using the
LogLevel=Error setting.
Good luck and hope this helps some!
object CheckCommand "check_health" {
import "by_ssh"
vars.by_ssh_command = "sudo /usr/lib64/nagios/plugins/check_health"
timeout = 60
arguments += {
"-l" = "icinga"
"-o" = "StrictHostKeyChecking=no"
"-o" = "LogLevel=Error"
}
}
object EventCommand "event_by_ssh" {
import "plugin-event-command"
command = [ PluginDir + "/check_by_ssh" ]
arguments = {
"-H" = "$event_by_ssh_address$"
"-p" = "$event_by_ssh_port$"
"-C" = "$event_by_ssh_command$"
"-l" = "$event_by_ssh_logname$"
"-i" = "$event_by_ssh_identity$"
"-q" = {
set_if = "$event_by_ssh_quiet$"
}
"-w" = "$event_by_ssh_warn$"
"-c" = "$event_by_ssh_crit$"
"-t" = "$event_by_ssh_timeout$"
}
vars.event_by_ssh_address = "$address$"
vars.event_by_ssh_quiet = false
}
On September 16, 2016 at 6:08:23 AM, dirk@roeder.rocks (dirk@roeder.rocks)
wrote:
Hello together,
I'm having some problems with getting by_ssh running.
We are enforcing SSH Commands through ssh keys, this works fine wenn called
manually (So key exchange and so on is working).
-bash-4.2$ /usr/lib64/nagios/plugins/check_by_ssh -H localhost -l icinga -C
'uptimeTest 1 2 3'
uptimeTest 1 2 3 | uptimeTest 1 2 3
I followed the wiki
https://wiki.icinga.org/display/howtos/Using+SSH+as+remote+client+for+Icinga2
and created a small config file:
object CheckCommand "ssh_enforce" {
import "by_ssh"
vars.by_ssh_login = "icinga"
vars.by_ssh_command = [ "$command$", "$param1$", "$param2$", "$param3$" ]
}
apply Service "ssh_enforce_uptime" {
import "generic-service"
check_command = "ssh_enforce"
vars.command = "uptimeTest"
vars.param1 = "1"
vars.param2 = "2"
assign where host.vars.os == "Linux"
}
apply Service "ssh_enforce_updates" {
import "generic-service"
check_command = "ssh_enforce"
vars.command = "updates"
assign where host.vars.os == "Linux"
}
I found Icinga trying to run the commands uptimeTest and updates running
locally and not via ssh.
Plugin Output
Remote command execution failed: bash: uptimeTest: command not found
I'm running icinga2-2.5.4-1 on latest CentOS from the official repositories.
>From what I can see within the configuration all arguments are parsed fine:
icinga2 object list
Check Command:
Object 'ssh_enforce' of type 'CheckCommand':
% declared in '/etc/icinga2/conf.d/test.conf', lines 1:0-1:32
* __name = "ssh_enforce"
* arguments
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
1646:2-1683:2
* -4
* description = "Use IPv4 only"
* set_if = "$by_ssh_ipv4$"
* -6
* description = "Use IPv6 only"
* set_if = "$by_ssh_ipv6$"
* -C
* type = "Function"
* -H = "$by_ssh_address$"
* -c = "$by_ssh_crit$"
* -i = "$by_ssh_identity$"
* -l = "$by_ssh_logname$"
* -o
* description = "Provide ssh options (may be repeated)"
* value = "$by_ssh_options$"
* -p = "$by_ssh_port$"
* -q
* set_if = "$by_ssh_quiet$"
* -t = "$by_ssh_timeout$"
* -w = "$by_ssh_warn$"
* command = [ "/usr/lib64/nagios/plugins/check_by_ssh" ]
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
1644:2-1644:42
* env = null
* execute
% = modified in 'methods-itl.conf', lines 36:3-36:33
* type = "Function"
* name = "ssh_enforce"
* package = "_etc"
* templates = [ "ssh_enforce", "by_ssh", "plugin-check-command",
"ipv4-or-ipv6" ]
% = modified in '/etc/icinga2/conf.d/test.conf', lines 1:0-1:32
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
1640:1-1640:28
% = modified in 'methods-itl.conf', lines 35:2-35:61
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
20:1-20:36
* timeout = 60
* type = "CheckCommand"
* vars
* by_ssh_address = "$check_address$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
1685:2-1685:40
* by_ssh_command = [ "$command$", "$param1$", "$param2$", "$param3$" ]
% = modified in '/etc/icinga2/conf.d/test.conf', lines 5:5-5:77
* by_ssh_login = "icinga"
% = modified in '/etc/icinga2/conf.d/test.conf', lines 4:5-4:36
* by_ssh_quiet = false
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
1686:2-1686:26
* check_address
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines
21:2-30:3
* type = "Function"
* check_i
Re: [icinga-users] Is notification based on % possible?
This is working out well but have one more question. Is there a way to set the
vars.cluster_nodes array using a variable or predefined hostgroup? Even a regex
would work but is not optimal.
Here is what I have:
object Host "cluster_f" {
import "cluster_template"
vars.cluster_nodes = [“servera”,”serverb”,”serverc”]
and here is what I want:
object Host "cluster_f" {
import "cluster_template"
vars.cluster_nodes = [“server\*"]
But this is what I *really* *really* want:
object Host "cluster_f" {
import "cluster_template"
vars.cluster_nodes == {{ all $hostnames$ in host.vars.servertype =
“my_servers” }}
Suggestions?
On September 13, 2016 at 10:24:49 AM, Rob DeSanno (rdesa...@gmail.com) wrote:
Markus,
That’s brilliant! I’m going to need some time to digest and test it but this
looks like it is the solution I am looking for.
On September 13, 2016 at 3:35:47 AM, Joosten, Markus (markus.joos...@plumbe.de)
wrote:
On 2016-09-12 19:23, Rob DeSanno wrote:
> The challenge presented to me was to somehow configure notifications
> to be sent only when a certain percentage of hosts experience critical
> alerts.
>
> For example, instead of sending out a notification when every host
> fails a ping check, only send one out if 10%, or more, hosts fail.
>
> We want something a little more complicated than that but the basic
> theory should be the same, assuming its possible. Anyone have any
> experience or thoughts on how to go about doing this?
I have implemented something like this using check_dummy and Icinga2's
runtime macros.
Behold the following template (the basic idea is borrowed somewhere
else, can't remember where):
template Host "dummy-cluster" {
import "generic-host"
check_command = "dummy"
vars.cluster_nodes = [ ]
vars.dummy_state = {{
var up_count = 0
var down_count = 0
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
if (get_host(node).state > 0) {
down_count += 1
} else {
up_count += 1
}
}
if (up_count >= 1 ) {
return 0 //at least one host responded
} else {
return 2 //no host answered
}
}}
vars.dummy_text = {{
var output = "Cluster hosts:\n"
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
output += node + ": " + get_host(node).last_check_result.output +
"\n"
}
return output
}}
}
As you can see, the vars.dummy_state is always evaluated at runtime and
takes the last state of all host objects stored in vars.cluster_nodes
into account.
My template always returns UP as long as one host in vars.cluster_nodes
is UP.
You could introduce an additional var where you can define which
percentage at which everything should be considered "UP".
I instantiate the template as follows:
object Host "ClusterA" {
import "dummy-cluster"
vars.cluster_nodes = [ "HostA", "HostB", "HostC", "HostD" ]
}
Kind regards,
Markus
> ___
> 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
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Is notification based on % possible?
Markus,
That’s brilliant! I’m going to need some time to digest and test it but this
looks like it is the solution I am looking for.
On September 13, 2016 at 3:35:47 AM, Joosten, Markus (markus.joos...@plumbe.de)
wrote:
On 2016-09-12 19:23, Rob DeSanno wrote:
> The challenge presented to me was to somehow configure notifications
> to be sent only when a certain percentage of hosts experience critical
> alerts.
>
> For example, instead of sending out a notification when every host
> fails a ping check, only send one out if 10%, or more, hosts fail.
>
> We want something a little more complicated than that but the basic
> theory should be the same, assuming its possible. Anyone have any
> experience or thoughts on how to go about doing this?
I have implemented something like this using check_dummy and Icinga2's
runtime macros.
Behold the following template (the basic idea is borrowed somewhere
else, can't remember where):
template Host "dummy-cluster" {
import "generic-host"
check_command = "dummy"
vars.cluster_nodes = [ ]
vars.dummy_state = {{
var up_count = 0
var down_count = 0
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
if (get_host(node).state > 0) {
down_count += 1
} else {
up_count += 1
}
}
if (up_count >= 1 ) {
return 0 //at least one host responded
} else {
return 2 //no host answered
}
}}
vars.dummy_text = {{
var output = "Cluster hosts:\n"
var cluster_nodes = macro("$cluster_nodes$")
for (node in cluster_nodes) {
output += node + ": " + get_host(node).last_check_result.output +
"\n"
}
return output
}}
}
As you can see, the vars.dummy_state is always evaluated at runtime and
takes the last state of all host objects stored in vars.cluster_nodes
into account.
My template always returns UP as long as one host in vars.cluster_nodes
is UP.
You could introduce an additional var where you can define which
percentage at which everything should be considered "UP".
I instantiate the template as follows:
object Host "ClusterA" {
import "dummy-cluster"
vars.cluster_nodes = [ "HostA", "HostB", "HostC", "HostD" ]
}
Kind regards,
Markus
> ___
> 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
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Is notification based on % possible?
The challenge presented to me was to somehow configure notifications to be sent only when a certain percentage of hosts experience critical alerts. For example, instead of sending out a notification when every host fails a ping check, only send one out if 10%, or more, hosts fail. We want something a little more complicated than that but the basic theory should be the same, assuming its possible. Anyone have any experience or thoughts on how to go about doing this? ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Losing downtimes upon reload
Thanks, all! I’m glad it’s not just me.
On September 2, 2016 at 8:03:58 AM, Peter Eckel (li...@eckel-edv.de) wrote:
Hi,
I can confirm it's there in 2.5.4.
Cheers,
Peter.
> On 02 Sep 2016, at 08:53, Bancal Samuel wrote:
>
> Hi,
>
> This is a bug that was reported https://dev.icinga.org/issues/11182 and
marked as resolved 3 months ago (target version 2.5.0).
> When 2.5.0 was released ... aparently the bug was still there :
https://dev.icinga.org/issues/12548 .
>
> You can "Watch" these bugs to know when it'll be fixed.
>
> Regards,
> Samuel
>
>
> On 02. 09. 16 00:33, Rob DeSanno wrote:
>> I'm at a loss and hoping that maybe someone here has a solution. The
problem that I have been noticing is that anytime I do a restart or reload,
I am losing some type of downtime information in icinga2. I just upgraded
to the latest release but unfortunately the problem still exists for me.
>>
>> For starters, I am running icinga 2.5 with mariadb, plus icinga2-classic
for use with nagstamon and older mobile app compatibility.
>>
>> # rpm -qa | egrep -i 'mariadb|icinga'
>> icingacli-2.3.4-1.el7.centos.noarch
>> icingaweb2-vendor-dompdf-0.6.2-1.el7.centos.noarch
>> MariaDB-client-10.1.17-1.el7.centos.x86_64
>> icinga2-2.5.4-1.el7.centos.x86_64
>> opsgenie-icinga2-2.0.0-1.all.noarch
>> icinga2-common-2.5.4-1.el7.centos.x86_64
>> icinga2-classicui-config-2.5.4-1.el7.centos.x86_64
>> icinga-rpm-release-7-1.el7.centos.noarch
>> icingaweb2-vendor-lessphp-0.4.0-1.el7.centos.noarch
>> icinga2-libs-2.5.4-1.el7.centos.x86_64
>> MariaDB-server-10.1.17-1.el7.centos.x86_64
>> icingaweb2-common-2.3.4-1.el7.centos.noarch
>> icingaweb2-vendor-JShrink-1.0.1-1.el7.centos.noarch
>> icingaweb2-vendor-Parsedown-1.0.0-1.el7.centos.noarch
>> MariaDB-common-10.1.17-1.el7.centos.x86_64
>> icinga2-bin-2.5.4-1.el7.centos.x86_64
>> icingaweb2-2.3.4-1.el7.centos.noarch
>> icinga-gui-1.13.3-0.el7.centos.x86_64
>> MariaDB-shared-10.1.17-1.el7.centos.x86_64
>> icinga2-ido-mysql-2.5.4-1.el7.centos.x86_64
>> icinga-doc-1.13.3-0.el7.centos.x86_64
>> php-Icinga-2.3.4-1.el7.centos.noarch
>> icingaweb2-vendor-HTMLPurifier-4.7.0-1.el7.centos.noarch
>>
>> The problem is that when I have a host that is down, and it is acked,
the services still show up in icinga classic as critical. If I set a
downtime on the host and services at the same time, everything is fine
until I do a restart or a reload. This causes icinga to ignore that there
is a downtime set against the host even though my previous comments still
persist.
>>
>> To troubleshoot, I tried all different kinds of approaches like removing
the downtimes from
>>
/var/lib/icinga2/api/packages/_api/{SERVERNAME}-1459445242-1/conf.d/downtimes/
>>
>> or manually removing them from the following database tables directly
(ie icinga_downtimehistory, icinga_acknowledgements, icinga_comments, or
icinga_scheduleddowntime).
>>
>> The reason for being so extreme is because I was not able to remove
whatever downtime was associated with this host by using the gui directly.
I guess the next step would be to remove the host and add it back in to see
what happens but to be honest, i'm seeing this same problem with a handful
of hosts however, it could be just limited to these servers and not all.
>>
>> Anyone have any similar experiences?
>>
>>
>>
>>
>> ___
>> icinga-users mailing list
>>
>> icinga-users@lists.icinga.org
>> https://lists.icinga.org/mailman/listinfo/icinga-users
>
> --
> Samuel Bancal
> ENAC-IT
> EPFL
>
> ___
> 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
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Losing downtimes upon reload
I'm at a loss and hoping that maybe someone here has a solution. The
problem that I have been noticing is that anytime I do a restart or reload,
I am losing some type of downtime information in icinga2. I just upgraded
to the latest release but unfortunately the problem still exists for me.
For starters, I am running icinga 2.5 with mariadb, plus icinga2-classic
for use with nagstamon and older mobile app compatibility.
# rpm -qa | egrep -i 'mariadb|icinga'
icingacli-2.3.4-1.el7.centos.noarch
icingaweb2-vendor-dompdf-0.6.2-1.el7.centos.noarch
MariaDB-client-10.1.17-1.el7.centos.x86_64
icinga2-2.5.4-1.el7.centos.x86_64
opsgenie-icinga2-2.0.0-1.all.noarch
icinga2-common-2.5.4-1.el7.centos.x86_64
icinga2-classicui-config-2.5.4-1.el7.centos.x86_64
icinga-rpm-release-7-1.el7.centos.noarch
icingaweb2-vendor-lessphp-0.4.0-1.el7.centos.noarch
icinga2-libs-2.5.4-1.el7.centos.x86_64
MariaDB-server-10.1.17-1.el7.centos.x86_64
icingaweb2-common-2.3.4-1.el7.centos.noarch
icingaweb2-vendor-JShrink-1.0.1-1.el7.centos.noarch
icingaweb2-vendor-Parsedown-1.0.0-1.el7.centos.noarch
MariaDB-common-10.1.17-1.el7.centos.x86_64
icinga2-bin-2.5.4-1.el7.centos.x86_64
icingaweb2-2.3.4-1.el7.centos.noarch
icinga-gui-1.13.3-0.el7.centos.x86_64
MariaDB-shared-10.1.17-1.el7.centos.x86_64
icinga2-ido-mysql-2.5.4-1.el7.centos.x86_64
icinga-doc-1.13.3-0.el7.centos.x86_64
php-Icinga-2.3.4-1.el7.centos.noarch
icingaweb2-vendor-HTMLPurifier-4.7.0-1.el7.centos.noarch
The problem is that when I have a host that is down, and it is acked, the
services still show up in icinga classic as critical. If I set a downtime
on the host and services at the same time, everything is fine until I do a
restart or a reload. This causes icinga to ignore that there is a downtime
set against the host even though my previous comments still persist.
To troubleshoot, I tried all different kinds of approaches like removing
the downtimes from
/var/lib/icinga2/api/packages/_api/{SERVERNAME}-1459445242-1/conf.d/downtimes/
or manually removing them from the following database tables directly (ie
icinga_downtimehistory, icinga_acknowledgements, icinga_comments, or
icinga_scheduleddowntime).
The reason for being so extreme is because I was not able to remove
whatever downtime was associated with this host by using the gui directly.
I guess the next step would be to remove the host and add it back in to see
what happens but to be honest, i'm seeing this same problem with a handful
of hosts however, it could be just limited to these servers and not all.
Anyone have any similar experiences?
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Icinga2 mobile App for iOS/Android
This is interesting and we are looking for a good nagios/icinga app for our phones that is also compatible with icinga2. I have the classic gui up and running and would love to give this a try when I have the time! On June 8, 2016 at 3:29:27 AM, Willem de Jonge (wil...@isnapp.nl) wrote: My iOS app MobiosPush (http://www.isnapp.nl/mobiospush/) supports Icinga 1.x and includes support for push notifications. Possibly this works for Icinga2 also when using the classic-ui. Maybe someone can try this and confirm if this works (I can provide a test code to get the app). Kind regards, Willem de Jonge ___ 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
[icinga-users] Icinga2 mobile App for iOS/Android
We have a log of nagstamon/anag users here at the office and was wondering what everyone is using on their mobile devices to monitor their icinga2 instances. Please don’t say Chrome ;) TIA! ___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Migrating from Nagios - Migration scripts ?
I was in the same situation having thousands of servers and a bunch of checks
to migrate from Nagios to Icinga, but couldn’t find an easy migration tool. To
be honest, I wound up copying over my config files from my old Nagios server
and configured them myself with a combination of a little shell scripting and
sed magic. Once you understand the syntax, its not too terrible.
Service checks, on the other hand, took me a lot of time to get them the way I
wanted them (and still tweaking every day). I’ll start you off with a script I
put together to generate my hosts.conf.
export list=“ENTER SERVERS HERE"
for i in $list ; do echo -e "object Host \"$i\" {\n\tdisplay_name =
\"$i\"\n\taddress = \"`nslookup $i | grep ^Add| tail -1 | cut -d\" \"
-f2`\"\n\tvars.servertype = \”LInux\"\n\tvars.timezone =
\"UTC\"\n\tcheck_command = \"hostalive\"\n\t"action_url = jira_url +
display_name"\n\t"notes_url = racktables_url +
display_name"\n\tvars.environment = \"production\"\n}\n" ; done
HTH!
On April 9, 2016 at 12:50:41 PM, Michael Friedrich
(michael.friedr...@netways.de) wrote:
Hi,
On 09 Apr 2016, at 13:58, Toussaint OTTAVI
mailto:t.ott...@bc-109.com>> wrote:
Hi,
I'm new to this ML. I'm planning to migrate from Nagios, and I'm evaluating
Icinga2.
I read a lot of things about the new sytax of the configuration files, and all
the advices telling to re-write configuration files from scratch.
Yep. That’s our experience from now 2 years of community and customer support.
And I am doing quite a lot of support, as others say.
But... that clearly won't be possible on our production environment ! We have
hundreds of hosts, and thousands of services. Re-writing all the config files
by hand, just to get the same thing as before, would involve several days
(weeks ?) of work. I don't have that time.
You haven’t started yet, so you can’t estimate it anyways. Give it a try once
you’re learned the new syntax and do a small prototype first.
Having the ability to import, let's say, 80% of the actual config (even it is
not optimized at all), would be the minimum. Without that, Icinga may be the
best software in the world, I can't afford spending too much time re-writing
existing files with another syntax.
We discussed writing a config parser for the Icinga 1.x language, just in
Icinga 2. That was iirc in late 2012 or somewhere in 2013. We decided against
it. Then we would have to maintain two configuration languages and users will
never switch to a new format. The one were a lot of effort has been running
into allowing to easily deploy thousands of services with some simple apply
rules.
You will see the old world partially, as there’s status.dat or DB IDO or the
command pipe. In the end you don’t care much when looking into the Icinga Web 2
frontend. One thing which could be interesting as well is the REST API which
allows your to create objects at runtime without doing a reload.
About the "migration script", I didn't really understand what's the currest
status : Is it still a "standalone" tool ? Is it integrated in the icingacli (I
didn't find it) ? Is there any documentation (I didn't ever find ow to specify
the source path for old files) ? Is it still supported, or is it considered as
"deprecated" and "unuseful” ?
The answer is simple - everyone thought a migration script will solve the pain
of rewriting the configs. So we created one. Turns out that your config objects
look horrible and you are not able to maintain such in production.
Even harder - doing a migration automatically will hide several cool new
features from you, and later on you will find yourself needing to learn about
the new stuff in a short while. Especially when you ask for support and someone
sees your “vars.ARG1” custom attributes. That works but is far from elegant in
production.
I’m the author of that script which partially uses code for parsing the old
config done by Tom. It will never get integrated into icingacli, bugs won’t be
fixed and it is now deprecated. Will be removed soon enough allowing anyone to
copy the code if they want to.
The future in terms of configuration tools is the Icinga Director, which I have
been eagerly waiting for. If you have some sort of CMDB or $datastorage you can
import your monitoring data from, look into that. Better than any migration
script.
I understand all what has been said about the advantages of the new file
structure. But without a decent migration tool, I just can't afford spending so
much time in rewriting my existing Nagios files by hand.
Instead of fearing the time it would take, you should do an inventory at first
glance.
Find out what’s running currently, find similarities and identify your plugins,
check commands, and checkable objects. Further, dive into the notification and
dependency world. Get to know your contacts and parents.
There is no unique guidance in doing such a migration, as each Nagios/I
[icinga-users] Icingaweb2 and htpasswd
Is it possible to set up Icinga2 / Icingaweb to use htpasswd for authentication? I’m looking on the web and docs but cant seem to figure out how to do it and wonder if it’s even possible. Sorry in advance for the noob question but could use some help setting it up if it can be. TIA!___ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Error: Request contained illegal metachars help!
As always, thanks for your quick response. I’ll play around with doing it your
way and report back if I continue having issues.
On February 3, 2016 at 11:43:22 AM, Michael Friedrich
(michael.friedr...@netways.de) wrote:
> On 03 Feb 2016, at 16:49, Rob DeSanno wrote:
>
> Good morning / afternoon!
>
> I have one http check that I am trying to convert from Nagios over to Icinga2
> but its kicking my butt. In a nutshell, the way this check works is the
> icinga host uses nrpe to run a command on the destination host which, in
> turn, tries to verify that that host can reach an outside host (ie icinga —>
> SERVERNAME —> amazonaws.com).
>
> The problem that I am coming across is that this check only runs when the
> nrpe arguments are encapsulated within quotes, something Icinga can’t
> process. If I escape the quotes in the check, the remote host doesn’t like it
> and returns the following error:
>
> Client request was invalid, bailing out...
> Error: Request contained illegal metachars!
>
> Here is how I have it currently configured...
>
> object CheckCommand "check_http_remote" {
> import "nrpe-common"
> command = [ PluginDir + "/check_nrpe","-H", "$host.address$", "-t", "30",
> "-c", "check_http_remote", "-a", "$ARG1$”]
>
>
> apply Service "pingS3" {
> import "generic-service"
> display_name = "pingS3"
> check_command = "check_http_remote"
>
> vars += {
> "ARG1" = "-H s3.amazonaws.com -u https://s3.amazonaws.com/blahblahblah.txt";
> }
>
> assign where host.vars.servertype in [“remote_server"]
> }
Don’t go the old way of passing command arguments as an entire string. There
already is an “nrpe” CheckCommand available which allows you to pass additional
arguments (the infamous -a flag). Note that you really should read about how to
pass command parameters as custom attributes (you certainly do already
partially).
Those arguments can be defined as array, so to speak yours would look like the
following.
apply Service “pingS3” {
import “generic-service”
display_name = …
check_command = “nrpe”
vars.nrpe_timeout = 30
vars.nrpe_command = “check_http_remote”
vars.nrpe_arguments = [ “-H”, “s3.amazonaws.com”, “-u”,
“https://s3.amazonaws.com/blahblahblah.txt” ]
assign where host.vars.servertype in [“remote_server"]
}
(untested brain dump). Icinga 2 will automatically convert the given array into
shell-escaped parameters for the “-a” argument. Everything else should be
working already as the “nrpe” CheckCommand is provided by just enabling the ITL
plugins (default).
Although there might be another problem in passing additional parameters, so I
would go for an nrpe config like this
[check_http_remote]=…./check_http -H $ARG1$ -u $ARG2$
and change the Service apply rule to
apply Service “pingS3” {
import “generic-service”
display_name = …
check_command = “nrpe”
vars.nrpe_timeout = 30
vars.nrpe_command = “check_http_remote”
vars.nrpe_arguments = [ “s3.amazonaws.com”,
“https://s3.amazonaws.com/blahblahblah.txt” ]
assign where host.vars.servertype in [“remote_server"]
}
Last but not least NRPE is considered insecure (or, immature) and you should
consider looking into alternatives, such as the Icinga 2 client itself.
>
> ...and this is how it is configured in nagios
>
> define command{
> command_name check_http_remote
> command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_http_remote -a
> "$ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$ $ARG10$
> $ARG11$ $ARG12$ $ARG13$ $ARG14$ $ARG15$ $ARG16$ $ARG17$ $ARG18$ $ARG19$
> $ARG20$”
… and then you had to remove $ARG7$ and rename the entire numbering … reminds
me of my fun days back in Vienna.
Kind regards,
Michael
>
>
> define service {
> use generic
> service_description pingS3
> check_command
> check_http_remote!-H!s3.amazonaws.com!-u!https://s3.amazonaws.com/blahblahblah.txt!-t!30
>
>
> Lastly, here are the results of a manual run from the icinga server, the
> first without quotes and the second with.
>
> /usr/lib64/nagios/plugins/check_nrpe -H SERVERNAME -c check_http_remote -t 30
> -a -H s3.amazonaws.com -u https://s3.amazonaws.com/blahblahblah.txt
> Name or service not known
> HTTP CRITICAL - Unable to open TCP socket
>
> /usr/lib64/nagios/plugins/check_nrpe -H SERVERNAME -c check_http_remote -t 30
> -a "-H s3.amazonaws.com -u https://s3.amazonaws.com/blahblahblah.txt";
> HTTP OK: HTTP/1.1 200 OK - 496 bytes in 0.050 second response time
> |time=0.0
[icinga-users] Error: Request contained illegal metachars help!
Good morning / afternoon!
I have one http check that I am trying to convert from Nagios over to Icinga2
but its kicking my butt. In a nutshell, the way this check works is the icinga
host uses nrpe to run a command on the destination host which, in turn, tries
to verify that that host can reach an outside host (ie icinga —> SERVERNAME —>
amazonaws.com).
The problem that I am coming across is that this check only runs when the nrpe
arguments are encapsulated within quotes, something Icinga can’t process. If I
escape the quotes in the check, the remote host doesn’t like it and returns the
following error:
Client request was invalid, bailing out...
Error: Request contained illegal metachars!
Here is how I have it currently configured...
object CheckCommand "check_http_remote" {
import "nrpe-common"
command = [ PluginDir + "/check_nrpe","-H", "$host.address$", "-t",
"30", "-c", "check_http_remote", "-a", "$ARG1$”]
apply Service "pingS3" {
import "generic-service"
display_name = "pingS3"
check_command = "check_http_remote"
vars += {
"ARG1" = "-H s3.amazonaws.com -u
https://s3.amazonaws.com/blahblahblah.txt";
}
assign where host.vars.servertype in [“remote_server"]
}
...and this is how it is configured in nagios
define command{
command_name check_http_remote
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c
check_http_remote -a "$ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$
$ARG9$ $ARG10$ $ARG11$ $ARG12$ $ARG13$ $ARG14$ $ARG15$ $ARG16$ $ARG17$ $ARG18$
$ARG19$ $ARG20$"
define service {
use generic
service_description pingS3
check_command
check_http_remote!-H!s3.amazonaws.com!-u!https://s3.amazonaws.com/blahblahblah.txt!-t!30
Lastly, here are the results of a manual run from the icinga server, the first
without quotes and the second with.
/usr/lib64/nagios/plugins/check_nrpe -H SERVERNAME -c check_http_remote -t 30
-a -H s3.amazonaws.com -u https://s3.amazonaws.com/blahblahblah.txt
Name or service not known
HTTP CRITICAL - Unable to open TCP socket
/usr/lib64/nagios/plugins/check_nrpe -H SERVERNAME -c check_http_remote -t 30
-a "-H s3.amazonaws.com -u https://s3.amazonaws.com/blahblahblah.txt";
HTTP OK: HTTP/1.1 200 OK - 496 bytes in 0.050 second response time
|time=0.049625s;;;0.00 size=496B;;;0
Any thoughts on how I can overcome this and still use the same check? I can
code my way out of this by running individual scripts on each server and
calling them from Icinga but that doesn’t seem like the right way of doing it.___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
Re: [icinga-users] Changing the default return results number
Thanks, Eric. I’ll open an official issue request in a day or so. I appreciate the quick response! On January 19, 2016 at 9:18:19 AM, Eric Lippmann (eric.lippm...@netways.de) wrote: Hi Robert, The default is set in /usr/share/php/Icinga/Web/Controller::setupPaginationControl(). But please open an issue for changing this via configuration and/or preferences. Best, Eric > On 18 Jan 2016, at 11:03 PM, Robert DeSanno wrote: > > > > > > I *really* want to change the default return results from #25 to something a > little higher, like 100 but can’t seem to find the setting for it. I thought > it was under > /usr/share/icingaweb2/application/forms/Control/LimiterControlForm.php but > that didn’t do anything. Anyone know where this setting is? > ___ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users -- Eric Lippmann Lead Senior Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | eric.lippm...@netways.de ** OSDC 2016 - April - netways.de/osdc ** ** OSBConf 2016 - September - osbconf.org ** ___ 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
Re: [icinga-users] if...else question
I took a step back yesterday and yes, I did make this too complicated and came
up with a similar solution too. Yours is a little more interesting however and
may need to adjust my monitoring check strategy to incorporate.
Thanks for the direction!!
On January 18, 2016 at 2:43:53 AM, Gunnar Beutner (gunnar.beut...@netways.de)
wrote:
Hello,
The if/else construct you’re using is evaluated when the CheckCommand is
instantiated - i.e. when Icinga starts and parses its config. „vars.servertype“
actually refers to the CheckCommand’s custom variables.
If you want the if/else to be evaluated for each check you’re going to have to
use a lambda function, like so:
object CheckCommand "check_timezone" {
import „nrpe-common"
command = [ PluginDir + "/check_nrpe", "-H", "$host.address$", "-c",
"check_timezone" ]
arguments += {
"-a" = {{
if (host.vars.servertype in [ "cassandra", "rabbit", "mq", "redis" ]) {
var tz_permanent = "UTC"
var tz_seasonal_comma = "UTC"
var localtime_hash = "c79354b8dbee09e62bbc3fb544853283"
} else {
var tz_permanent = "America/New_York"
var tz_seasonal_comma = "EST,EDT"
var localtime_hash = "e4ca381035a34b7a852184cc0dd89baa"
}
return tz_permanent + " " + tz_seasonal_comma + " " + localtime_hash
}}
"-t" = "$timeout$"
}
}
Does that feel overly complicated to you? Because… well, it should. Ideally you
should keep as much domain-specific knowledge out of the CheckCommand
definitions as possible.
A far better - and easier - way would be to use host templates:
template Host „utc-server“ {
vars.tz_permanent = "UTC"
vars.tz_seasonal_comma = "UTC"
vars.localtime_hash = "c79354b8dbee09e62bbc3fb544853283"
}
template Host „est-server“ {
vars.tz_permanent = "America/New_York"
vars.tz_seasonal_comma = "EST,EDT"
vars.localtime_hash = "e4ca381035a34b7a852184cc0dd89baa"
}
template Host „mq-server“ {
import „utc-server“
vars.servertype = „mq“
}
/* Additional templates for cassandra, rabbit, redis, etc. */
object Host „mq-server-001“ {
import „mq-server"
}
Kind regards,
Gunnar Beutner
On 16/01/16 19:32, "icinga-users on behalf of Rob DeSanno"
wrote:
>
>I’m trying to wrap my head around using if/else conditions for my
>CheckCommands but I can’t seem to get it to work. In this example, most of my
>servers timezone is set to EST whereas only a handful (cassandra, rabbit, mq,
>and redis) are set to UTC.
>
>
>How can I reconfigure this check to pass the correct variables based on the
>servertype defined in hosts.conf? I suspect that these checks are not picking
>up either set of variables but having a hard time figuring out how it should
>be set.
>
>
>Any thoughts?
>
>
>
>
>object CheckCommand "check_timezone" {
> import "nrpe-common"
> command = [ PluginDir + "/check_nrpe", "-H", "$host.address$", "-c",
> "check_timezone" ]
>
>
> arguments += {
> "-a" = "$tz_permanent$ $tz_seasonal_comma$ $localtime_hash$"
> "-t" = "$timeout$"
> }
>
>
> if ( vars.servertype == "cassandra" || vars.servertype == "rabbit" ||
> vars.servertype == “mq" || vars.servertype == "redis" ) {
> vars.tz_permanent = "UTC"
> vars.tz_seasonal_comma = "UTC"
> vars.localtime_hash = "c79354b8dbee09e62bbc3fb544853283"
> } else {
> vars.tz_permanent = "America/New_York"
> vars.tz_seasonal_comma = "EST,EDT"
> vars.localtime_hash = "e4ca381035a34b7a852184cc0dd89baa"
> }
>}
>
>
>apply Service "check_timezone" {
> import "generic-service"
> display_name = "timezone"
> check_command = "check_timezone"
>
>
> vars += {
> "timeout" = "30"
> }
>
>
> assign where host.vars.servertype in [ … ]
>
>
--
Gunnar Beutner
Senior Developer
NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
Tel: +49 911 92885-0 | Fax: +49 911 92885-77
CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
http://www.netways.de | gunnar.beut...@netways.de
** OSDC 2016 - April - netways.de/osdc **
** OSBConf 2016 - September - osbconf.org **
___
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
[icinga-users] if...else question
I’m trying to wrap my head around using if/else conditions for my CheckCommands
but I can’t seem to get it to work. In this example, most of my servers
timezone is set to EST whereas only a handful (cassandra, rabbit, mq, and
redis) are set to UTC.
How can I reconfigure this check to pass the correct variables based on the
servertype defined in hosts.conf? I suspect that these checks are not picking
up either set of variables but having a hard time figuring out how it should be
set.
Any thoughts?
object CheckCommand "check_timezone" {
import "nrpe-common"
command = [ PluginDir + "/check_nrpe", "-H", "$host.address$", "-c",
"check_timezone" ]
arguments += {
"-a" = "$tz_permanent$ $tz_seasonal_comma$ $localtime_hash$"
"-t" = "$timeout$"
}
if ( vars.servertype == "cassandra" || vars.servertype == "rabbit" ||
vars.servertype == “mq" || vars.servertype == "redis" ) {
vars.tz_permanent = "UTC"
vars.tz_seasonal_comma = "UTC"
vars.localtime_hash = "c79354b8dbee09e62bbc3fb544853283"
} else {
vars.tz_permanent = "America/New_York"
vars.tz_seasonal_comma = "EST,EDT"
vars.localtime_hash = "e4ca381035a34b7a852184cc0dd89baa"
}
}
apply Service "check_timezone" {
import "generic-service"
display_name = "timezone"
check_command = "check_timezone"
vars += {
"timeout" = "30"
}
assign where host.vars.servertype in [ … ]___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
[icinga-users] Service check already exists
I’m trying to configure a check in icinga to validate the age of our hourly,
daily, and monthly backups on server “backup” but icinga doesn’t like the way I
have it configured. I am pasting the error message as well as lines 131 - 158
for reference.
Is there a better way of reconfiguring my checks below so I can have multiple
checks against the same host?
icinga2[22383]: [2016-01-14 16:54:22 -0500] critical/config: Error: An object
with type 'Service' and name 'backup!check_backup' already exists (in
/etc/icinga2/conf.d/services.conf: 131:1-131:28), new declaration: in
/etc/icinga2/conf.d/services.conf: 158:1-158:28
apply Service "check_backup" {
import "generic-service"
display_name = "gpbackup_daily"
check_command = "check_backup"
vars += {
warn = "100800"
crit = "187200"
file = "/backup//SQLBACKUP/Daily"
}
assign where host.display_name in [ "backup" ]
}
apply Service "check_backup" {
import "generic-service"
display_name = "gpbackup_hourly"
check_command = "check_backup"
vars += {
warn = "21600"
crit = "100800"
file = "/backup/SQLBACKUP/Hourly"
}
assign where host.display_name in [ "backup" ]
}
apply Service "check_backup" {
import "generic-service"
display_name = "gpbackup_monthly"
check_command = "check_backup"
vars += {
warn = "2764800"
crit = "4060800"
file = "/backup/SQLBACKUP/Monthly"
}
assign where host.display_name in [ "backup" ]
}___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
