Thanks for fast Reply
i use the Icinga Agent and Configure it via Director.
I cannot set command_endpoint via Director, i didn’t found it
Thanks for fast Reply
i use the Icinga Agent and Configure it via Director.
I cannot set command_endpoint via Director, i didn’t found it
Afaik you can see the client just like a satellite, with the sole difference that it only checks itself.
A satellite, or better the term “satellite”, refers to an Icinga 2 instance that executes checks on itself and remote hosts as well. For example SNMP checks to remote machines/switches or triggering NRPE checks.
The command endpoint can only be set in a host or service template, at least in the Icinga Director.
I’m not sure if the Director sets the command endpoint to the client itself if it is an Agent. But the behavior is correct for the apt check, as it has to be run locally on the machine, or else you would have x checks reporting the updates of you satellite.
That’s the “agent” option, Director automatically sets the command_endpoint configuration then.
Since the agent checks are triggered from the satellite zone, the corresponding agent host also needs to be put into the satellite
cluster zone.
Cheers,
Michael
PS: I strongly advise against NRPE having multiple security flaws. SSH should be an option, the configuration is not really a breeze compared to what’s possible with Director and agents.
Well, since I am just using the DSL (not the director) and checking all my linux hosts via SSH I must say, it works like a charm (+1100 Hosts, + 9200 Services). And since Windows Server 2019, you can also use SSH to get a Powershell Session and trigger PS scripts. So you will got a totally agentless monitoring solution via ssh, wmi and snmp. For me, the director is much more complicated than the DSL.
Okay,
now i’am littebit confused on your PS:
Agent isn’t NRPE, correct?
Than what i tried. The Director set command_enpoint to host_name when i use Agent = yes.
For my understanding, Set the Host to the satellite Zone. Than the checks are triggered from satellite and not from master, but the main checks are executed on Client and that’s why check_source = client
correct?
Sorry for many Questions, i’am into a Tunnel, and i tried a lot
Yep.
Right. NRPE is a small daemon which runs on the agent, and can be queried with check_nrpe
. This originates from Nagios and is their preferred way. NRPE is known for weak TLS, and possible MITM attacks. Also, it doesn’t integrate that transparent as you’ll have with the Icinga 2 Agent sharing the same binary and configuration language as a satellite/master instance.
Coming back to the question - does that then work on a deployment?
In terms of the zones.conf files, I’d suggest changes.
Master:
object Endpoint "icinga-master" {
//host is not needed
}
object Zone "master" {
endpoints = [ "icinga-master" ]
}
object Endpoint "icinga-sat-1" {
host = "icinga-sat-1"
}
object Zone "satellite-zone-1" {
endpoints = [ "icinga-sat-1" ]
parent = "master"
}
object Zone "global-templates" {
global = true
}
object Zone "director-global" {
global = true
}
Satellite:
object Endpoint "icinga-master" {
host = "XXX"
port = "5665"
}
object Zone "director-global" {
global = true
}
object Endpoint "icinga-sat-1" {
host = "icinga-sat-1"
}
object Zone "satellite-zone-1" {
endpoints = [ "icinga-sat-1" ]
parent = "master"
}
object Zone "master" {
endpoints = [ "icinga-master" ]
}
object Zone "global-templates" {
global = true
}
object Endpoint "agent-FQDN" {}
object Endpoint "icinga-sat-1" {
//set the host attribute, if the agent should actively connect to the satellite
}
object Zone "satellite-zone-1" {
endpoints = [ "icinga-sat-1" ]
}
object Zone "agent-FQDN" {
endpoints = [ "agent-FQDN" ]
parent = "satellite-zone-1"
}
object Zone "global-templates" {
global = true
}
object Zone "director-global" {
global = true
}
Cheers,
Michael
Thanks @dnsmichi for clarify.
I’ll update my config.
in this case i have also Question about second Master config.
Should i create separate Topic?
Sounds interesting, you have an example for DSL and usage with ssh?
SSH can be rather complex, also in combination with the Director. Coming back to the original question, what exactly is not working with the agent in the Director?
Cheers,
Michael
the main question was answered
Icinga is working.
Another question was
Ah. Just shoot in here, same topic I’d say.
Okay
I want to install a second Master as failover. Is there any HowTo?
My first Questions:
The docs give a pretty good walkthrough:
https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#high-availability-master-with-clients
Basically it is:
A second DB is not really needed (unless you want some form of HA there to, with all its complications like master/slave, pacemaker, cluster ip and so on).
The masters automatically decide which one is writing to the database. You just have to configure the ido-mysql.conf on the second master like on the first master. They also automatically distribute the checks based on an algorithm.
As the second master connects to the first master (node wizard setup as satellite) the CA from the first master is used.
That’s all I can think of now. Hope I haven’t told something stupid/wrong here
Thanks, you were faster. I am fixing the online docs atm (formatting et al), so it may be a little unresponsive.
Thanks for explanation, I’ll try it.
So, i tested some cluster configs.
Now i created this config
Later i’ll create also Replications for satellite Hosts
All works fine.
Only i miss a flag on icinga2 node setup
statement to set custom local Endpoint name
or i overlook this
--zone arg The name of the local zone
--endpoint arg Connect to remote endpoint; syntax: cn[,host,port]
--parent_host arg The name of the parent host for auto-signing the csr; syntax: host[,port]
--parent_zone arg The name of the parent zone
--listen arg Listen on host,port
--ticket arg Generated ticket number for this request (optional)
--trustedcert arg Trusted master certificate file
--cn arg The certificates common name
--accept-config Accept config from master
--accept-commands Accept commands from master
--master Use setup for a master instance
--global_zones arg The names of the additional global zones to 'global-templates' and 'director-global'.
--disable-confd Disables the conf.d directory during the setup
That’s left out with the intention to follow the conventions with using the FQDN everywhere.
Cheers,
Michael
Ahh Okay, thanks for the Info.
Is there also a way to add more than one parent master/satellite Endpoints on icinga2 node setup
same like on icinga2 node wizard Add more master/satellite endpoints? [y/N]: