{
    "product": "Cenvero Stratum",
    "generated_at": "2026-08-03T07:17:38+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "monitoring",
            "title": "Monitoring & Observability",
            "category": null,
            "url": "https://www.stratum.cenvero.com/docs/monitoring",
            "headings": [
                {
                    "level": 1,
                    "text": "Monitoring & Observability"
                },
                {
                    "level": 2,
                    "text": "Status: is this node healthy?"
                },
                {
                    "level": 2,
                    "text": "Metrics: how much of what"
                },
                {
                    "level": 2,
                    "text": "Flows: who is talking to whom"
                },
                {
                    "level": 2,
                    "text": "Alerts: tell me when something happens"
                },
                {
                    "level": 2,
                    "text": "Audit: who changed what"
                },
                {
                    "level": 2,
                    "text": "Live events"
                },
                {
                    "level": 2,
                    "text": "What to watch"
                },
                {
                    "level": 2,
                    "text": "Reaching a node from a collector"
                },
                {
                    "level": 2,
                    "text": "Where to go next"
                }
            ],
            "word_count": 903,
            "markdown": "# Monitoring & Observability\n\nWhat a node can tell you about itself, and which source to reach for. There are\nfive, and picking the wrong one is the usual reason a question feels hard to\nanswer.\n\n| Source | Answers | Shape |\n|---|---|---|\n| **Status** | Is this node healthy right now? | One snapshot |\n| **Metrics** | How much of what, over time? | Counters and gauges |\n| **Flows** | Who is actually talking to whom? | Live connections |\n| **Alerts** | Tell me when something crosses a line | Push |\n| **Audit** | Who changed what, and when? | Append-only history (API only) |\n\nLogs sit underneath all of them — see [Operations](/docs/operations) for reading\nthem.\n\n## Status: is this node healthy?\n\nThe first command to run, and usually the only one needed:\n\n```bash\ncenvero-str-ctl status\n```\n\nIt reports whether the agent is running, the licence state, the data plane, and\nthe bridges. When something is wrong this is where it shows up first.\n\nHealth checks run on their own schedule and record their results:\n\n```bash\ncenvero-str-ctl heal status      # latest result for every check\ncenvero-str-ctl heal check       # force a run now, don't wait for the schedule\n```\n\n`heal status` is the better command when you want to know whether a problem is\n*recurring* rather than whether it is happening this second.\n\n## Metrics: how much of what\n\n```bash\ncenvero-str-ctl metrics\ncenvero-str-ctl metrics --format json\n```\n\nA snapshot of the node's counters. The JSON form is what you scrape into whatever\nyou already use for graphing — the same data is available over the API at\n`GET /api/v1/metrics` for a collector that cannot run commands on the node.\n\nFor traffic volume specifically — how much a tenant or endpoint used, rather than\nhow the node is behaving — use accounting instead, which is what billing reads:\n\n```bash\ncenvero-str-ctl bandwidth list          # configured limits\ncenvero-str-ctl quota list              # volume caps and consumption\n```\n\n## Flows: who is talking to whom\n\nMetrics tell you a link is busy. Flows tell you *what* is making it busy.\n\n```bash\ncenvero-str-ctl flow list      # live connections\ncenvero-str-ctl flow stats     # aggregate view\n```\n\nThis is the tool for \"the network is slow\", \"is this rule doing anything\", and\n\"what is this host actually connecting to\". Over the API, flows can also be\nexported for offline analysis.\n\nTwo things to know. Flows show conversations the data plane is currently tracking,\nso a connection that finished is gone — this is a live view, not a history. And a\nlong-established connection appears even after you have tightened a rule against\nit, because existing conversations survive a policy change until they end or are\nflushed. That surprise is covered in\n[Zero-Trust Firewall](/docs/networking/firewall).\n\n## Alerts: tell me when something happens\n\nEverything above is you asking. Alerts are the node telling you.\n\n```bash\ncenvero-str-ctl alert condition list      # what is being watched\ncenvero-str-ctl alert list                # what is currently firing\ncenvero-str-ctl alert history             # what has fired before\ncenvero-str-ctl alert status              # is alerting itself working?\ncenvero-str-ctl alert ack <id>            # acknowledge a firing alert\n```\n\nConditions define what to watch for. Actions define what happens when one fires,\nso an alert can reach a system you already run rather than waiting to be noticed.\n\n**Check `alert status` occasionally.** It reports whether action dispatch is\nsucceeding. Alerting that is configured but silently failing to deliver is worse\nthan no alerting, because it is mistaken for quiet.\n\n## Audit: who changed what\n\nAn append-only record of changes made through the agent, with who made them and\nwhen. Reach for it when the question is \"why is this configured like this\" or\n\"what changed just before it broke\" — that second question is answered faster here\nthan in the logs.\n\nThe audit trail is available over the API at `GET /api/v1/audit`; there is no CLI\ncommand for it, so reading it needs the API turned on (see\n[Security Model](/docs/security)). On a node where the API is off, the agent's\nlogs in `/var/log/cenvero-str/` are the fallback — see\n[Operations](/docs/operations).\n\n## Live events\n\nFor a continuous feed rather than polling, the agent publishes events over a\nWebSocket on port 7072, grouped into categories (traffic, bandwidth, security,\nDHCP, DNS, network, alerts, system, load balancing, and clustering) so a consumer\ncan subscribe to only what it cares about. See the\n[Management API Reference](/docs/api).\n\n## What to watch\n\nIf you are setting up monitoring for the first time, start here:\n\n- **Agent up, and licence not frozen.** A frozen licence blocks changes silently\n  from a traffic standpoint — everything keeps flowing, so nothing looks wrong\n  until a change fails. Watch the licence state, not just the process.\n- **Health-check results.** Repeated failures of one check are the earliest\n  warning of most problems.\n- **Certificate expiry.** See [TLS/SSL & Licence Operations](/docs/tls-and-license).\n- **Gateway failover events.** A failover that happened and recovered is easy to\n  miss, and it usually means something is worth investigating.\n- **Cluster leadership changes.** Occasional is normal; frequent is not.\n- **Alert dispatch failures.** As above — verify the alerting path works.\n\n## Reaching a node from a collector\n\nThe CLI works over a local socket and needs no network, which is why it keeps\nworking when the API is off. A remote collector needs the API turned on, which\nmeans a token and an address allowlist — see [Security Model](/docs/security)\nbefore exposing it.\n\n## Where to go next\n\n- **[Operations](/docs/operations)** — logs, health checks, and troubleshooting.\n- **[Management API Reference](/docs/api)** — the endpoints behind these commands.\n- **[Security Model](/docs/security)** — before exposing the API to a collector.\n"
        }
    ]
}