YAVA Ambari ver 2.2 - User Guide


Hadoop is a large-scale, distributed data storage and processing infrastructure using clusters of commodity hosts networked together. Monitoring and managing such complex distributed systems is a non-trivial task. To help you manage the complexity, Apache Ambari collects a wide range of information from the cluster’s nodes and services and presents it to you in an easy-to-read and use, centralized web interface, Ambari Web.

Ambari Web displays information such as service-specific summaries, graphs, and alerts. You use Ambari Web to create and manage cluster and to perform basic operational tasks such as starting and stopping services, adding hosts to your cluster, and updating service configurations. You also can use Ambari Web to perform administrative tasks for your cluster such as enabling Kerberos security and performing Stack upgrades.


Ambari Login

Figure 1. Ambari Login



The Ambari Server serves as the collection point for data from across your cluster. Each host has a copy of the Ambari Agent – either installed automatically by the Install wizard or manually – which allows the Ambari Server to control each host.

 Ambari Architecture

Figure 2. Ambari Architecture


Ambari Web is a client-side JavaScript application, which calls the Ambari REST API (accessible from the Ambari Server) to access cluster information and perform cluster operations. After authenticating to Ambari Web, the application authenticates to the Ambari Server. Communication between the browser and server occurs asynchronously via the REST API.

The Ambari Web UI periodically accesses the Ambari REST API, which resets the session timeout. Therefore, by default, Ambari Web sessions do not timeout automatically. You can configure Ambari to timeout after a period of inactivity.

Ambari Sessions

Figure 3. Ambari Sessions

1.2.Accessing Ambari Web

Typically, you start the Ambari Server and Ambari Web as part of the installation process. If Ambari Server is stopped, you can start it using a command line editor on the Ambari Server host machine. Enter the following command:

ambari-server start

To access Ambari Web, open a supported browser and enter the Ambari Web URL:


Enter your user name and password. If this is the first time Ambari Web is accessed, use the default values, admin/admin.

These values can be changed, and new users provisioned, using the Manage Ambari option.

 Accessing Ambari Web

Figure 4. Accessing Ambari Web

For more information about managing users and other administrative tasks, see Administering Ambari.

2.Monitoring and Managing Your Cluster

2.1.Cluster Dashboard

Use the Dashboard to view the operating status of your cluster. Each metrics widget displays status information for a single service in your Yava cluster. The Dashboard displays all metrics for the HDFS, YARN, HBase, and Storm services, and cluster-wide metrics by default.  You can add and remove individual widgets, and rearrange the Dashboard by dragging and dropping each widget to a new location in the dashboard.

View Cluster Dashboard

Figure 5. View Cluster Dashboard

Each Service installed in your cluster also has a Service-specific dashboard. Refer to the Managing Services
Modifying the Service Dashboard section for more information.

Scanning Service Status

Notice the color of the dot appearing next to each component name in a list of components, services or hosts. The following colors and actions indicate service status:

Status Indicators


Figure 6. Status IndicatorsClick the service name to open the Services screen, where you can see more detailed information on each service.

Widget Descriptions

The Dashboard includes metrics for the following services. View Metrics that indicate the operating status of your cluster on the Ambari Dashboard. Each metrics widget displays status information for a single service in your Yava cluster. The Ambari Dashboard displays all metrics for the HDFS, YARN, HBase, and Storm services, and cluster-wide metrics by default. You can add and remove individual widgets, and rearrange the dashboard by dragging and dropping each widget to a new location in the dashboard.

Metrics data for Storm is buffered and sent as a batch to Ambari every five minutes. After adding the Storm service, anticipate a five-minute delay for Storm metrics to appear.

The Ambari Dashboard includes metrics for the following services:


Ambari Service Metrics and Descriptions

Figure 7.a. Ambari Service Metrics and Descriptions

Ambari Service Metrics and Descriptions

Figure 7.b. Ambari Service Metrics and Descriptions

Widget Descriptions

To see more detailed information about a service, hover your cursor over a Metrics widget.
More detailed information about the service displays, as shown in the following example:


Widget Details

Figure 8. Widget Details


  • To remove a widget from the mashup, click the white X.
  • To edit the display of information in a widget, click the pencil

Widget Details

The HDFS Links and HBase Links widgets for which links to more metrics information, such as thread stacks, logs and native component UIs are available. For example, you can link to NameNode, Secondary NameNode, and DataNode components for HDFS, using the links shown in the following example:


Linking to Service UIs

Figure 9. Linking to Service UIs


Choose the More drop-down to select from the list of links available for each service. The Ambari Dashboard includes additional links to metrics for the following services:


Link to More Metrics for Yava Services

Figure 10. Link to More Metrics for Yava Services

Linking to Service UIs

Cluster-wide metrics display information that represents your whole cluster. The Ambari Dashboard shows the following cluster-wide metrics:


Viewing Cluster-Wide Metrics

Figure 11. Viewing Cluster-Wide Metrics

Ambari Cluster-Wide Metrics and Descriptions

Figure 12. Ambari Cluster-Wide Metrics and Descriptions


  • To remove a widget from the dashboard, click the white X.
  • Hover your cursor over each cluster-wide metric to magnify the chart or itemize the widget display.
  • To remove or add metric items from each cluster-wide metric widget, select the item on the widget legend.
  • To see a larger view of the chart, select the magnifying glass icon.

Ambari displays a larger version of the widget in a pop-out window, as shown in the following example:


Metrics Cluster-Wide Widgets Large Version

Figure 13. Metrics Cluster-Wide Widgets Large Version


Use the pop-up window in the same ways that you use cluster-wide metric widgets on the dashboard.
To close the widget pop-up window, choose OK.

2.2.Modifying the Cluster Dashboard

You can customize the Ambari Dashboard in the following ways:

Adding a Widget to the Dashboard

To replace a widget that has been removed from the dashboard:

  1. Select the Metrics drop-down, as shown in the following example:
    Adding a Widget to the Dashboard

    Figure 14. Adding a Widget to the Dashboard

  2. Choose Add.
  3. Select a metric, such as Region in Transition.
  4. Choose Apply.

Resetting the Dashboard

To reset all widgets on the dashboard to display default settings:

  1. Select the Metrics drop-down, as shown in the following example:
    Resetting the Dashboard

    Figure 15. Resetting the Dashboard

  2. Choose Edit.
  3. Choose Reset all widgets to default.

Customizing Widget Display

To customize the way a service widget displays metrics information:

  1. Hover your cursor over a service widget.
  2. Select the pencil-shaped, edit icon that appears in the upper-right corner.
    The Customize Widget pop-up window displays properties that you can edit, as shown inthe following example.
    Customizing Widget Display

    Figure 16. Customizing Widget Display

  3. Follow the instructions in the Customize Widget pop-up to customize widget appearance. In this example, you can adjust the thresholds at which the HDFS Capacity bar chart changes color, from green to orange to red.
  4. To save your changes and close the editor, choose Apply.
  5. To close the editor without saving any changes, choose Cancel.

Not all widgets support editing.

2.3.Viewing Cluster Heatmaps

Heatmaps provides a graphical representation of your overall cluster utilization using simple color coding.

Viewing Cluster Heatmaps

Figure 17. Viewing Cluster Heatmaps


A colored block represents each host in your cluster. To see more information about a specific host, hover over the block representing the host in which you are interested. A pop-up window displays metrics about Yava components installed on that host. Colors displayed in the block represent usage in a unit appropriate for the selected set of metrics. If any data necessary to determine state is not available, the block displays “Invalid Data”. Changing the default maximum values for the heatmap lets you fine tune the representation. Use the Select Metric drop-down to select the metric type.

Cluster Metrics mode heatmaps

Figure 18. Cluster Metrics mode heatmaps


Heatmaps supports the following metrics:

Cluster Heatmaps Supports Metrics

Figure 19. Cluster Heatmaps Supports Metrics

3.Managing Hosts

Use Ambari Hosts to manage multiple Yava components such as DataNodes, NameNodes, NodeManagers and RegionServers, running on hosts throughout your cluster. For example, you can restart all DataNode components, optionally controlling that task with rolling restarts. Ambari Hosts supports filtering your selection of host components, based on operating status, host health, and defined host groupings.

3.1.Determining Host Status

A colored dot beside each host name indicates operating status of each host, as follows:

  • Red
    At least one master component on that host is down. Hover to see a tooltip that lists affected components.
  • Orange
    At least one slave component on that host is down. Hover to see a tooltip that lists affected components.
  • Yellow
    Ambari Server has not received a heartbeat from that host for more than 3 minutes.
  • Green
    Normal running state.

A red condition flag overrides an orange condition flag, which overrides a yellow condition flag. In other words, a host having a master component down may also have other issues. The following example shows three hosts, one having a master component down, one having a slave component down, and one healthy. Warning indicators appear next to hosts having a component down.


Status Host

Figure 20. Status Host

3.2.Performing Host-Level Actions

  • Hosts
    lists selected, filtered or all hosts options, based on your selections made using Hosts home and Filters.
  • Objects
    lists component objects that match your host selection criteria.
  • Operations
    lists all operations available for the component objects you selected.

For example, to restart DataNodes on one host:

  1. In Hosts, select a host running at least one DataNode.
  2. In Actions, choose Selected Hosts > DataNodes > Restart, as shown in the following image.
    Performing Host-Level Actions

    Figure 21. Performing Host-Level Actions

  3. Choose OK to confirm starting the selected operation.
  4. Optionally, use Monitoring Background Operationsto follow, diagnose or troubleshoot the restart operation.

3.3.Decommissioning Masters and Slaves

Decommissioning is a process that supports removing a component from the cluster. You must decommission a master or slave running on a host before removing the component or host from service. Decommissioning helps prevent potential loss of data or service disruption. Decommissioning is available for the following component types:

  • DataNodes
  • NodeManagers
  • RegionServers

Decommissioning executes the following tasks:

  • For DataNodes, safely replicates the HDFS data to other DataNodes in the cluster.
  • For NodeManagers, stops accepting new job requests from the masters and stops the component.
  • For RegionServers, turns on drain mode and stops the component.

How to Decommission a Component

To decommission a component using Ambari Web, browse Hoststo find the host FQDN on which the component resides.
Using Actions, select HostsComponent Type, then choose Decommission.

For Example

Decommission a Component

Figure 22. Decommission a Component


The UI shows “Decommissioning” status while steps process, then “Decommissioned” when complete.


UI Status

Figure 23. UI Status

3.4.How to Delete a Component

To delete a component using Ambari Web, on Hostschoose the host FQDN on which the component resides.

  1. In Components, find a decommissioned component.
  2. Stop the component, if necessary.
    Note : A decommissioned slave component may restart in the decommissioned state.
  3. For a decommissioned component, choose Deletefrom the component drop-down menu.
    Note : Restarting services enables Ambari to recognize and monitor the correct number of components.

Deleting a slave component, such as a DataNode does not automatically inform a master component, such as a NameNode to remove the slave component from its exclusion list. Adding a deleted slave component back into the cluster presents the following issue; the added slave remains decommissioned from the master’s perspective. Restart the master component, as a work-around.

3.5.Deleting a Host from a Cluster

Deleting a host removes the host from the cluster. Before deleting a host, you must complete the following prerequisites:

  • Stop all components running on the host.
  • Decommission any DataNodes running on the host.
  • Move from the host any master components, such as NameNode or ResourceManager, running on the host.
  • Turn Off Maintenance Mode, if necessary, for the host.

How to Delete a Host from a Cluster

  1. In Hosts, click on a host name.
  2. On the Host-Details page, select Host Actions drop-down menu.
  3. Choose Delete.

If you have not completed prerequisite steps, a warning message similar to the following one appears:

Delete a Host from a Cluster

Figure 24. Delete a Host from a Cluster

3.6.Setting Maintenance Mode

Maintenance Mode supports suppressing alerts and skipping bulk operations for specific services, components and hosts in an Ambari-managed cluster. You typically turn on Maintenance Mode when performing hardware or software maintenance, changing configuration settings, troubleshooting, decommissioning, or removing cluster nodes. You may place a service, component, or host object in Maintenance Mode before you perform necessary maintenance or troubleshooting tasks.

Maintenance Mode affects a service, component, or host object in the following two ways:

  • Maintenance Mode suppresses alerts, warnings and status change indicators generated for the object
  • Maintenance Mode exempts an object from host-level or service-level bulk operations

Explicitly turning on Maintenance Mode for a service implicitly turns on Maintenance Mode for components and hosts that run the service. While Maintenance Mode On prevents bulk operations being performed on the service, component, or host, you may explicitly start and stop a service, component, or host having Maintenance Mode On.

3.6.1 Setting Maintenance Mode for Services, Components, and Hosts

For example, examine using Maintenance Mode in a 3-node, Ambari-managed cluster installed using default options. This cluster has one data node, on host c6403. This example describes how to explicitly turn on Maintenance Mode for the HDFS service, alternative procedures for explicitly turning on Maintenance Mode for a host, and the implicit effects of turning on Maintenance Mode for a service, a component and a host.

3.7.Adding Hosts to a Cluster

To add new hosts to your cluster, browse to the Hosts page and select Actions >+Add New Hosts. The Add Host Wizard provides a sequence of prompts similar to those in the Ambari Install Wizard. Follow the prompts, providing information similar to that provided to define the first set of hosts in your cluster.

Adding Hosts to a Cluster

Figure 25. Adding Hosts to a Cluster

3.8.Rack Awareness

Ambari can manage Rack information for hosts. By setting the Rack ID, Ambari can display the hosts in heatmaps by Rack ID, as well users can filter & find hosts based on Rack ID on the Hosts page.

Rack Awareness

Figure 26. Rack Awareness

If HDFS is installed in your cluster, Ambari will pass this Rack ID information to HDFS via a topology script. Ambari generates a topology script at /etc/hadoop/conf/topology.py and sets the net.topology.script.file.name property in core-site automatically. This topology script reads a mappings file /etc/hadoop/conf/topology_mappings.data that Ambari automatically generates. When you make changes to Rack ID assignment in Ambari, this mappings file will be updated when you push out the HDFS configuration.

4.Managing Services

Use Services to monitor and manage selected services running in your Hadoop cluster. All services installed in your cluster are listed in the leftmost Services panel.

4.1.Starting and Stopping All Services

To start or stop all listed services at once, select Actions, then choose Start All or Stop All, as shown in the following example:

Starting and Stopping All Services

Figure 27. Starting and Stopping All Services

4.2.Adding a Service

The Ambari install wizard installs all available Hadoop services by default. You may choose to deploy only some services initially, then add other services at later times. For example, many customers deploy only core Hadoop services initially. Add Service supports deploying additional services without interrupting operations in your Hadoop cluster. When you have deployed all available services, Add Service displays disabled.
For example, if you are using Yava 2.2 Stack and did not install Falcon or Storm, you can use the Add Service capability to add those services to your cluster.
To add a service, select Actions > Add Service, then complete the following procedure using the Add Service Wizard.


Adding a Service to your Hadoop cluster

This example shows the Falcon service selected for addition.

  1. Choose Services.
    Choose an available service. Alternatively, choose all to add all available services to your cluster. Then, choose Next. The Add Service wizard displays installed services highlighted green and check-marked, not available for selection.
    Choose Services

    Figure 28. Choose Services

    Example, Adding Storm Service
    Adding Storm Service

    Figure 29. Adding Storm Service

  2. In Assign Masters, confirm the default host assignment. Alternatively, choose a different host machine to which master components for your selected service will be added. Then, choose Next. The Add Services Wizard indicates hosts on which the master components for a chosen service will be installed. A service chosen for addition shows a grey check mark.
    Using the drop-down, choose an alternate host name, if necessary.
    • A green label located on the host to which its master components will be added, or
    • An active drop-down list on which available host names appear.
      Assign Master

      Figure 30. Assign Master

  3. In Assign Slaves and Clients, accept the default assignment of slave and client components to hosts. Then, choose Next.
    Alternatively, select hosts on which you want to install slave and client components. You must select at least one host for the slave of each service being added.
    Host Role Required For Adding Service

    Figure 31. Host Role Required For Adding Service

    The Add Service Wizard skips and disables the Assign Slaves and Clients step for a service requiring no slave nor client assignment. memerlukan slave atau client assignment.
    Assign Slaves dan Client

    Figure 32. Assign Slaves dan Client

  4. In Customize Services, accept the default configuration properties.
    Alternatively, edit the default values for configuration properties, if necessary. Choose Override to create a configuration group for this service. Then, choose Next.
    Customize Services

    Figure 33. Customize Services

  5. In Review, make sure the configuration settings match your intentions. Then, choose Deploy
    Review Services

    Figure 34. Review Services

  6. Monitor the progress of installing, starting, and testing the service. When the service installs and starts successfully, choose Next
     Install, Start and Test

    Figure 35. Install, Start and Test

  7. Summary displays the results of installing the service. Choose Complete.

    Figure 36. Summary

  8. Restart any other components having stale configurations.

4.3.Editing Service Config Properties

Select a service, then select Configs to view and update configuration properties for the selected service. For example, select MapReduce2, then select Configs. Expand a config category to view configurable service properties. For example, select General to configure Default virtual memory for a job’s map task.

Editing Service Config Properties

Figure 37. Editing Service Config Properties

4.4.Viewing Service Summary and Alerts

After you select a service, the Summary tab displays basic information about the selected service.

Viewing Service Summary and Alerts

Figure 38. Viewing Service Summary and Alerts

Select one of the View Host links, as shown in the following example, to view components and the host on which the selected service is running.

Service Condition In Running

Figure 39. Service Condition In Running

Alerts and Health Checks

On each Service page, in the Summary area, click Alerts to see a list of all health checks and their status for the selected service. Critical alerts are shown first. Click the text title of each alert message in the list to see the alert definition. For example, On the HBase > Services, click Alerts. Then, in Alerts for HBase, click HBase Master Process.

Alerts for HBase

Figure 40. Alerts for HBase

Modifying the Service Dashboard

Depending on the Service, the Summary tab includes a Metrics section which is by default populated with important service metrics to monitor.

Modifying the Service Dashboard

Figure 41. Modifying the Service Dashboard

This section of Metrics is customizable. You can add and remove widgets from the Dashboard as well as create new widgets. Widgets can be private only to you and your dashboard or shared in a Widget Browser library for other Ambari users to add/remove the widget from their Dashboard.

You must have the Ambari Metrics service installed to be able to view, create, and customize the Service Dashboard. Only HDFS, Hive, HBase, and YARN have customizable service dashboards.

  1. Click on the “ + ” to launch the Widget Browser. Alternatively, you can choose the Actions menu in the Metrics header to Browse Widgets.
  2. The Widget Browser displays the available widgets to add to your Service Dashboard. This is a combination of shared widgets and widgets you have created. Widgets that are shared are identified by the icon highlighted in the following example.
    Adding or Removing a Widget

    Figure 42. Adding or Removing a Widget

  3. If you want to only display the widgets you have created, click the “Show only my widgets” checkbox to filter the Widget Browser.
  4. If you want to only display the widgets you have created, click the “Show only my widgets” checkbox to filter the Widget Browser.
  5. If a widget is not already added, you can click Add.
  1. Click on the “ + ” to launch the Widget Browser. Click the Create Widget button. Alternatively, you can choose the Actions menu in the Metrics header to Create Widget. This launches the Create Widget wizard.
  2. Select the type of widget to create.
  3. Depending on the service and type of widget, you can select metrics and use operators to create an Expression that will be displayed in the widget. A preview of the widget is displayed as you build the expression.
  4. Enter the widget name and description. Optionally choose to Share the widget. Sharing the widget makes the widget available to all Ambari users for this cluster. Once a widget is shared, other Ambari Admins or Cluster Operators can modify or delete the widget. This cannot be undone.
  1. Click on the “ + ” to launch the Widget Browser. Alternatively, you can choose the Actions menu in the Metrics header to Browse Widgets.
  2. The Widget Browser displays the available widgets to add to your Service Dashboard. This is a combination of shared widgets and widgets you have created. Widgets that are shared are identified by the icon highlighted in the following example.
    Deleting a Widget

    Figure 43. Deleting a Widget

  3. If a widget is already added to your dashboard, it is shown as Added. Click to remove.
  4. For widgets that you created, you can select the More… option to delete.
  5. For widgets that are shared, if you are an Ambari Admin or Cluster Operator, you will also have the option to delete.
  6. Deleting a shared widget removes the widget from all users. This cannot be undone.

4.5.Monitoring Background Operations

Use Background Operations to monitor progress and completion of bulk operations such as rolling restarts.
Background Operations opens by default when you run a job that executes bulk operations.

  1. Select the right-arrow for each operation to show restart operation progress on each host.
    Background Operation Running

    Figure 44. Background Operation Running

  2. After restarts complete, Select the right-arrow, or a host name, to view log files and any error messages generated on the selected host.
    Restart Semua komponen untuk HBASE

    Figure 45. Restart Semua komponen untuk HBASE

    Select links at the upper-right to copy or open text files containing log and error information.
    File Text yang Berisi Informasi Log dan Error

    Figure 46. File Text yang Berisi Informasi Log dan Error

    Optionally, select the option to not show the bulk operations dialog

4.6.Rolling Restarts

When you restart multiple services, components, or hosts, use rolling restarts to distribute the task. A rolling restart stops, then starts multiple, running slave components such as DataNodes, NodeManagers, RegionServers, or Supervisors, using a batch sequence. You set rolling restart parameter values to control the number of, time between, tolerance for failures, and limits for restarts of many components across large clusters.

To run a rolling restart:

  1. Select a Service, then link to a lists of specific components or hosts that Require Restart.
  2. Select Restart, then choose a slave component option.
  3. Review and set values for Rolling Restart Parameters.
  4. Optionally, reset the flag to only restart components with changed configurations.
  5. Choose Trigger Restart.

Use Monitor Background Operations to monitor progress of rolling restarts.

Rolling Restarts of DataNodes is recommended to only be performed during a cluster maintenance window.


Setting Rolling Restart Parameters

If you trigger a rolling restart of components, Restart components with stale configs defaults to true. If you trigger a rolling restart of services, Restart services with stale configs defaults to false.

Restart DataNodes

Figure 47. Restart DataNodes

Validation Rules for Rolling Restart Parameters

Figure 48. Validation Rules for Rolling Restart Parameters

Aborting a Rolling Restart

To abort future restart operations in the batch, choose Abort Rolling Restart.

Rolling Restart from NodeManagers

Figure 49. Rolling Restart from NodeManagers

5.Managing Configurations

Use Ambari Web to manage your Yava component configurations. Select any of the following topics on this section.

5.1.Configuring Services

Select a service, then select Configs to view and update configuration properties for the selected service. For example, select MapReduce2, then select Configs. Expand a config category to view configurable service properties.


Updating Service Properties

  1. Expand a configuration category.
  2. Edit values for one or more properties that have the Override option.
    Edited values, also called stale configs, show an Undo option.
  3. Choose Save.

Restarting Components

After editing and saving a service configuration, Restart indicates components that you must restart.

Select the Components or Hosts links to view details about components or hosts requiring a restart.

Then, choose an option appearing in Restart. For example, options to restart YARN components include:

Figures 50. Restarting Components

5.2.Using Host Config Groups

Ambari initially assigns all hosts in your cluster to one, default configuration group for each service you install. For example, after deploying a three-node cluster with default configuration settings, each host belongs to one configuration group that has default configuration settings for the HDFS service. In Configs, select Manage Config Groups, to create new groups, re-assign hosts, and override default settings for host components you assign to each group.

Manage Host Config Groups

Figure 51. Manage Host Config Groups

To create a Configuration Group:

  1. Choose Add New Configuration Group.
  2. Name and describe the group, then choose Save.
  3. Select a Config Group, then choose Add Hosts to Config Group.
  4. Select Components and choose from available Hosts to add hosts to the new group.
    Select Configuration Group Hosts enforces host membership in each group, based on Installed components for the selected service.
    Select Configuration Group Hosts

    Figure 52. Select Configuration Group Hosts

  5. Choose OK.
  6. In Manage Configuration Groups, choose Save.

To edit settings for a configuration group:

  1. In Configs, choose a Group.
  2. Select a Config Group, then expand components to expose settings that allow Override.
  3. Provide a non-default value, then choose Override or Save.
    Configuration groups enforce configuration properties that allow override, based on installed components for the selected service and group

    Figure 53. DataNode

  4. Override prompts you to choose one of the following options:
    HDFS Configuration Group

    Figure 54. HDFS Configuration Group

    • Select an existing configuration group (to which the property value override provided in step 3 will apply), or
    • Create a new configuration group (which will include default properties, plus the property override provided in step 3).
    • Then, choose OK.
  5. In Configs, choose Save.

5.3.Customizing Log Settings

Ambari Web displays default logging properties in Service Configs > Custom log 4j Properties. Log 4j properties control logging activities for the selected service.

Customizing Log Settings

Figure 55. Customizing Log Settings

Restarting components in the service pushes the configuration properties displayed in Custom log 4j Properties to each host running components for that service. If you have customized logging properties that define how activities for each service are logged, you will see refresh indicators next to each service name after upgrading to Ambari 1.5.0 or higher. Make sure that logging properties displayed in Custom log 4j Properties include any customization. Optionally, you can create configuration groups that include custom logging properties.

5.4.Service Configuration Versions

Ambari provides the ability to manage configurations associated with a Service. You can make changes to configurations, see a history of changes, compare + revert changes and push configuration changes to the cluster hosts.

Basic Concepts

It’s important to understand how service configurations are organized and stored in Ambari. Properties are grouped into Configuration Types (config types). A set of config types makes up the set of configurations for a service.

For example, the HDFS Service includes the following config types: hdfs-site, core-site, hdfslog4j, hadoop-env, hadoop policy. If you browse to Services > HDFS > Configs, the configuration properties for these config types are available for edit.

Versioning of configurations is performed at the service-level. Therefore, when you modify a configuration property in a service, Ambari will create a Service Config Version. The figure below shows V1 and V2 of a Service Configuration Version with a change to a property in Config Type A. After making the property change to Config Type A in V1, V2 is created.

Basic Concepts

Figure 56. Basic Concepts


The following table lists configuration versioning terms and concepts that you should know.


Figure 57. Terminology

Saving a Change

  1. Make the configuration property change.
  2. Choose Save.
  3. You are prompted to enter notes that describe the change
    Saving a Change

    Figure 58. Saving a Change

  4. Click Save to confirm your change. Cancel will not save but instead returns you to the configuration page to continuing editing.
    To revert the changes you made and not save, choose Discard.
    To return to the configuration page and continue editing without saving changes, choose Cancel

Viewing History

Service Config Version history is available from Ambari Web in two places: On the Dashboard page under the Config History tab; and on each Service page under the Configs tab.

The Dashboard > Config History tab shows a list of all versions across services with each version number and the date and time the version was created. You can also see which user authored the change with the notes entered during save. Using this table, you can filter, sort and search across versions.

History Configuration

Figure 59. History Configuration

The most recent configuration changes are shown on the Service > Configs tab. Users can navigate the version scrollbar left-right to see earlier versions. This provides a quick way to access the most recent changes to a service configuration.

Click on any version in the scrollbar to view, and hover to display an option menu which allows you compare versions and perform a revert. Performing a revert makes any config version that you select the current version.

Configuration Tab

Figure 60. Configuration Tab

Comparing Versions

To perform a compare between two service configuration versions:

  1. Navigate to a specific configuration version. For example “V4”.
  2. Using the version scrollbar, find the version would you like to compare against “V6”. For example, if you want to compare V4 to V3, find V3 in the scrollbar.
  3. Hover over the version to display the option menu. Click “Compare”.
  4. Ambari displays a comparison of V4 to V3, with an option to revert to V2.
  5. Ambari also filters the display by only “Changed properties”. This option is available under the Filter control.
Comparing Versions

Figure 61. Comparing Versions

Reverting a Change

You can revert to an older service configuration version by using the “Make Current” feature. The “Make Current” will actually create a new service configuration version with the configuration properties from the version you are reverting it is effectively a “clone”. After initiating the Make Current operation, you are prompted to enter notes for the new version (i.e. the clone) and save. The notes text will include text about the version being cloned.

Confirm Make Current

Figure 62. Confirm Make Current

There are multiple methods to revert to a previous configuration version:

  1. View a specific version and click the “Make V* Current” button.
  2. Use the version navigation dropdown and click the “Make Current” button.
    Version Navigation

    Figure 63. Version Navigation

  3. Hover on a version in the version scrollbar and click the “Make Current” button.
  4. Perform a comparison and click the “Make V* Current” button.

Versioning and Host Config Groups

Service configuration versions are scoped to a host config group. For example, changes made in the default group can be compared and reverted in that config group. Same with custom config groups.

The following example describes a flow where you have multiple host config groups and create service configuration versions in each config group.


Versioning and Host Config Groups

Figure 64. Versioning and Host Config Groups

6.Administering the Cluster

From the cluster dashboard, use the Admin options to view information about Managing Stack and Versions, Service Accounts, and to Enable Kerberos security.

For more information about administering your Ambari Server, see the Ambari Administration Guide.

6.1.Service Accounts

To view the list of users and groups used by the cluster services, choose Admin > Service Accounts.

Service Accounts

Figure 65. Service Accounts


If Kerberos has not been enabled in your cluster, click the Enable Kerberos button to launch the Kerberos wizard. For more information on configuring Kerberos in your cluster, see the Ambari Security Guide. Once Kerberos is enabled, you can:

  1. Regenerate Keytabs
  2. Disable Kerberos

How To Regenerate Keytabs

  1. Browse to Admin > Kerberos.
  2. Click the Regenerate Kerberos button.
  3. Click the Regenerate Kerberos button.
  4. Optionally, you can regenerate keytabs for only those hosts that are missing keytabs. For example, hosts that were not online/available from Ambari when enabling Kerberos.
  5. Once you confirm, Ambari will connect to the KDC and regenerate the keytabs for the Service and Ambari principals in the cluster.
  6. 6. Once complete, you must restart all services for the new keytabs to be used.

Ambari requires the Kerberos Admin credentials in order to regenerate the keytabs. If the credentials are not available to Ambari, you will be prompted to enter the KDC Admin username and password. For more information on configuring Kerberos in your cluster, see the Ambari Security Guide.

How To Disable Kerberos

  1. Browse to Admin > Kerberos.
  2. Click the Disable Kerberos button.
  3. Confirm your selection to proceed. Cluster services will be stopped and the Ambari Kerberos security settings will be reset.
  4. To re-enable Kerberos, click Enable Kerberos and follow the wizard steps. For more information on configuring Kerberos in your cluster, see the Ambari Security Guide.

7.Monitoring and Alerts

Ambari monitors cluster health and can alert you in the case of certain situations to help you identify and troubleshoot problems. You manage how alerts are organized, under which conditions notifications are sent, and by which method. This section provides information on:

  1. Managing Alerts
  2. Configuring Notifications
  3. List of Predefined Alerts

7.1.Managing Alerts

Ambari predefines a set of alerts that monitor the cluster components and hosts. Each alert is defined by an Alert Definition, which specifies the Alert Typecheck interval and thresholds. When a cluster is created or modified, Ambari reads the Alert Definitions and creates Alert Instances for the specific items to watch in the cluster. For example, if your cluster includes HDFS, there is an alert definition to watch the “DataNode Process”. An instance of that alert definition is created for each DataNode in the cluster.



The following basic terms help explain the concepts associated with Alert Ambari: Terminology

Terms And Definitions

Figure 66. Terms And Definitions


Definition Alert and Instance

Alert thresholds and the threshold units are dependent on alert type. The following table lists the types of alerts, their possible status and if the thresholds are configurable:

Alert Types

Figure 67. Alert Types


Modifying an Alert

  1. Browse to the Alerts section in Ambari Web.
  2. Find the alert definition and click to view the definition details.
  3. Click Edit to modify the name, description, check interval and thresholds (as applicable).
  4. Click Save.
  5. Changes will take effect on all alert instances at the next check interval.

How to see the list of alert instances

  1. Browse to the Alerts section in Ambari Web.
  2. Find the alert definition and click to view the definition details.
  3. List of alert instances displayed, or
  4. Find a specific host from Ambari’s website to see a list of certain instances of alerts in the host.

Enabling or Disabling Alerts

  1. Browse to the Alerts section in Ambari Web.
  2. Find the alert definition. Click the Enabled or Disabled text to enable/disable the alert.
  3. Alternatively, you can click on the alert to view the definition details and click Enabled or Disabled to enable/disable the alert.
  4. You will be prompted to confirm enable/disable.

7.2.Configuring Notifications

With Alert Groups and Notifications, you can create groups of alerts and setup notification targets for each group. This way, you can notify different parties interested in certain sets of alerts via different methods. For example, you might want your Hadoop Operations team to receive all alerts via EMAIL, regardless of status. And at the same time, have your System Administration team receive all RPC and CPU related alerts that are Critical only via SNMP. To achieve this scenario, you would have an Alert Notification that handles Email for all alert groups for all severity levels, and you would have a different Alert Notification group that handles SNMP on critical severity for an Alert Group that contains the RPC and CPU alerts.

Ambari defines a set of default Alert Groups for each service installed in the cluster. For example, you will see a group for HDFS Default. These groups cannot be deleted and the alerts in these groups are not modifiable. If you choose not to use these groups, just do not set a notification target for them.


Creating or Editing Notifications

  1. Browse to the Alerts section in Ambari Web.
  2. Under the Actions menu, click Manage Notifications.
  3. The list of existing notifications is shown.
  4. Click + to “Create new Alert Notification”. The Create Alert Notification dialog is displayed.
  5. Enter the notification name, select the groups to which the notification should be assigned (all or a specific set), select the Severity levels that this notification responds to, include a description, and choose the method for notification (EMAIL or SNMP).
    • For EMAIL: provide information about your SMTP infrastructure such as SMTP Server, Port, To/From address and if authentication is required to relay messages through the server. You can add custom properties to the SMTP configuration based on the Javamail SMTP options.
      SMTP JavaMail options

      Figure 68. SMTP JavaMail options

    • For SNMP: select the SNMP version, Community, Host, and Port where the SNMP trap should be sent. Also, the OID parameter must be configured properly for SNMP trap context. If no custom, or enterprise-specific OID will be used, we recommend the following:
      Enterprise-Specific OID

      Figure 69. Enterprise-Specific OID

    Only SNMPv1 and SNMPv2c should be chosen for SNMP Version. SNMP v3 is not supported nor functional at this time.

  6. After completing the notification, click Save.

Creating or Editing Alert Groups

  1. Browse to the Alerts section in Ambari Web.
  2. From the Actions menu, choose Manage Alert Groups
  3. The list of existing groups (default and custom) is shown.
  4. Choose + to “Create Alert Group”. Enter the Group a name and click Save.
  5. By clicking on the custom group in the list, you can add or delete alert definitions from this group, and change the notification targets for the group.

Dispatching Notifications

When an alert is enabled and the alert status changes (for example, from OK to CRITICAL or CRITICAL to OK), Ambari will send a notification (depending on how the user has configured notifications). For EMAIL notifications: Ambari will send an email digest that includes all alert status changes.

For example: if two alerts go CRITICAL, Ambari sends one email that says “Alert A is CRITICAL and Ambari B alert is CRITICAL”. Ambari will not send another email notification until status has changed again.

For SNMP notifications: Ambari will fire an SNMP trap per alert status change. For example: if two alerts go CRITICAL, Ambari will fire two SNMP traps, one for each alert going OK -> CRITICAL. When the alert changes status from CRITICAL -> OK, another trap is sent.


Viewing Alert Status Log

In addition to dispatching alert notifications, Ambari writes alert status changes to a log on the Ambari Server host. Alert status changes will be written to the log regardless if EMAIL or SNMP notifications are configured.

  1. On the Ambari Server host, browse to the log directory:
    cd /var/log/ambari-server/
  2. View the ambari-alerts.log file.
  3. Log entries will include the time of the status change, the alert status, the alert definition name and the response text.

7.3.List of Predefined Alerts


HDFS Service Alerts

HDFS Service Alert

Figure 70. HDFS Service Alert


NameNode HA Alert

NameNode HA Alert

Figure 71. NameNode HA Alert


YARN Alert

YARN Alert

Figure 72. YARN Alert


MapReduce2 Alert

MapReduce2 Alert

Figure 73. MapReduce2 Alert


HBase Service Alert

HBase Service Alert

Figure 74. HBase Service Alert


Hive Alert

Hive Alert

Figure 75. Hive Alert


Oozie Alert

Oozie Alert

Figure 76. Oozie Alert


ZooKeeper Alert

ZooKeeper Alert

Figure 77. ZooKeeper Alert


Ambari Alert

Ambari Alert

Figure 78. Ambari Alert

Suggest Edit

© 2017 Labs247. All rights reserved.
YAVA logo and HGrid247 logo are registered trademarks or trademarks of the Labs247 Company.
HADOOP, the Hadoop Elephant Logo, Apache, Flume, Ambari, Yarn, Bigtop, Phoenix, Hive, Tez, Oozie, HBase, Mahout, Pig, Solr, Storm, Spark, Sqoop, Impala, and ZooKeeper are registered trademarks or trademarks of the Apache Software Foundation.