Service checks in chroot

Icinga 2
1

Hello,

I would like to ask because I didnt found any proper answer yet.
I have setup of Master->Satellite->Client
Basic global checks works great.
But I have to deal with more complicated thing and its custom check, group checks based on host condition. Its all fine but what about checks for daemons which runs inside of chroot on Client node?

Its basic Debian with host check for load, disks etc…
But how can I easily setup multiple checks, complex checks which have to run inside of chroot?
eg. Mysql check through socket + slave check with critical and warning seconds.
or custom checks in bash/perl/python
Is there any workaround which I havent found yet?

The only thing what I found is this: check nagios config argument -x (Runs inside of specified chroot folder).
check_nagios_config

I would appreciate any helpful hint.

Thanks

2

Hi,

do you have a concrete example about such a daemon running in a chroot you’d want to monitor? E.g. how it is created, specific outputs and things you need to run inside the chroot and not from the outside.

Cheers,
Michael

3

Hi,

sure, its set of known DBs like MySQL, Mongo, Redis
Some specific processes to check if they are running (this should be monitored from outside).
And maybe some simple scripts which will do some parsing from running process & logs -> This is WIP and will be specified soon.
Mainly about DB daemons.
Its all supported by nagios plugins in icinga but how to do it while they run in chroot?

Thanks

4

Hi,

I don’t really understand the term chroot in combination with a database server.

Anyhow, if that means that you cannot access the RDBMS from your remote Icinga master, you can always install the Icinga Agent/Client on the DB host and execute the checks locally on there.

Something like

template Host "mysql-server" {
  ...
}
object Host "mysql-server" {
  import "mysql-server"
  ...
  vars.agent_endpoint = name
}

apply Service "mysql-health-connection-time" {
  check_command = "mysql_health"

  vars.mysql_health_mode = "..."

  command_endpoint = host.vars.agent_endpoint //execute the check directly on the agent being the mysql-server

  assign where "mysql-server" in host.templates
}

I’ve updated the Agent based monitoring chapter for 2.11 already, here’s a preview.

Cheers,
Michael

5

UPDATE

setup is like this

VM1-1 (control machine) -> Master icinga with all zones synced to the satellite/agents + icinga web

VM2-1 (one of the servers in cloud solution behind nat) -> Satellite

VM2-2 (part of cloud together with rest VM2-X servers) -> Agent
We can monitor system resources right now, its working OK.
This VM host running Debian has chroot folder. Inside of this chroot runs everything
Its something like a container
In future it will be migrated to Docker but at this time all prodction servers running chroots.

So you suggest to install Icinga agent even to the chroot?
Have to try it.
But cant imagine it because one VM host can contain multiple chroot folders.
How to setup? While there is no IP its just chrooted jail.
Any ideas?

Thanks

6

I know the definition of a chroot, I was just wondering how this works with a database server - I would never run multiple database instances in chroots on the same server, is that a common thing?

In that specific case I’d just install the agent on the root host which controls the creation/runtime of these chroots and look in there “as root”. The services provided by this can be checked in a similar fashion. For Docker, there’s APIs to look into containers, for chroots/jails - others might know better.

Cheers,
Michael