Skip to main content
Iceberg provides a pluggable metrics reporting system to collect and export operational metrics. As of version 1.1.0, the MetricsReporter and MetricsReport APIs enable tracking scan performance, commit statistics, and other operational data.

Metrics Architecture

The metrics system consists of two main components:
  • MetricsReport: Data structure containing metrics for specific operations
  • MetricsReporter: Plugin interface for reporting metrics to external systems

Types of Reports

ScanReport

A ScanReport captures metrics collected during scan planning against a table.

Included Metrics

  • General information: Table name, snapshot ID, schema ID, projection details
  • Planning duration: Total time spent planning the scan
  • File statistics: Number of data/delete files and manifests scanned or skipped
  • Size statistics: Total size of data and delete files
  • Delete file breakdown: Equality vs. positional delete files

Example ScanReport

CommitReport

A CommitReport captures metrics collected after committing changes to a table (producing a snapshot).

Included Metrics

  • General information: Table name, snapshot ID, sequence number, operation type
  • Commit duration: Total time to commit
  • Retry statistics: Number of attempts required for commit to succeed
  • File changes: Added/removed data and delete files
  • Row changes: Added/removed records
  • Delete breakdown: Equality vs. positional deletes added/removed

Example CommitReport

Available Metrics Reporters

LoggingMetricsReporter

The default metrics reporter that logs reports to the application log file.

Configuration

No configuration required - automatically enabled when no other reporter is configured.

Output Example

The LoggingMetricsReporter is useful for debugging and development but may generate significant log volume in production.

RESTMetricsReporter

Automatically enabled when using the RESTCatalog. Sends metrics to a REST server endpoint.

Endpoint

Metrics are posted to:

Configuration

Control REST metrics reporting with the catalog property:
The REST metrics reporter follows the REST OpenAPI specification for Iceberg catalogs.

Implementing a Custom Metrics Reporter

Create custom reporters to send metrics to monitoring systems like Prometheus, CloudWatch, or Datadog.

Basic Implementation

Prometheus Reporter Example

CloudWatch Reporter Example

Registering Custom Metrics Reporters

Via Catalog Configuration

Register a reporter globally for all tables in a catalog:

Via Scan API

Attach reporters to specific scan operations:
Reporters registered via the scan API are used in addition to catalog-level reporters, not instead of them.

Metrics Use Cases

Performance Monitoring

Track scan performance to identify slow queries:

Cost Tracking

Track data scanned for cost allocation:

Audit Logging

Log all table modifications:

Best Practices

  1. Implement efficient reporters: Avoid blocking operations in the report() method
  2. Use asynchronous publishing: Buffer and batch metrics before sending to external systems
  3. Handle failures gracefully: Don’t let reporter failures affect table operations
  4. Filter relevant metrics: Only export metrics you need to reduce overhead
  5. Add context: Include table name, operation type, and timestamps in all metrics
  6. Monitor reporter health: Track metrics about the metrics system itself
  7. Use structured logging: Export metrics in structured formats (JSON) for easier parsing