Skip to main content

Collect Host Metrics with the ReductBridge Metrics Input

· 9 min read
Alexey Timin
Co-founder & CTO - Database & Systems Engineering

Host CPU, memory, and disk metrics flow through the ReductBridge metrics input to ReductStore, alongside industrial and robotics data from MQTT on one shared time index

Every host already exposes how busy it is. For observability and deployment-health monitoring, CPU, memory, and disk usage show whether the system producing your data is healthy. The ReductBridge metrics input collects these host metrics automatically: no SDK in an application, no broker, and no robot. Give the bridge a config file on a host and it writes the metrics to ReductStore as time-indexed JSON records.

The same bridge instance can also collect industrial or robotics data through MQTT, such as camera frames or PLC telemetry. Host health and production data then share one time index, so "what was the CPU doing when this frame was captured?" is a direct correlation, not an exercise in reconciling two monitoring systems.

This post walks through collecting host metrics from an edge PC, storing them beside a camera stream, and querying both back over the same time window.

Query CSV and Parquet Records in Place with ReductSelect

· 10 min read
Anthony Cavin
Co-founder & CEO - Data, ML & Robotics Systems

Machines often send several measurements at once. A controller might send a CSV packet every 200 milliseconds, with several readings in each packet. ReductStore stores each packet as a timestamped record, without splitting it into individual measurements. This keeps the original packets intact, even as the number of records grows.

Later, you might want to find readings above a threshold, calculate an average over a time window, or combine the packets into a Parquet file. Rather than downloading all the raw data and processing it in your application, you can use ReductSelect to process the records directly on the server.

Disaster Recovery for Time-Indexed Sensor Data

· 7 min read
Alexey Timin
Co-founder & CTO - Database & Systems Engineering

A robot or production line writes sensor data continuously. Eventually, a machine crashes, a disk fails, or a bad deployment corrupts an index. The real question is how much data loss and downtime you can afford when that happens.

The Disaster Recovery guide is the product reference: it describes the available mechanisms and their settings. This post focuses on choosing and deploying them. It covers cold backup, hot backup with the CLI, hot standby, and read-only replicas, including the downtime each requires and when each is appropriate for a robot or plant that cannot stop.