Promoting only metric/series/descriptor left the five rollup tables tenant-less under canonical names. Replayed against a copy of the live shapes: two orgs' series rows sharing one fingerprint both reached series_6h, which has no org column, and the second REPLACED the first. The fingerprint is a hash of the labels and is therefore tenant-independent, so without org leading the sort key two tenants are one row — a tenancy migration that ends with one tenant's data overwriting another's is worse than not running. So the rule the file already states — the tenant-less table goes to attic, the org-first one takes the name — now applies to all eleven names in one RENAME, and the five rollup targets, which have no org-first twin to promote, are created org-first here. Their history goes to attic alongside the samples it summarizes; that is the same loss already accepted for the 268M rows underneath. The five fill_* views are dropped BEFORE the rename and rebuilt after. A view binds its source by name: after the swap fill_metric_5m was ORPHANED (nothing is called event.metric any more, so sample_5m and sample_30m silently stopped being fed) while fill_series_6h RE-ATTACHED to the swapped-in table and began pouring two tenants into an org-less rollup. Neither announces itself, so step 6 now asserts the chain is wired rather than assuming it. metric_buffer and series_buffer carry a one-day TTL because a buffer is a buffer; promoted unchanged they cut the plane's retention 30x. MODIFY TTL restores thirty days while both are still empty. The gate could not have caught that — it diffed system.columns, and a TTL is not a column — so it now reads create_table_query, which is the whole definition in one field. ALTER TABLE ... ADD COLUMN org was evaluated and rejected. The engine refuses every form that puts org first in the sort key; the one form it accepts leaves 268M rows under the empty-string tenant with no pruning. The three refusals are quoted in the file. Also: the uuid -> slug map the 0002 precondition asked the operator to derive is derived and written out. Both live values reproduce exactly from uuid5(NameSpaceURL, 'hanzo:o11y:org:' || slug) — hanzo and admin. A product uuid is a minted UUIDv7 and cannot be inverted, so it stays a lookup. Co-authored-by: Hanzo Dev <[email protected]>
Deploy
Check that you have cloned o11y/o11y
and currently are in o11y/deploy folder.
Docker
If you don't have docker set up, please follow this guide to set up docker before proceeding with the next steps.
Using Install Script
Now run the following command to install:
./install.sh
Using Docker Compose
If you don't have docker compose set up, please follow this guide to set up docker compose before proceeding with the next steps.
cd deploy/docker
docker compose up -d
Open http://localhost:8080 in your favourite browser.
To start collecting logs and metrics from your infrastructure, run the following command:
cd generator/infra
docker compose up -d
To start generating sample traces, run the following command:
cd generator/hotrod
docker compose up -d
In a couple of minutes, you should see the data generated from hotrod in Hanzo O11y UI.
For more details, please refer to the Hanzo O11y documentation.
Docker Swarm
To install Hanzo O11y using Docker Swarm, run the following command:
cd deploy/docker-swarm
docker stack deploy -c docker-compose.yaml o11y
Open http://localhost:8080 in your favourite browser.
To start collecting logs and metrics from your infrastructure, run the following command:
cd generator/infra
docker stack deploy -c docker-compose.yaml infra
To start generating sample traces, run the following command:
cd generator/hotrod
docker stack deploy -c docker-compose.yaml hotrod
In a couple of minutes, you should see the data generated from hotrod in Hanzo O11y UI.
For more details, please refer to the Hanzo O11y documentation.
Uninstall/Troubleshoot?
Go to our official documentation site o11y.hanzo.ai/docs for more.