The initial health monitoring configuration is handled during the installation and configuration of your cluster, and most monitoring parameters have default settings. However, you can set or modify these at any time.

To configure a service monitoring setting:

1. Click the Clusters tab, and select the service instance you want to modify.
2. (This can be any of the services for which monitoring is provided, or the Cloudera Manager management service.)
3. Click the Configuration tab.
4. Expand the Service-Wide category.
5. Click the Monitoring category.
6. Under the Monitoring category, select the category of properties you want to change (these are organized as service-wide or by role).
7. Configure the property.
8. Click Save Changes to commit the changes.

To configure a host monitoring setting:

1. Click the Hosts tab.
2. To modify the settings for an individual host, select the host.
3. Click the Configuration tab.
4. Expand the Service-Wide category.
5. Click the Monitoring category.
6. Configure the property.
7. Click Save Changes to commit the changes. You can add a note that will be included with the change in the Configuration History.

Depending on the service or role you select, and the configuration category, you can enable or disable health tests, determine when health tests cause alerts, or determine whether specific health tests are used in computing the overall health of a role or service. In most cases you can disable these "roll-up" health tests separately from the individual health tests.

As a rule, a health tests whose result is considered "Concerning" or "Bad" will be forwarded as an event to the Event Server. That includes health tests whose results are based on configured Warning or Critical thresholds, as well pass-fail type health tests. An event will also be published when the health test result returns to normal.

You can control when an individual health test will be forwarded as an event or an alert by modifying the threshold values for the relevant health test.

Cloudera Manager can perform threshold-based monitoring of free space in the various directories on the hosts it monitors — such as log directories or checkpoint directories (for the Secondary NameNode).

These thresholds can be set in one of two ways — as absolute thresholds (in terms of MiB and GiB, and so on) or as percentages of space. As with other threshold properties, you can set values that will trigger events at both the Warning and Critical levels.

If you set both thresholds, the Absolute Threshold setting will be used.

These thresholds are set under the Monitoring category of the Configuration page for each service.

The Activity Monitor monitors the MapReduce MRv1 jobs running on your cluster. This also includes the higher-level activities, such as Pig, Hive, and Oozie workflows that run as MapReduce tasks.

You can monitor for slow-running jobs or jobs that fail, and alert on these events. To detect jobs that are running too slowly, you must configure a set of activity duration rules that specify what jobs to monitor, and what the limits on duration are for those jobs. A "slow activity" event occurs when a job exceeds the duration limit configured for it in an activity duration rule. Activity duration rules are not defined by default; you must configure these rules if you want to see events for jobs that exceed the duration defined by these rules.

To configure Activity Monitor settings for MapReduce:

1. Click the Clusters tab.
2. Select the MapReduce service instance.
3. Click the Configuration tab.
4. Expand the Service-Wide category.
5. Click the Monitoring category.
6. Specify one or more activity duration rules.
7. Click Save Changes to commit the changes.

foo=10
bar=20

foo.*=10
bar=20

foo.*=10
bar=20
baz=30
.*=60

You can configure the visibility of the YARN application monitoring results.

You can configure the visibility of the Impala query results and the size of the storage allocated to Impala query results.

You can enable or disable the forwarding of selected log events to the Event Server. This is enabled by default, and is a service-wide setting (Enable Log Event Capture) for each service for which monitoring is provided. You can enable and disable event capture for CDH services or for the Cloudera Management Service.

To enable or disable log event capture:

1. Click the Clusters tab, and select the service instance you want to modify.
2. Click the Configuration tab.
3. Expand the Service-Wide category.
4. Click the Monitoring category.
5. Modify the Enable Log Event Capture setting.
6. Click Save Changes to commit the changes. You can add a note that will be included with the change in the Configuration History.

You can also modify the rules that determine how log messages are turned into events. Editing these rules is not recommended.

For each role, there are rules that govern how its log messages are turned into events by the custom log4j appender for the role. These are defined in the Rules to Extract Events from Log Files property for each HDFS, MapReduce and HBase role, and for ZooKeeper, Flume agent, and monitoring roles as well.

To configure which log messages become events:

1. Click the Clusters tab, and select the service instance you want to modify.
2. Expand the Service-Wide category.
3. Click the Monitoring category.
4. Select the role group for the Role for which you want to configure log events, or search for "Rules to Extract Events from Log Files". Note that for some roles there may be more than one role group, and you may need to modify all of them. The easiest way to ensure that you have found all occurrences of the property you need to modify is to search for the property by name. Cloudera Manager will show all copies of the property that match the search filter.
5. Edit these rules as needed.
6. Click Save Changes to commit the changes.

A number of useful rules are defined by default, based on Cloudera's experience supporting Hadoop clusters. For example:

• The line {"rate": 10, "threshold":"FATAL"}, means log entries with severity FATAL should be forwarded as events, up to 10 a minute.
• The line {"rate": 0, "exceptiontype": "java.io.EOFException"}, means log entries with the exception java.io.EOFException should always be forwarded as an event.

The syntax for these rules is defined in the Description field for this property: the syntax lets you create rules that identify log messages based on log4j severity, message content matching, and/or the exception type. These rules must result in valid JSON.

  Note: Editing these rules is not recommended. Cloudera Manager provides a default set of rules that should be sufficient for most users.