Re: Serial Key Nagios Xi
Leana Eckes
Nagios /ˈnɑːɡiːoʊs/ is an event monitoring system which offers monitoring and alerting services for servers, switches, applications and services. It alerts users when things go wrong and alerts them a second time when the problem has been resolved.
Nagios was originally designed to run under Linux, but it also runs on other Unix variants. It is free software licensed under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.
On 16 January 2014, Nagios Enterprises redirected the nagios-plugins.org domain to a web server controlled by Nagios Enterprises without explicitly notifying the Nagios Plugins community team the consequences of their actions.[6][7] Nagios Enterprises replaced the nagios-plugins team with a group of new, different members.[8] The community team members who were replaced continued their work under the name Monitoring Plugins along with a different website with the new domain of monitoring-plugins.org.[9]
Nagios XI is a proprietary interface using Nagios Core as the back-end, written and maintained by the original author, Ethan Galstad, and Nagios Enterprises. CentOS and RHEL are the currently supported operating systems. It combines Nagios Core with other technologies. Its main database and the ndoutils module that is used alongside Nagios Core use MySQL. While the front-end of Nagios Core is mainly CGI with some PHP,[14] most of the Nagios XI front-end and back-end are written in PHP including the subsystem, event handlers, and notifications, and Python is used to create capacity planning reports and other reports. RRDtool and Highcharts are included to create customizable graphs that can be displayed in dashboards.
Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.
The system running this cookbooks should have a role named 'monitoring' so that NRPE clients can authorize monitoring from that system. This role name is configurable via an attribute. See --Attributes-- below.
The config file contains the Nagios configuration options. Consult the nagios documentation for available settings and allowed options. Configuration entries of which multiple entries are allowed, need to be specified as an Array.
node['nagios']['server']['install_method'] - whether to install from package or source. Default chosen by platform based on known packages available for Nagios: debian/ubuntu 'package', redhat/centos/scientific: source
node['nagios']['server']['install_yum-epel'] - whether to install the EPEL repo or not (only applies to RHEL platform family). The default value is true. Set this to false if you do not wish to install the EPEL RPM; in this scenario you will need to make the relevant packages available via another method e.g. local repo, or install from source.
node['nagios']['http_port'] - port that the Apache/Nginx virtual site should listen on, determined whether ssl is enabled (443 if so, otherwise 80). Note: You will also need to configure the listening port for either NGINX or Apache within those cookbooks.
node['nagios']['default_user_name'] - Specify a defaut guest user to allow page access without authentication. --Only-- use this if nagios is running behind a secure webserver and users have been authenticated in some manner. You'll likely want to change node['nagios']['server_auth_require'] to all granted. Defaults to nil.
node['nagios']['templates'] - These set directives in the default host template. Unless explicitly overridden, they will be inherited by the host definitions for each discovered node and nagios_unmanagedhosts data bag. For more information about these directives, see the Nagios documentation for host definitions.
The server recipe sets up Apache as the web front end by default. This recipe also does a number of searches to dynamically build the hostgroups to monitor, hosts that belong to them and admins to notify of events/alerts.
Installs pagerduty plugin for nagios. If you only have a single pagerduty key, you can simply set a node['nagios']['pagerduty_key'] attribute on your server. For multiple pagerduty key configuration see Pager Duty under Data Bags.
You can define pagerduty contacts and keys by creating nagios_pagerduty data bags that contain the contact and the relevant key. Setting admin_contactgroup to "true" will add this pagerduty contact to the admin contact group created by this cookbook.
Create data bag items in the users data bag for each administer you would like to be able to login to the Nagios server UI. Pay special attention to the method you would like to use to authorization users (openid or htauth). See --Users-- and --Atttributes--
NRPE commands are defined in recipes using the nrpe_check LWRP provider in the nrpe cookbooks. For base system monitoring such as load, ssh, memory, etc you may want to create a cookbook in your environment that defines each monitoring command via the LWRP.
With NRPE commands created using the LWRP you will need to define Nagios services to use those commands. These services are defined using the nagios_services data bag and applied to roles and/or environments. See --Services--
[COOK-3774]Services can be limited to run on nagios servers in specific chef environments by adding a new "activate_check_in_environment" key to the services data bag. See the Services section of the readme for an example.
This is a major release that refactors a significant amount of the service configuration to use data bags rather than hardcoding specific checks in the templates. The README describes how to create services via data bags.
The main incompatibility and breaking change is that the default services that are monitored by Nagios is reduced to only the "check-nagios" service. This means that existing installations will need to start converting checks over to the new data bag entries.
11.3.2 passed this metric Contributing File Metric 11.3.2 failed this metric Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of , and your repo must contain a CONTRIBUTING.md file Cookstyle Metric 11.3.2 passed this metric No Binaries Metric 11.3.2 passed this metric Testing File Metric 11.3.2 failed this metric Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of , and your repo must contain a TESTING.md file Version Tag Metric 11.3.2 failed this metric Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of , and your repo must include a tag that matches this cookbook version number
sous-chefs Sous Chefs Details View Source View Issues Updated May 2, 2024 Created on February 26, 2010 Supported Platforms License Apache-2.0
This is a feature release. Please note that while this release is backward-compatible, we did make updates to the nagios headers. If you are using any NEB modules (incl. NDOUtils, Mod Gearman, or Livestatus), you will need to recompile these modules with the new nagios-4.5.0 headers. Please see the Changelog for a full list of changes.
I have a custom field called _tier, which can have the state tier[1-4]. We would like this to map to P[1-4] in the nagios integration, but cannot figure out how this is done via opsgenie/oec/opsgenie-nagios/send2opsgenie. Maybe I can use it as a tag, but then I cant figure out how that is mapped in Nagios Integration in OpsGenie.
For example, if you are sending the values as tags "tier-1", "tier-2"..... You should be able to set conditions on the filter to match the particular label and set priority accordingly (as shown in the example screenshot below)
PagerDuty integrations require a Manager base role or higher for account authorization. If you do not have this role, please reach out to an Admin or Account Owner within your organization to configure the integration.
Integrating with Global Event Routing enables you to route events to specific services based on the payload of the event from Nagios Core. If you would like to learn more, please visit our article on Global Event Routing.
3. Click on the name of the ruleset you would like to use and click on the arrow next to Incoming Event Source to display the Integration key information. Copy your Integration Key and keep it in a safe place for later use. When you have finished setting up the integration in Nagios Core, you will return to this interface to specify how to route events from Nagios Core to services in PagerDuty.
Note: If your team has already integrated using Global Event Routing, you can verify by checking for the PagerDuty Event Rules Integration Key (found in step 3 above) in an existing configuration file. You can then use the existing integration and pipe Nagios Core events into your service by writing new Global Event Rules for your service.
If you are creating a new service for your integration, please read our documentation in section Configuring Services and Integrations and follow the steps outlined in the Create a New Service section.
4. Enter the integration key (generated in the In PagerDuty section above) into the pager field. If you would like to integrate Nagios Core with multiple PagerDuty services at once, you can use Global Event Routing (instructions in the In PagerDuty section above) or you can read our article on integrating directly with multiple PagerDuty services.
6. Skip this step if you are using a Debian-based distribution. If you are using a RHEL-based distribution, you will need to edit the Nagios Core config to load the PagerDuty config. To do this, open /etc/nagios/nagios.cfg and add this line to the file:
7fc3f7cf58