NagiosXI 5.7 custom variables in notifications best practice

This support forum board is for support questions relating to Nagios XI, our flagship commercial network monitoring solution.
Locked
dfmco
Posts: 257
Joined: Wed Dec 04, 2013 11:05 am

NagiosXI 5.7 custom variables in notifications best practice

Post by dfmco »

I am trying to populate the "client" variable from Nagios to Pagerduty. I know I can do this from pdagent with the -f flag but do you know what variable I can use or where I can set that variable in Nagios itself?

Here is a sample of my notification command:
/usr/share/pdagent-integrations/bin/pd-nagios -n host -k $CONTACTPAGER$ -t "$NOTIFICATIONTYPE$" -f HOSTNAME="$HOSTNAME$" -f HOSTSTATE="$HOSTSTATE$" -f client="$??????$" -f client_url="%xiserverurl%"

I would like "client" to be set to the client name for the instance. I have never seen this set anywhere in Nagios so I was hoping for some direction in the best place to set this variable and even better, if it could be set via a script. I currently have the "pager" variable defined in the "pagerduty" contact and could likely set it there but I would prefer that I get some guidance on best practices. I have never seen a way to set any variables via the API so if this is not possible, could I add this as a request for a future version?

I would also like to set "client_url" to the server name. I found the %xiserverurl% in this document:
https://assets.nagios.com/downloads/nag ... =209668515
It is not the correct format that I can tell. Is there a way to reference this in a notification? Currently we use IP addresses for the server url in the config as we do not have DNS at these sites. Will this variable just return that IP address or is there a way to set it in the gui to a name that will not resolve but still not break the system? Basically, if I change the Nagios URL, will it break anything? Is there an alternate method to get the real server hostname from the OS and add it to a notification?
benjaminsmith
Posts: 5324
Joined: Wed Aug 22, 2018 4:39 pm
Location: saint paul

Re: NagiosXI 5.7 custom variables in notifications best prac

Post by benjaminsmith »

Hi @dfmco,

Hopefully, I undestoond the question correctly, just let me know if I am missing anything.

For the first question, I believe using a custom variable set at the host level would work in this case. You can set these in the Core Confgiuration Manager by selecting the host and then clicking on the Misc Setting Tab. Howver, you can use the API as well. Take a look at the PUT command fora host or service in the Config API.

For example, the following command would add a new customer variable called apivariable to a host called Testhost. All custom variables need to be prefixed with an underscores to avoid any name collisions.

Code: Select all

curl -XPUT "https://192.168.23.113/nagiosxi/api/v1/config/host/TestHost?apikey=sCWXTQ3rHtm483AgRUUtLi04v5ECCVmktCCGoU8mINpPPflWafJbRKeGO8fGjUh6&pretty=1&_apivariable=testhoststring&applyconfig=1"
For the second question, would the IP address work? It's available as a standard Nagios Macro that you can call to your pager duty script.

https://assets.nagios.com/downloads/nag ... olist.html

Some useful documentation links for more details.
https://support.nagios.com/kb/article.php?id=509out.
https://assets.nagios.com/downloads/nag ... tvars.html

Let me know if you have more questions or need clarification on anything.

Best Regards,
Benjamin
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.

Be sure to check out our Knowledgebase for helpful articles and solutions!
dfmco
Posts: 257
Joined: Wed Dec 04, 2013 11:05 am

Re: NagiosXI 5.7 custom variables in notifications best prac

Post by dfmco »

We have multiple Nagios servers that send alerts to a single pagerdury instance. So the purpose of the variable is to send to pagerduty to identify the location of the particular site in the alert. The variable that is available on the pagerduty side is called "client". I need to map a variable called "client" to the name of the client that Nagios is running (example Joe's Fish and Chips). I don't want to map this variable on each monitored host for a client. It makes a lot more sense to set it globally for that particular client. I currently set a "free variable" in the contact called "pagerduty" that I pass in the custom alert that points to the pagerduty api key so I am certain I can add an additional free variable called "client" with a value of "Joe's Fish and Chips" there but I wanted to know if there is a better place to define such a variable as it can likely be used for other purposes outside of the pagerduty alerts.

Here is the command that I send. I would like to set client so that it fills in the client that that Nagios XI serves.

Code: Select all

/usr/share/pdagent-integrations/bin/pd-nagios -n host -k $CONTACTPAGER$ -t "$NOTIFICATIONTYPE$" -f HOSTNAME="$HOSTNAME$" -f HOSTSTATE="$HOSTSTATE$" -f client="$CLIENT$"
Example1:
Nagios server named joe_nagios is installed at Joe's Fish and Chips. His printer goes down and sends an alert to pager duty. That alert has a variable named "client" that is set to Joe's Fish and Chips. Pager duty reads the alert and sends out a text that says "Joe's Fish and Chips Printer1 is down"

Example2:
Nagios server named fred_nagios is installed at Fred's Sporting Goods. His workstation goes down and sends an alert to the same pager duty instance as above. That alert has a variable named "client" that is set to Fred's Sporting Goods. Pager duty reads the alert and sends out a text that says "Fred's Sporting Goods workstation1 is down"

In a nutshell, where is the best place in Nagios that I could create a new variable called "CLIENT" and set it to a value of "Joe's Fish and Chips" and have it be available to a custom alert command?

For the second question, there is an existing variable called %xiserverurl% that returns the server name. I would like this value in my custom alert command but if I call that variable like this:

Code: Select all

/usr/share/pdagent-integrations/bin/pd-nagios -n host -k $CONTACTPAGER$ -t "$NOTIFICATIONTYPE$" -f HOSTNAME="$HOSTNAME$" -f HOSTSTATE="$HOSTSTATE$" -f client_url="%xiserverurl%"
It fails because %xiserverurl% is not valid in this context (custom alert command). Is there a different way to reference %xiserverurl% in a notification command? If not, is there another way I can access the Linux OS server name or Nagios server name inside of Nagios to use in the custom notification command?

Does that help? I hope what I am asking is clear. Thanks for your help!
benjaminsmith
Posts: 5324
Joined: Wed Aug 22, 2018 4:39 pm
Location: saint paul

Re: NagiosXI 5.7 custom variables in notifications best prac

Post by benjaminsmith »

Hi @dfmco

Thank you, that is very helpful. And I think using a free variable, called _client, to store this would work out for you. You can use the Bulk Mods Tool to apply this across more than one object. Go to Configure > Tools > Bulk Modification Tool, and then create a new variable and apply this across all the hosts for that particular client.
bulk-mods-free-variable.png
Then the host notication command would look like,

Code: Select all

/usr/share/pdagent-integrations/bin/pd-nagios -n host -k $CONTACTPAGER$ -t "$NOTIFICATIONTYPE$" -f HOSTNAME="$HOSTNAME$" -f HOSTSTATE="$HOSTSTATE$" -f client="$_HOSTCLIENT$"
The %xiserverurl% variable does not work since those tags are for the notification templates in XI that use the phpmailer(email) notifications.

For the server URL, you can use the free variable here to pass that along as well, or if this is a global setting, you can create a macro in the resource.cfg. Settting user macros is explained in the following guide.

Understanding User Macros

Hope that helps. Please let me know if you have more questions. There's a lot going on here since we are utilizing both Nagios Core and XI features.

--Benjamin
You do not have the required permissions to view the files attached to this post.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.

Be sure to check out our Knowledgebase for helpful articles and solutions!
Locked