Frequently Asked Questions

trcr is a network testing and monitoring daemon that continuously probes your infrastructure — servers, services, DNS, and network paths — and ships the results to your preferred data backend. It replaces ad-hoc scripts and fragmented tools (ping, traceroute, curl, iperf) with a single, configurable system that runs 24/7.

trcr supports five probe types: ICMP Ping for latency, jitter, and packet loss measurement; Traceroute for hop-by-hop network path analysis with automatic change detection; HTTP/HTTPS for web service health with full request phase breakdown (DNS, TCP, TLS, TTFB, transfer); DNS for resolver monitoring with configurable record types; and iperf3 for TCP/UDP bandwidth testing between nodes.

trcr supports four backend types that can be used simultaneously: Stdout/File for local debugging and log aggregation; Elasticsearch for full-text search, Kibana dashboards, and alerting; InfluxDB (v1, v2, and v3) for time-series storage and Grafana dashboards; and PostgreSQL for SQL queries, custom reporting, and long-term archival. PostgreSQL uses JSONB columns so new probe types never require schema migrations.

Everything is defined in a single YAML configuration file. This includes all targets, agents, probe types, output backends, and monitoring intervals. There's no database setup, no UI configuration step — just edit the YAML file and start the daemon. trcr supports both daemon mode (continuous monitoring) and one-shot mode for integration with cron or CI/CD pipelines.

No. trcr uses capability-based privilege escalation, meaning it only needs the specific kernel capabilities required for raw sockets (used by ICMP ping and traceroute). It ships with hardened systemd service units and does not require running as root.

When monitoring hundreds or thousands of targets, trcr automatically switches to a high-performance batch mode that uses a single raw socket to complete a full sweep in seconds rather than minutes. For each target, it measures round-trip time (min, average, max, standard deviation), jitter (variation between consecutive responses, critical for VoIP and video), and packet loss percentage.

trcr runs traceroutes continuously and automatically detects when the network path changes compared to the previous cycle. When traffic is rerouted (due to ISP failovers, BGP shifts, or misconfigurations), trcr flags the change and preserves the old path for comparison. This means you see routing changes as they happen, without needing to manually run traceroutes after the fact.

Every HTTP/HTTPS probe records the full request lifecycle: DNS resolution time (how long name lookup takes), TCP connect time (network-level connection), TLS handshake time (encryption overhead), Time to first byte (TTFB) (end-to-end server responsiveness), Transfer time (response body download), and the status code and protocol version. This breakdown isolates whether an issue is at the DNS, network, TLS, or application layer.

Yes. trcr integrates iperf3 for throughput testing between nodes. It measures TCP bandwidth with retransmit counts (which indicate congestion) and UDP bandwidth with jitter and packet loss. You can configure upload/download direction and test duration or byte count. This is particularly useful for capacity planning and verifying link performance after infrastructure changes.

The Master is the central scheduler: it runs its own probes, pushes configuration to agents, and collects all results into the output backends. Agents are lightweight daemons deployed on remote sites. When the master starts, it pushes the config to all agents, which begin probing immediately. Agent results flow back to the master and into the same dashboards and databases, tagged with the source host for filtering.

Each agent automatically probes every other agent, creating a full mesh measurement grid. A 10-agent deployment automatically produces 90 (10 × 9) measurement paths covering latency, loss, traceroute, HTTP, DNS, and bandwidth between every pair of sites — with zero per-agent configuration. Asymmetric issues (good in one direction, bad in the other) are immediately visible.

No. A single YAML config on the master defines the entire monitoring topology. When the master starts, it pushes the configuration to all agents automatically. You only maintain one config file regardless of how many agents you deploy. This makes scaling from 2 sites to 200 sites straightforward.

Absolutely. trcr works perfectly as a standalone monitoring daemon on a single host. You can monitor any number of external targets (up to your license limit) without deploying any agents. The agent architecture is optional — use it when you need monitoring from multiple vantage points.

Yes. trcr's free tier supports up to 5 monitored nodes with no license key required. All probe types (Ping, Traceroute, HTTP, DNS, iperf3) and all data backends (Elasticsearch, InfluxDB, PostgreSQL) are available on the free tier. There are no feature restrictions — only a node limit.

Paid licenses are tied to a machine serial number. This means the license is associated with the specific server running the trcr master. Each license has a configurable node limit that determines how many targets can be monitored. Contact our sales team to discuss the right license size for your deployment.

A monitored node is any unique target that trcr probes. This includes IP addresses, hostnames, and URLs defined in your configuration. Agents themselves do not count against your node limit — they are deployment points, not monitoring targets (unless you also probe them as targets).

Yes. Adding a license key to your configuration is a simple config change. You can upgrade at any time without stopping the daemon or losing any historical data. Your existing configuration, dashboards, and data all remain intact.

After creating an account, you can manage your licenses through the trcr self-service portal. The portal allows you to view your active licenses, track deployments, and access support — all in one place.