Monitoring & Observability

What a node can tell you about itself, and which source to reach for. There are five, and picking the wrong one is the usual reason a question feels hard to answer.

Source	Answers	Shape
Status	Is this node healthy right now?	One snapshot
Metrics	How much of what, over time?	Counters and gauges
Flows	Who is actually talking to whom?	Live connections
Alerts	Tell me when something crosses a line	Push
Audit	Who changed what, and when?	Append-only history (API only)

Logs sit underneath all of them — see Operations for reading them.

Status: is this node healthy?

The first command to run, and usually the only one needed:

cenvero-str-ctl status

It reports whether the agent is running, the licence state, the data plane, and the bridges. When something is wrong this is where it shows up first.

Health checks run on their own schedule and record their results:

cenvero-str-ctl heal status      # latest result for every check
cenvero-str-ctl heal check       # force a run now, don't wait for the schedule

heal status is the better command when you want to know whether a problem is recurring rather than whether it is happening this second.

Metrics: how much of what

cenvero-str-ctl metrics
cenvero-str-ctl metrics --format json

A snapshot of the node's counters. The JSON form is what you scrape into whatever you already use for graphing — the same data is available over the API at GET /api/v1/metrics for a collector that cannot run commands on the node.

For traffic volume specifically — how much a tenant or endpoint used, rather than how the node is behaving — use accounting instead, which is what billing reads:

cenvero-str-ctl bandwidth list          # configured limits
cenvero-str-ctl quota list              # volume caps and consumption

Flows: who is talking to whom

Metrics tell you a link is busy. Flows tell you what is making it busy.

cenvero-str-ctl flow list      # live connections
cenvero-str-ctl flow stats     # aggregate view

This is the tool for "the network is slow", "is this rule doing anything", and "what is this host actually connecting to". Over the API, flows can also be exported for offline analysis.

Two things to know. Flows show conversations the data plane is currently tracking, so a connection that finished is gone — this is a live view, not a history. And a long-established connection appears even after you have tightened a rule against it, because existing conversations survive a policy change until they end or are flushed. That surprise is covered in Zero-Trust Firewall.

Alerts: tell me when something happens

Everything above is you asking. Alerts are the node telling you.

cenvero-str-ctl alert condition list      # what is being watched
cenvero-str-ctl alert list                # what is currently firing
cenvero-str-ctl alert history             # what has fired before
cenvero-str-ctl alert status              # is alerting itself working?
cenvero-str-ctl alert ack <id>            # acknowledge a firing alert

Conditions define what to watch for. Actions define what happens when one fires, so an alert can reach a system you already run rather than waiting to be noticed.

Check alert status occasionally. It reports whether action dispatch is succeeding. Alerting that is configured but silently failing to deliver is worse than no alerting, because it is mistaken for quiet.

Audit: who changed what

An append-only record of changes made through the agent, with who made them and when. Reach for it when the question is "why is this configured like this" or "what changed just before it broke" — that second question is answered faster here than in the logs.

The audit trail is available over the API at GET /api/v1/audit; there is no CLI command for it, so reading it needs the API turned on (see Security Model). On a node where the API is off, the agent's logs in /var/log/cenvero-str/ are the fallback — see Operations.

Live events

For a continuous feed rather than polling, the agent publishes events over a WebSocket on port 7072, grouped into categories (traffic, bandwidth, security, DHCP, DNS, network, alerts, system, load balancing, and clustering) so a consumer can subscribe to only what it cares about. See the Management API Reference.

What to watch

If you are setting up monitoring for the first time, start here:

• Agent up, and licence not frozen. A frozen licence blocks changes silently

from a traffic standpoint — everything keeps flowing, so nothing looks wrong until a change fails. Watch the licence state, not just the process.

• Health-check results. Repeated failures of one check are the earliest

warning of most problems.

• Certificate expiry. See TLS/SSL & Licence Operations.
• Gateway failover events. A failover that happened and recovered is easy to

miss, and it usually means something is worth investigating.

• Cluster leadership changes. Occasional is normal; frequent is not.
• Alert dispatch failures. As above — verify the alerting path works.

Reaching a node from a collector

The CLI works over a local socket and needs no network, which is why it keeps working when the API is off. A remote collector needs the API turned on, which means a token and an address allowlist — see Security Model before exposing it.

Where to go next

• Operations — logs, health checks, and troubleshooting.
• Management API Reference — the endpoints behind these commands.
• Security Model — before exposing the API to a collector.