Files
hanzo.ai/app/(marketing)/o11y/page.tsx
zooqueen 75c4f1f641 One product answers with one name, route, command and docs page
The CLI lines on the product pages were written from the product name -- hanzo
dns zones, hanzo kms keys -- and several were not commands the binary has. So the
command moves into lib/product.ts, which assembles the rest from what is already
stated: the catalog names the product and its route, pages.json names what the
catalog does not carry, and products-metadata answers for docs, where null means
docs publishes nothing and the link drops.

Every CLI line in that table was run against the binary. A product absent from it
has no command and its page prints none; nothing composes a verb out of a name.
Both blocks that draw it import the Product type rather than declaring their own,
which leaves the table the only place a command can be written.

The catalog also moves out of package.json into pnpm-workspace.yaml, where pnpm
reads it, so the versions are stated once.
2026-09-06 23:18:24 -07:00

80 lines
3.5 KiB
TypeScript

'use client'
import { ArrowRight, Activity, BarChart3, Flame, LineChart, ScrollText, Search, Workflow } from 'lucide-react'
import { ProductLanding } from '@/components/product/ProductLanding'
import { ProductFooter } from '@/components/products/ProductFooter'
/**
* Hanzo O11y, through the ONE product kit.
*
* The largest cluster left: TWELVE pages — engine, gateway, guard, ingress,
* jin, metrics, o11y, operator, sentinel, skills, telemetry, visor — at 85%+
* identical className sets, each a hero, a six-card grid and a call to action
* written out again. All twelve pass one typed props object to
* `ProductLanding`. See LLM.md, "Tailwind is NOT gone".
*
* EVERY WORD IS THE ONE THAT WAS HERE. ProductFooter came out of the final
* card's `max-w-3xl` wrapper, where it had been rendering narrower than on
* every other product page.
*/
export default function HanzoO11yPage() {
return (
<>
<ProductLanding
badge={"o11y.hanzo.ai"}
badgeIcon={LineChart}
title={"Hanzo O11y"}
tagline={"Traces, metrics and logs, in one place"}
lede={"Your services send OpenTelemetry; it lands in one column store and comes back as APM, logs, traces, metrics and exceptions. Because it is one store, a span and the log line it produced are one query rather than two tabs and a copied timestamp."}
ctas={[
{ label: "View on GitHub", href: "https://github.com/hanzoai/o11y" },
]}
what={{
title: "One store, one query language",
sub: "Every panel scopes to your org from the token, so a shared deployment still answers one tenant at a time.",
pillars: [
{
icon: Workflow,
title: "Traces and APM",
body: "Follow one request across services, queues and databases. Sort by the slow tail rather than the average, and open the span that spent the time.",
},
{
icon: BarChart3,
title: "Metrics",
body: "Write PromQL if you already have it, or build the query in the UI if you do not. Both run against the same store the traces are in.",
},
{
icon: ScrollText,
title: "Logs",
body: "Search structured logs by field, not by regex over a blob. A span carries the id its log lines were written with, so the pivot is a click.",
},
{
icon: Flame,
title: "Exceptions",
body: "Errors are grouped and counted rather than listed, so a thousand of the same stack trace is one row with a number on it — and it links to the trace that raised it.",
},
{
icon: Search,
title: "Dashboards and alerts",
body: "An alert rule is a saved query, so what fires at three in the morning is something you already looked at. It reaches PagerDuty, Opsgenie, Slack, Teams, email or a webhook.",
},
{
icon: Activity,
title: "OpenTelemetry on the wire",
body: "OTLP over gRPC on 4317 and HTTP on 4318. Any OTel SDK or collector points at it by setting one endpoint variable — there is no agent of ours to install.",
},
],
}}
finalCta={{
title: "Point an OTLP endpoint at it",
buttons: [
{ label: "View on GitHub", href: "https://github.com/hanzoai/o11y" },
],
}}
/>
<ProductFooter slug={"o11y"} name={"O11y"} />
</>
)
}