xi: host templates and inheritance

This support forum board is for support questions relating to Nagios xi, our flagship commercial network monitoring solution.
User avatar
inversecow
Posts: 44
Joined: Wed Sep 25, 2019 4:17 pm

xi: host templates and inheritance

Post by inversecow »

Ahoy folks,

At present we are making some use of host templates for basic UP/DOWN checks.
Also took the advice early and made a series of CONTACT GROUPs to help manage notification targets.
Specifically, the following:
  • - generic host template for UP/DOWN
    - contains syntax for check_icmp command
    - tied to a global / "parent" host-group, of which all "customer" hostgroups are children
    - users are instructed to USE the identified common host template to qualify for UP/DOWN monitoring

- three contact groups for each team of users
- TEAM-contacts: human users go in here, used to control access / visibility to registered assets per team (EG: hosts & services)
- TEAM-oncall: non-human mail-group CONTACT(s) for page-out email notifications
- TEAM-info: non-human mail-group CONTACT(s) for non-page-out email notifications
- had to do this as the "mail-group" CONTACT entities will never "login" to xi, so xi level HTML based emails never worked to notify them
- found we had to rely on the underlying nagios / OS mailserver (EG: postfix) to broadcast notifications to email plant

This works really well for us, to ensure all registered hosts are getting consistent UP/DOWN monitoring (assuming they "used" the right template at host ADD).
We do have issues with our users occasionally missing the important step of adding the right contact groups (so they "lose" visiblity of hosts after they leave the HOST record).
Some of my users now want to take it another step, with regards to assigning a contact group, which is inherited.

At present, they have two separate host templates to attempt this (one for the PING stuff, the other with the contact group stuff).
This is split out to accommodate a child template for LAB, vs one for PROD, etc. (for different contact groups), along with their basic TEAM-contacts contact group (for visibility of the new assets).

Apparently this works in one of our xi ENVs, but not any of the others (all at ver 5.8.2).

To that end, I have had a bit of a "montage" of learning about templates, inheritance, etc.
Thus, I understand that host templates are tied to HOST records, *not HOST GROUPs*.
I might tie a host template to a host group, but it still needs to be USEd by a host record (EG: at add time) in order to be leveraged / applied.

All this to say, I would like to think I understand how this should work, but it does not appear to manifest in the testing results.

From what I have observed in other parts of xi, inheritance seems to work well enough for partial records.

Is what I am driving for (HOST record attribute inheritance based on assigned HOST TEMPLATEs) possible?
Possibly I have my sequencing wrong in how I am nesting templates?
What is the value of having "Manage Host Groups" button inside a host template (if it must be USEd at the HOST record level to be applicable?)
Does inheritance hold for nesting host templates (EG: parent template with check settings, child templates with various contact group definitions)?

---

For my test case, I have the following (see at bottom for sample definitions):

- test user (regular, not admin)
- test user is a member of a test contact group
- several host records registered properly & set to ACTIVE
- test user does not "see" any hosts (or services) by default (as their contact group is not mapped to any resources)

- test host template (test_generic-all-hosts-check)
- test host template (test_group_contacts_template)

# initial state

- host record exists with associations as described in "control scenario"

# control scenario (how we do it today)

- manually assign to host records:
- test host template (test_generic-all-hosts-check)
- test contact group to host(s) records directly
- the involved nodes become visible to my test user within xi

RESULT: SUCCESS (hosts become visible as does the service monitors associated to them)

# experiment scenarios

## contact group only via separately assigned host templates

- assign host templates to host record(s)
- test host template (for test contact group)

- apply config & wait ~5 mins to permit "linking"
- verify visibility of host records with test user

RESULT: FAILED (expected, check-in flops due to missing required specifications / parameters for conducting the HOST check)

## ping & contact group via separately assigned host templates

- assign host templates to host record(s)
- test host template (test_generic-all-hosts-check)
- test host template (test_group_contacts_template)

- apply config & wait ~5 mins to permit "linking"
- verify visibility of host records with test user

RESULT: FAILED (test host never becomes "visible" for my test user), does inherit required values for UP/DOWN monitor

## ping & contact group via assignment of child host template

- update test host template (test_generic-all-hosts-check)
- nest test host template (test_group_contacts_template) within test host template (test_generic-all-hosts-check) (via Manage Templates button)

- assign host template (test_generic-all-hosts-check) to host record(s)

- apply config & wait ~5 mins to permit "linking"
- verify visibility of host records with test user

RESULT: FAILED (test host never becomes "visible" for my test user), does inherit required values for UP/DOWN monitor

## ping & contact group via assignment of child host template

- update test host template (test_group_contacts_template)
- nest test host template (test_generic-all-hosts-check) within test host template (test_group_contacts_template) (via Manage Templates button)

- assign host template (test_group_contacts_template) to host record(s)

- apply config & wait ~5 mins to permit "linking"
- verify visibility of host records with test user

RESULT: FAILED (test host never becomes "visible" for my test user), does inherit required values for UP/DOWN monitor

---

host template: UP/DOWN ACTIVE check attributes

Code: Select all

define host {
    name                            test_generic-all-hosts-check
    check_command                   check-host-alive!!!!!!!!
    initial_state                   o
    max_check_attempts              5
    check_interval                  5
    retry_interval                  1
    active_checks_enabled           1
    check_period                    24x7
    check_freshness                 1
    freshness_threshold             240
    event_handler_enabled           1
    low_flap_threshold              25
    high_flap_threshold             50
    flap_detection_enabled          1
    process_perf_data               1
    retain_status_information       1
    retain_nonstatus_information    1
    notification_interval           2
    notification_period             24x7
    notification_options            d,r,
    notifications_enabled           1
    register                        0
}
host template: TEAM-contacts attributes

Code: Select all

define host {
    name                            test_group_contacts_template
    use                             test_generic-all-hosts-check
    contact_groups                  team-testing
    register                        0
}
contact template: team-testing attributes

Code: Select all

define contactgroup {
    contactgroup_name    team-testing
    alias                team-testing
    members              team_lead,team_member
}
command: check-host-alive attributes

Code: Select all

define command {
    command_name    check-host-alive
    command_line    $USER1$/check_icmp -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 5
}
host: record attributes

Code: Select all

define host {
    host_name          hostname.fqdn
    use                test_group_contacts_template   <-- NOTE: This value would change based on what HOST TEMPLATE I associated with the HOST record.
    address            hostname.fqdn
    hostgroups         customer,customer_location_cage_team-servers,customer_location_cage_team-servers,location_cage,team-servers,team-servers
    contact_groups     team-contacts,team-info
    icon_image         linux-server.png
    statusmap_image    linux-server.png
    register           1
}
“And who better understands the Unix-nature?” Master Foo asked.
“Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Master Foo - The ten thousand Lines
Unix Koans of Master Foo
User avatar
pbroste
Posts: 1288
Joined: Tue Jun 01, 2021 1:27 pm

Re: xi: host templates and inheritance

Post by pbroste »

Hello @inversecow

Thanks for reaching out about host and services templates.

Reviewing your post, we see that you have in-depth questions about templates and want to provide the support article to review it.

https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectinheritance.html

To start with want hit on the questions that you have:

Possibly I have my sequencing wrong in how I am nesting templates?

I found this from another post and stole it, and does a pretty good job with summarizing.
I usually have difficulty visualizing this correctly But in terms, whatever is at the end of the chain takes precedence. Let's look at some templates that exist by default and made-up hosts.
  • General Template -> Linux-server -> MyHost
As you go further right, you override whatever is to the left. So that when you get down to the actual host, you can always override anything that was applied via template.
What is the value of having "Manage Host Groups" button inside a host template
(if it must be USEd at the HOST record level to be applicable?)


By default, I believe that this is an option that we don't currently have that logic built-in to the program code.

Is what I am driving for (HOST record attribute inheritance based on assigned HOST TEMPLATEs) possible?

There are several ways to apply inheritance, and you will want to look at additive, implied, and multiple inheritance options. I did not see host record attribute inheritance listed. You may wish to apply inheritance differently.

I also want to touch on some methods others use to create and check host and services templates.
  • There's an xi Component available on Nagios Exchange called "View Object Configuration" that lets you see the effective settings once you've created a Host or Service
  • Configuration Wizard: Bulk Host Cloning and Import from a list
  • View /usr/local/nagios/var/objects.cache file to see the final results from template inheritance
This provides a good foundation; please let us know if you have questions going forward.

Thanks,
Perry
User avatar
inversecow
Posts: 44
Joined: Wed Sep 25, 2019 4:17 pm

Re: xi: host templates and inheritance

Post by inversecow »

Ahoy Perry (and team)!

Thank you for the review on this matter, and suggestions.

In the end, I managed to arrive to a successful configuration, that suits my users scenario.

In short, it was a combo of your confirmation on gradual scope for templates (General Template -> Linux-server -> MyHost), and some old-fashioned RTFM (from the link you provided).

What squared things up nicely in the end, was that in our current "production method" for adding hosts to monitoring, we instruct users to add "contact_groups" explicitly at HOST ADD time.
While this sounds innocent enough on the surface, I came to realize (after reading about Local Variables vs. Inherited Variables), that we may well be overriding what we would otherwise expect to be inherited.
To point, once I removed the HOST level contact_group attributes, the HOST TEMPLATE inherited values applied as expected.

We further resolved the disparity between the "it works here, but not over here" (between two xi ENVs).
In that case, my users had inadvertently leveraged Additive Inheritance for these contact_groups (between their HOST TEMPLATE, and the ones explicitly defined at the HOST record level).
This was not at all apparent, until we "fell over" it while grepping files on-disk.

Thus, several problems resolved, very neat for a "read-only" Friday!

I do have some "feature-requests" for consideration:

- Enable the "Manage Host Groups" button to do something (EG: add / remove HOST TEMPLATE attributes to member nodes of the HG) OR remove the button from the HOST TEMPLATE interface.

Adding the functionality would be preferable from an operational perspective, but understandably the removal of the button may be faster / easier from a DEV perspective.

- Add something to denote contact / contact_group attributes are ADDITIVE in nature (when viewing the host record within xi).

Granted if you "view config" you will see it (but only if you are sharp for 1 character differences on that little "+".)
Otherwise, when looking at it from the standard xi views, a contact / contact_group association looks the same (regardless if it had the "+" flag set or otherwise.)

Happy 444 Friday, and a great weekend to all! :-D
“And who better understands the Unix-nature?” Master Foo asked.
“Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Master Foo - The ten thousand Lines
Unix Koans of Master Foo
User avatar
pbroste
Posts: 1288
Joined: Tue Jun 01, 2021 1:27 pm

Re: xi: host templates and inheritance

Post by pbroste »

Hello @inversecow

Excellent details on the write-up on how you went about resolving the issue.

I've submitted a feature request to add this ability to the product on your behalf.

Please keep in mind that the decision to implement an enhancement is at
the discretion of our development team.

I will go ahead and lock this support case.

Thanks,
Perry