ores.compute.node_sample
Table of Contents
One wrapper node's report, published fire-and-forget on
compute.v1.ops.node_sample and written here by the service. The
rows are append-only, one per node per interval, and the dashboard shows
the newest row of each node.
The model states :current_state: for the same reason grid_sample does:
a sample is a fact about an instant, so the bi-temporal pair has no
meaning on it.
The per-node newest read stays hand-written. It is a
DISTINCT ON (host_id) over the installation's rows, which no generated read
expresses: a read by host_id returns one node's rows, and a read of the
newest returns the grid's newest and not one row per node.
A sample describes the installation's own fleet, not one tenant's slice of
it, so the table carries :rls_own_or_system_tenant_rows:: every session
reads the system tenant's rows, and writes stay the current tenant's. The
C++ read states :tenant_read_scope: shared, so it adds no tenant
predicate and the policy decides.
1. Flags
2. Columns
2.1. id
Surrogate key, so the partition column can sit in the primary key beside it.
2.2. sampled_at
When the sample was taken.
2.3. host_id
The reporting node.
2.4. machine
The computer the node runs on, by the name it knows itself by. Several nodes share one, so this is what tells a computer being down from one node being down. Empty when the node did not say.
2.5. tasks_completed
Tasks the node finished since its wrapper started.
2.6. tasks_failed
Tasks that failed since the wrapper started.
2.7. tasks_since_last
Tasks the node finished since its previous sample.
2.8. avg_task_duration_ms
Mean task duration over the tasks since the last sample.
2.9. max_task_duration_ms
Longest task duration over the tasks since the last sample.
2.10. input_bytes_fetched
Bytes the node fetched for those tasks.
2.11. output_bytes_uploaded
Bytes the node uploaded for those tasks.
2.12. seconds_since_hb
Seconds since the node last heartbeated.
3. C++
3.1. Repository
The node rows describe the installation's fleet, not one tenant's slice of it, so the read states no tenant filter and the row-level-security policy is what decides. Mutations stay tenant-scoped.
3.2. Domain includes
#include <chrono> #include <cstdint>
3.3. Conventions
4. SQL
4.1. Flags
The retention policy keeps thirty days, which is what the hand-written
table set. The installation's own rows are readable by every session the
compute::grid_samples:read permission admits, and writes stay the
current tenant's.
4.2. Indexes
| name | columns | unique | current_only | where_extra |
|---|---|---|---|---|
| node_samples_host | host_id, sampled_at desc | false | false | |
| node_samples_tenant | tenant_id, sampled_at desc | false | false |
5. Physical space
The table is internal, like grid_sample, so only the data layer and the
SQL schema are generated.
| Address | Enabled |
|---|---|
| ores.cpp.service | false |
| ores.cpp.protocol | false |
| ores.cpp.nats-handler | false |
| ores.cpp.nats-sub-registrar | false |
| ores.cpp.nats-event-registrar | false |
| ores.cpp.nats-eventing | false |
| ores.cpp.nats-event-cache | false |
| ores.cpp.history-provider-registrar | false |
| ores.cpp.presentation | false |
| ores.cpp.eventing-integration-test | false |
| ores.cpp.shell-command | false |
| ores.sql.schema.notify_trigger | false |
| ores.sql.schema.notify_trigger_drop | false |
| ores.ts.protocol | false |
| ores.ts.domain | false |
6. See also
- ores.compute — component group overview.