# Building a Spark observability product with StarRocks: Real-time and historical performance analysis

[Grab](https://yomu.fyi/company/grab) · Huong Vuong · Mar 6, 2025

## Summary

Grab redesigned its Spark observability platform, Iris, to overcome limitations associated with its previous Telegraf, InfluxDB, and Grafana stack. InfluxDB presented operational challenges due to limited SQL compatibility, poor handling of string metadata, and query degradation on high-cardinality identifiers. The team replaced InfluxDB with StarRocks to serve as a unified analytical engine for both real-time cluster metrics and historical analysis. StarRocks ingests metrics directly from Kafka via routine load tasks, storing worker and Spark event data in partitioned duplicate-key OLAP tables linked by worker and application identifiers. This architecture eliminated intermediate ingestion agents, simplified S3 data lake backups, and enabled a custom web application alongside Superset for consistent querying.

## Takeaways

- Replacing InfluxDB with StarRocks removed the need for Telegraf by using native routine load tasks that ingest JSON-formatted metrics directly from Kafka partitions.
- The Iris data model correlates 5-second worker metrics and stage-level execution events with cluster metadata using worker\_uuid and app\_id fields across partitioned OLAP tables.
- StarRocks resolved InfluxDB limitations around string metadata joins, Flux query constraints, and performance degradation on high-cardinality unique identifiers.

**Tags:** [Data Pipelines](https://yomu.fyi/topic/data-pipelines), [Kafka](https://yomu.fyi/topic/kafka), [Migrations](https://yomu.fyi/topic/migration), [Monitoring](https://yomu.fyi/topic/monitoring), [Observability](https://yomu.fyi/topic/observability)

[Read original post](https://engineering.grab.com/building-a-spark-observability)