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