Recon

    On a high level, Recon collects and aggregates metadata from Ozone Manager (OM), Storage Container Manager (SCM) and Datanodes (DN) and acts as a central management and monitoring console. Ozone administrators can use Recon to query the current state of the system without overloading OM or SCM.

    Recon maintains multiple databases to enable batch processing, faster querying and to persist aggregate information. It maintains a local copy of OM db and SCM db along with a SQL database for persisting aggregate information.

    Recon also integrates with Prometheus to provide a HTTP endpoint to query Prometheus for Ozone metrics and also to display a few crucial point in time metrics in the web UI.

    Recon and Ozone Manager

    Recon - 图2

    The db updates retrieved from OM is then converted into a batch of events for further processing by OM db tasks via .

    Recon also acts as a passive SCM for datanodes. When Recon is configured in the cluster, all the datanodes register with Recon and send heartbeats, container reports, incremental container reports etc. to Recon similar to SCM. Recon uses all the information it gets from datanodes to construct its own copy of SCM rocks db locally. Recon never sends any command to datanodes in response and just acts as a passive SCM for faster lookup of SCM metadata.

    Task Framework

    Recon has its own Task framework to enable batch processing of data obtained from OM and SCM. A task can listen to and act upon db events such as , DELETE, UPDATE, etc. on either OM db or SCM db. Based on this, a task either implements org.apache.hadoop.ozone.recon.tasks.ReconOmTask or extends org.apache.hadoop.ozone.recon.scm.ReconScmTask.

    An example is ContainerKeyMapperTask that persists the container -> key mapping in RocksDB. This is useful to understand which keys were part of the container when the container is reported missing or is in a bad health state. Another example is FileSizeCountTask which keeps track of count of files within a given file size range in a SQL database. These tasks have implementations for two scenarios:

    • Delta updates (process())

    An example ReconScmTask is ContainerHealthTask that runs in configurable intervals to scan the list of all the containers and to persist the state of unhealthy containers (, MIS_REPLICATED, UNDER_REPLICATED, OVER_REPLICATED) in a SQL table. This information is used to determine if there are any missing containers in the cluster.

    Recon can integrate with any Prometheus instance configured to collected metrics and can display useful information in Recon UI in Datanodes and Pipelines pages. Recon also exposes a proxy endpoint () to query Prometheus. This integration can be enabled by setting this configuration ozone.recon.prometheus.http.endpoint to the Prometheus endpoint like .

    API Reference

    • A local copy of OM database

    • A local copy of

      • ContainerKey table
        • Stores the mapping (container, key) -> count
      • ContainerKeyCount table
        • Stores containerID -> no. of keys count within the container

    Notable configurations