Skip to main content

ChronoLog's year: from 2.5 to 3.5

Software Releases · · 5 min read

Between April 2 and November 12, the ChronoLog team published eleven releases, from 2.5.0 to 3.5.0. Over those seven months, GRC's distributed log store gained SQL, publish-subscribe and agent interfaces. It also learned to keep every event it acknowledges, even through a crash, and moved to a current HPC software stack. This is a summary of the year, release by release.

ChronoLog is a distributed shared log that orders events by physical time and moves them from memory to local storage to an HDF5 archive. ChronoKeepers take in events, ChronoGraphers merge them into story chunks and write the archive, and ChronoPlayers serve replays. The project is funded by an NSF CSSI framework grant (OAC-2104013) led by Xian-He Sun.

ChronoLog component design with ChronoVisor, ChronoKeeper, ChronoStore, ChronoGrapher and ChronoPlayer, showing write, tail-read and historic-read paths
ChronoLog's original component design. Writes go to ChronoKeepers, tail reads come from keeper memory, and replays of older events come from ChronoPlayer.

Spring: packaging and new read paths (2.5 to 2.8)​

  • 2.5.0 (April 2) added range, earliest and latest reads to ChronoKVS, the key-value interface, along with a native Grafana data source plugin and a first streaming plugin. It also set up a release pipeline with Docker images and launched a new website and documentation at chronolog.dev.
  • 2.6.0 (April 24) split the configuration, shipped source tarballs and RPM and Debian packages, and added end-to-end data-integrity tests.
  • 2.7.0 (April 30) separated the client library from the server's internal data structures and added a protocol version check when a client connects.
  • 2.8.0 (May 18) added extraction chains, which control where sealed chunks go next, and a configurable number of ingestion threads.

3.0 and 3.1: new ways in​

ChronoLog 3.0.0 (May 29) added ChronoSQL, which queries stories with SQL-style statements, and ChronoPubSub, a publish-subscribe plugin. It moved the ChronoLog MCP server, which gives AI agents access to the log, into the main repository. The release also added a recording service to ChronoPlayer and cleaned up the client API.

Version 3.1.0 (September 7) merged replay streams in ChronoPlayer, let clients read the last N events of a story straight from keeper memory, and added a store plugin for the Lightweight Distributed Metric Service (LDMS), a monitoring service for HPC systems. Version 3.1.1 followed on September 10.

Autumn: never lose an event (3.2 to 3.4)​

The fall releases closed the gaps in which an event could be lost.

  • 3.2.0 (October 2) keeps each sealed chunk on its keeper until the grapher confirms that the archive holds it. Until then, a chunk the grapher had received but not yet written existed only in the grapher's memory. Replays now read events that are not archived yet directly from the keepers, and an incomplete answer is reported as partial instead of looking complete.
  • 3.3.0 (October 15) has each grapher record every archive file it publishes in a manifest, and players find files only through those records. On NFS, a directory listing can be stale, so a replay could miss a file written late. Each story also gets its own directory.
  • 3.4.0 (November 5) adds opt-in durable writes. A durable write returns success only after the keeper has written the event to a write-ahead log on local disk and synced it, and a restarted keeper replays its log into the archive. With eight writers, a 1 KB durable write took about 480 microseconds at the median on a local NVMe drive, about 15,000 events per second. The unit test suite grew from 480 to 758 tests.

3.5: a new dependency stack​

ChronoLog had built with Spack 0.21.2 since 2024. Version 3.5.0 (November 12) moves to Spack 1.2.2, with Mercury 2.4.1, Margo 0.24.4, Thallium 0.17.0, libfabric 2.6.0 and HDF5 2.2.0. The newer Margo stops a memory leak and supports deadlines that the next release will use for RPCs that still wait without one. Because the newer Mercury handles requests differently, 3.5.0 cannot talk to 3.4.0 or older, and every component and client has to be upgraded together. Archives written by 3.4.0 remain readable.

The people behind the releases​

Research software engineer Eneko Gonzalez led the work from 2.5 through 3.0, including the release pipeline, ChronoKVS, ChronoSQL, ChronoPubSub and the MCP server. Research software engineer Kun Feng wrote the Grafana and LDMS plugins and led 3.1 through 3.5, including durable retention, the manifest archive, the write-ahead log and the new stack. Research associate Inna Brodkin rebuilt the configuration manager and wrote the extraction chains, the player's recording service and its combined replay stream. Shivalika Chaudhary, a 2025 summer resident, wrote the first streaming plugin.

Jaime Cernuda and Anthony Kougkas presented a ChronoLog poster at the NSF CSSI principal investigators' meeting in Rockville, Maryland, from September 13 to 15. In May, a GCASR 2026 poster showed ChronoLog feeding live HPC telemetry to Grafana and serving AI agents through MCP.

Learn more​