WAS THIS PAGE HELPFUL? Leave Feedback
Q: What configuration objects are associated with an auto-registered host?
A: Multiple connections will be made during auto-registration:
- Common practice is to have the host profile specified by the client be assigned and applied to the host. If the client does not specify a host profile, the server will assign a host profile based on the default_host_profile option in the config/register_agent.properties file. The server can modify these standard choices via the host_profile_to_assign() routine in a customized version of the AutoRegistration.pm module.
- Any service profiles associated with the applied host profile will be applied to the host.
- The client can optionally specify one additional service profile to be applied to the host.
- Host and service externals from the host profile and from the services applied to the host will be copied to the configuration for the host. This is a critical link in how the individual GDMA options and service checks for the host are made known to the client to run its monitoring commands.
- The host will become a member of the hostgroup listed as default_hostgroup in the config/register_agent.properties file. If a more-complex setup is required, a customized version of the AutoRegistration.pm module can be used to return a list of host groups in the result of the hostgroups_to_assign() routine. If you truly don't want any auto-registered host to be a member of any hostgroup (probably not a practical setup), that can also be accomplished by having your custom version of the AutoRegistration.pm module have no hostgroups_to_assign() routine.
- If the host is not already a member of some Monarch configuration group, the host will become a member of the Monarch configuration group listed as default_monarch_group in the config/register_agent.properties file. This standard behavior can be modified via a customized version of the AutoRegistration.pm module, where the monarch_groups_to_assign() routine can be used to determine a list of Monarch groups to which the host should be assigned.
- Also see the assign_monarch_groups_to_existing_group_hosts option in the config/register_agent.properties file, if you need to allow a host which is already assigned to some Monarch configuration group to also be assigned to the Monarch configuration group(s) determined by the auto-registration logic.
The host must be assigned to at least one Monarch group in order to have externals built and published on the server, where the client can subsequently find them. Some customers might want to create and distribute the client host-configuration files via some other mechanism. A future version of GDMA will include the ability to assign an empty string to the default_monarch_group option in the config/register_agent.properties file, to suppress the assignment of the host to a Monarch group, for all hosts. In the meantime, the same effect can be achieved in a custom version of the AutoRegistration.pm module by either having the monarch_groups_to_assign() routine return an empty list of Monarch groups, or having no monarch_groups_to_assign() routine in your package. - Administration of the Monarch configuration group can be made easier by manually assigning at least one hostgroup the host will be a member of to the Monarch group. Then all hosts that are auto-registered and that are a member of such a hostgroup won't have to be directly assigned to the Monarch group; the indirect association will suffice. This is generally the preferred setup, as it keeps the configuration much simpler.