Metrics Reporting

As of 1.1.0 Iceberg supports the MetricsReporter and the MetricsReport APIs. These two APIs allow expressing different metrics reports while supporting a pluggable way of reporting these reports.

Type of Reports

ScanReport

A ScanReport carries metrics being collected during scan planning against a given table. Amongst some general information about the involved table, such as the snapshot id or the table name, it includes metrics like:

  • total scan planning duration
  • number of data/delete files included in the result
  • number of data/delete manifests scanned/skipped
  • number of data/delete files scanned/skipped
  • number of equality/positional delete files scanned

CommitReport

A CommitReport carries metrics being collected after committing changes to a table (aka producing a snapshot). Amongst some general information about the involved table, such as the snapshot id or the table name, it includes metrics like:

  • total duration
  • number of attempts required for the commit to succeed
  • number of added/removed data/delete files
  • number of added/removed equality/positional delete files
  • number of added/removed equality/positional deletes

Available Metrics Reporters

LoggingMetricsReporter

This is the default metrics reporter when nothing else is configured and its purpose is to log results to the log file. Example output would look as shown below:

  1. INFO org.apache.iceberg.metrics.LoggingMetricsReporter - Received metrics report: 
  2. ScanReport{
  3.     tableName=scan-planning-with-eq-and-pos-delete-files, 
  4.     snapshotId=2, 
  5.     filter=ref(name="data") == "(hash-27fa7cc0)", 
  6.     schemaId=0, 
  7.     projectedFieldIds=[1, 2], 
  8.     projectedFieldNames=[id, data], 
  9.     scanMetrics=ScanMetricsResult{
  10.         totalPlanningDuration=TimerResult{timeUnit=NANOSECONDS, totalDuration=PT0.026569404S, count=1}, 
  11.         resultDataFiles=CounterResult{unit=COUNT, value=1}, 
  12.         resultDeleteFiles=CounterResult{unit=COUNT, value=2}, 
  13.         totalDataManifests=CounterResult{unit=COUNT, value=1}, 
  14.         totalDeleteManifests=CounterResult{unit=COUNT, value=1}, 
  15.         scannedDataManifests=CounterResult{unit=COUNT, value=1}, 
  16.         skippedDataManifests=CounterResult{unit=COUNT, value=0}, 
  17.         totalFileSizeInBytes=CounterResult{unit=BYTES, value=10}, 
  18.         totalDeleteFileSizeInBytes=CounterResult{unit=BYTES, value=20}, 
  19.         skippedDataFiles=CounterResult{unit=COUNT, value=0}, 
  20.         skippedDeleteFiles=CounterResult{unit=COUNT, value=0}, 
  21.         scannedDeleteManifests=CounterResult{unit=COUNT, value=1}, 
  22.         skippedDeleteManifests=CounterResult{unit=COUNT, value=0}, 
  23.         indexedDeleteFiles=CounterResult{unit=COUNT, value=2}, 
  24.         equalityDeleteFiles=CounterResult{unit=COUNT, value=1}, 
  25.         positionalDeleteFiles=CounterResult{unit=COUNT, value=1}}, 
  26.     metadata={
  27.         iceberg-version=Apache Iceberg 1.4.0-SNAPSHOT (commit 4868d2823004c8c256a50ea7c25cff94314cc135)}}
  1. INFO org.apache.iceberg.metrics.LoggingMetricsReporter - Received metrics report: 
  2. CommitReport{
  3.     tableName=scan-planning-with-eq-and-pos-delete-files, 
  4.     snapshotId=1, 
  5.     sequenceNumber=1, 
  6.     operation=append, 
  7.     commitMetrics=CommitMetricsResult{
  8.         totalDuration=TimerResult{timeUnit=NANOSECONDS, totalDuration=PT0.098429626S, count=1}, 
  9.         attempts=CounterResult{unit=COUNT, value=1}, 
  10.         addedDataFiles=CounterResult{unit=COUNT, value=1}, 
  11.         removedDataFiles=null, 
  12.         totalDataFiles=CounterResult{unit=COUNT, value=1}, 
  13.         addedDeleteFiles=null, 
  14.         addedEqualityDeleteFiles=null, 
  15.         addedPositionalDeleteFiles=null, 
  16.         removedDeleteFiles=null, 
  17.         removedEqualityDeleteFiles=null, 
  18.         removedPositionalDeleteFiles=null, 
  19.         totalDeleteFiles=CounterResult{unit=COUNT, value=0}, 
  20.         addedRecords=CounterResult{unit=COUNT, value=1}, 
  21.         removedRecords=null, 
  22.         totalRecords=CounterResult{unit=COUNT, value=1}, 
  23.         addedFilesSizeInBytes=CounterResult{unit=BYTES, value=10}, 
  24.         removedFilesSizeInBytes=null, 
  25.         totalFilesSizeInBytes=CounterResult{unit=BYTES, value=10}, 
  26.         addedPositionalDeletes=null, 
  27.         removedPositionalDeletes=null, 
  28.         totalPositionalDeletes=CounterResult{unit=COUNT, value=0}, 
  29.         addedEqualityDeletes=null, 
  30.         removedEqualityDeletes=null, 
  31.         totalEqualityDeletes=CounterResult{unit=COUNT, value=0}}, 
  32.     metadata={
  33.         iceberg-version=Apache Iceberg 1.4.0-SNAPSHOT (commit 4868d2823004c8c256a50ea7c25cff94314cc135)}}

RESTMetricsReporter

This is the default when using the RESTCatalog and its purpose is to send metrics to a REST server at the /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics endpoint as defined in the REST OpenAPI spec.

Sending metrics via REST can be controlled with the rest-metrics-reporting-enabled (defaults to true) property.

Implementing a custom Metrics Reporter

Implementing the MetricsReporter API gives full flexibility in dealing with incoming MetricsReport instances. For example, it would be possible to send results to a Prometheus endpoint or any other observability framework/system.

Below is a short example illustrating an InMemoryMetricsReporter that stores reports in a list and makes them available:

  1. public class InMemoryMetricsReporter implements MetricsReporter {
  3.   private List<MetricsReport> metricsReports = Lists.newArrayList();
  5.   @Override
  6.   public void report(MetricsReport report) {
  7.     metricsReports.add(report);
  8.   }
  10.   public List<MetricsReport> reports() {
  11.     return metricsReports;
  12.   }
  13. }

Registering a custom Metrics Reporter

Via Catalog Configuration

The catalog property metrics-reporter-impl allows registering a given MetricsReporter by specifying its fully-qualified class name, e.g. metrics-reporter-impl=org.apache.iceberg.metrics.InMemoryMetricsReporter.

Via the Java API during Scan planning

Independently of the MetricsReporter being registered at the catalog level via the metrics-reporter-impl property, it is also possible to supply additional reporters during scan planning as shown below:

  1. TableScan tableScan = 
  2.     table
  3.         .newScan()
  4.         .metricsReporter(customReporterOne)
  5.         .metricsReporter(customReporterTwo);
  7. try (CloseableIterable<FileScanTask> fileScanTasks = tableScan.planFiles()) {
  8.   // ...
  9. }