Observability

The platform reports everything it can see about your workload, and your code reports only what it alone knows. Both are named by one vocabulary, Telemetry Conventions, and your workload’s dashboard and default alerts are built from that vocabulary when it is admitted, so you write no dashboard and no alert rule to be watched.

Who	Reports
The platform	Your container’s CPU, memory, restarts and OOM kills; every call through the sidecar, by capability, operation and outcome, with its ack and its duration; every database connection the sidecar brokers, its pool wait, its time held, its statements and its lock waits; your probes’ results
Your code	The names of its operations and their outcomes, with each one’s ack and duration; its allocator’s statistics where it has them; its error log records; the domain series only it knows, such as orders settled
The vocabulary	Your dashboard and your default alerts, from the names both of the above report under

What your code reports

Your code reports through its OpenTelemetry SDK to the sidecar, which the platform points it at by OTEL_EXPORTER_OTLP_ENDPOINT. Name every HTTP route and every operation your code takes from a queue as the conventions name operations, and record its ack and, where callers wait on it, its duration. Log each failure as Error Logging states. The Telemetry Package does each of these in a line, and the plain SDK does them by the names the conventions state.

Keep every metric label to the conventions’ fixed sets. An account, a user, a request or any other value identifying a person or one event belongs on a log record or a span, never on a metric, and no record carries the content a person sent or was answered.

Uptime

The platform sends each probe your spec declares from beside your workload, on its interval, to each replica. A probe succeeds when the answer its kind expects arrives within its bound: the expected status for http, the connection accepted for tcp and a Binding success response for stun. It fails on any other answer, on a connection refused or reset, and on an answer arriving after the bound, so a slow workload is a down workload.

Your workload is up while the latest probe of each of its probes succeeded on at least one ready replica, and down once one probe has failed on every replica for 4 consecutive intervals. Its availability over a window is the share of the window’s probe intervals in which it was up. The series are vantacloud.probe.up and vantacloud.probe.duration, one point per probe sent, each carrying the probe’s name, your workload’s name as its target and the probe’s bound.

Default alerts

Each workload is given these alert rules when it is admitted, notifying the targets of its spec’s observability.notify, each named vantacloud-<workload>-<rule>.

Rule	Fires when
down	One of its probes has failed on every replica for 4 consecutive intervals
error-rate	More than 5% of its operations over 5 minutes end with the outcome class server-error
latency	The 99th percentile of an operation’s ack over 5 minutes exceeds observability.ackBoundMilliseconds, 300 when absent
memory	Its allocator’s resident bytes, or its container’s resident set where it reports no allocator, exceed 80% of its memory limit for 15 minutes

A default rule is changed only through the spec. Write rules of your own beside them as any alert rule is written.

Dashboard

Each workload is given a dashboard in its store’s provider console, named vantacloud-<workload>, drawing its uptime and availability against its probes’ bounds, its operations’ ack and duration percentiles and outcome classes, its errors by kind, its container and allocator memory, its sidecar calls and its database connections.

Conformance

A workload is conformant while, over the last 15 minutes, its records carry the service.name and vantacloud.conventions.version its spec names, the platform’s probe series arrive, and its code reports vantacloud.operation.ack for at least one operation. A workload that is not conformant still runs and its telemetry is still kept, but its dashboard and its error-rate and latency alerts read nothing.