This exact observation led to the creation of LinkSense — a lightweight, open-source synthetic monitoring tool developed by the Sycope team.
Synthetic monitoring is an approach in which you do not passively wait until something breaks and users report it. Instead, the system itself, at regular intervals, artificially generates traffic — sends a ping, makes an HTTP request, checks DNS — and measures how the monitored system responds. It is “synthetic” because this traffic is created for the purpose of the test and does not come from real users. As a result, you can learn about a problem before the customer notices it.
LinkSense is a project built around three very specific principles: no unnecessary complexity, no vendor lock-in and no excessive resource consumption.
Table of Contents
Where did LinkSense come from?
The story behind LinkSense is less corporate and more engineering-driven. Maciej Wilamowski, CIO of Sycope, and Marcin Kaźmierczak, Solution Architect, noticed that customers with truly large networks — covering many locations, data centers, applications and load balancers — needed a simple way to monitor connections: whether links between network points are working and how they actually behave.
The first reaction was predictable: “surely something like this already exists”. We live in times when there is a ready-made library or tool for almost every problem. Yes, Zabbix, Nagios and similar solutions exist, but it was not possible to find a system that was open source, extremely simple to configure and use, and well suited to large, distributed networks with many nodes and locations at the same time.
Since such a tool did not exist, and the idea itself seemed simple — it is enough to send a ping or an HTTP request from time to time to know whether a service is responding — the conclusion was clear: let’s write it ourselves. That is how LinkSense began.
Three principles that keep the project under control
1. No unnecessary complexity
LinkSense is a single small binary. Deployment comes down to the “copy the file and start the service” model. The entire configuration is based on text files in TOML format — separately for the agent itself and separately for the list of tasks. Defining a new task is simple enough that, in practice, it means copying one entry and changing a few values. Each task type has its own short README documentation, so there is no need to guess what individual fields mean.
Importantly, the project is strongly documented. There is a README for the entire project, for the agent, for the server and for each individual task separately. The documentation also includes information about the Rust ecosystem libraries used “under the hood”.
2. No vendor lock-in
Vendor lock-in is a situation in which a tool stores data in a closed, proprietary format and ties the user to a single ecosystem to such an extent that switching to another solution becomes costly or even impossible. Data is difficult to export, and key elements are “embedded” in a specific tool.
LinkSense does the opposite.
All data goes into a SQLite database — both on the agent side and on the server side. SQLite is a lightweight, file-based database: it does not require a separate database server, and everything is contained in a single file that can be opened with any SQL tool. The table structure is intentionally very simple so that LinkSense can be easily integrated with any other tool. If you want to extract your data and move it somewhere else, it comes down to a simple scenario: take the data from SQLite and copy it to another place. The license is permissive, meaning it allows the code to be freely used, modified and developed, and the code itself remains open.
This is a deliberate decision: LinkSense is a tool for collecting data, not for visualizing it. We will return to this topic later.
3. No excessive resource consumption
Here, the numbers speak for themselves. During a live demonstration in a webinar, an agent running for nearly an hour and executing several dozen different tasks — many pings, HTTP requests every several seconds, TLS and TCP tests — used 31 MB of memory and practically zero percent CPU, with fluctuations around 0–1%. The team also conducted long-term tests lasting more than a month, checking whether memory leaks or other issues appeared. The tests ended without a single failure.
This performance is partly the result of choosing Rust as the language in which LinkSense was written. Rust is valued for speed and efficient memory management. Asynchronous task execution is also crucial: instead of waiting for one test to finish, for example a ping that takes a fraction of a second, before starting the next one, the agent runs many tasks “in parallel” and does not block on any of them. As a result, one small process can handle several dozen tests at once without overloading the machine.
Architecture in a nutshell: the agent–server model
The core of the project is the division into agents and a central server. Agents are small binaries deployed in different locations. They perform assigned tests, store results locally in SQLite, and every 60 seconds create aggregated metrics and send them to the central server.
The direction of the connection is key: agents actively connect to the server, not the other way around. This brings two specific benefits.
Security. The agent can run on a machine with a firewall configured according to the “block incoming, allow outgoing” principle. It does not need any open ports. And no open ports means a significantly smaller attack surface — we have all heard about cases of monitoring agents being compromised, which can become a serious threat.
Simpler management. Only one machine needs open ports — the server. Securing one machine is much easier than protecting many distributed instances.
This model also has a third advantage: mass reconfiguration. Agent configuration can be changed from the server level. Imagine a ship with sixteen or more agents on board. If you want to add one new task to all of them, you do it with a single change in the configuration file on the server side. During the next update, the agent detects that its configuration is outdated, downloads the new version from the server, validates it and immediately starts using it.
The architecture is also “local-first”, meaning “locally first”. The agent saves results on its own side, locally, and only then sends them to the server. As a result, even if the server does not respond temporarily, agents do not lose data and continue monitoring during network issues. When connectivity returns, they send the collected metrics. Agents can also be run in a fully standalone mode. If you treat LinkSense as a small private project, you do not need a central server — it is enough to inspect the local SQLite database with any tool.
What can LinkSense monitor?
LinkSense offers a set of ready-made task types.
Ping — the simplest check of how quickly packets return and whether there is any packet loss, meaning whether some of the sent packets disappear along the way.
HTTP GET — full information about a page request. LinkSense breaks down the response time into components: the time needed to establish a TCP connection, the time needed to establish an encrypted connection, meaning the TLS handshake — the moment when the server and the client agree on encryption before any data is actually sent — time-to-first-byte, meaning the time until the first byte of the response and information about how long the server “thinks” before sending anything back, as well as the total download time. In addition, there are HTTP status codes, information on whether the certificate is valid, and how many days remain until it expires.
TCP and TLS — in practice, “subtasks” of HTTP GET. Sometimes you do not want to download the entire page, but only check whether a given port is open, meaning TCP, or whether encryption is established correctly, meaning TLS — without a full HTTP request.
DNS — checks whether domain names are correctly translated into IP addresses. Importantly, this task uses its own resolver, not the system resolver. A resolver is a mechanism that translates a name, for example sycope.com, into an IP address. The operating system usually remembers, or caches, results, so subsequent queries do not actually reach the DNS server. Its own resolver bypasses this cache and really queries DNS every time. As a result, you measure the actual state, not a remembered response.
HTTP content — allows you to inspect the response content using a regular expression, or regex — a pattern used to search for specific text in the page content. This is useful when an application returns a 200 status, meaning “everything OK”, but communicates, for example, a maintenance window in the content. The status code alone would not catch this, but matching a pattern in the content would.
Bandwidth — measurement of link throughput, always between the agent and the server. Queuing is used on the server side so that several tests launched at the same time do not distort one another’s results.
SQL query and SNMP query — optional tasks that go beyond the main purpose of the tool. An SQL query allows you to check not only whether the database responds, but also whether the data in it is correct, for example by counting how many rows a specific query returns. SNMP is a standard protocol for querying network devices about their state. It allows you to retrieve specific values from so-called OIDs, which are numeric identifiers of specific information in a device — for example CPU load, hostname or device description.
Typical use cases
These elements combine into specific usage scenarios:
- uptime monitoring, meaning availability — the percentage of time during which a service is actually working — in large networks, viewed from the perspective of geographically distributed endpoints, meaning end points: specific machines in different locations from which measurement is performed;
- measuring application and network performance;
- evaluating load balancers — devices or services that distribute traffic across multiple servers; in practice, it is useful to know whether each of them actually responds equally efficiently;
- checking DNS health and monitoring SLA levels, meaning Service Level Agreement — contractual availability and performance thresholds that the provider has committed to;
- checking SSL certificate expiration dates, so that you do not suddenly wake up to an “untrusted connection” message in production.
A deliberate “no”: no visualization and no alerting
By design, LinkSense does not have built-in visualization or alerting. This is not a missing feature, but a design decision. There are plenty of solutions for visualization, alerting and orchestration on the market. What was missing was a simple, lightweight, open-source tool for collecting data. The assumption is that a larger organization probably already has a system in which it wants to view and further process this data. By giving up visualization and alerting, LinkSense can remain so resource-efficient.
The absence of official containers follows the same philosophy. Since LinkSense is a single simple binary, containerization is trivial to do on your own, for example with your own docker compose that copies the binary and starts the service. The solution also works with Alpine Linux. Providing ready-made containers would not add much value here, and could take away part of the advantage related to low resource consumption.
This is not a “vibe-coded” project
The creators deliberately emphasize this distinction. Yes, they used tools such as Claude Code for development and documentation, because they genuinely speed up the work. However, the project structure was designed manually, and every line of code was reviewed. The documentation was also planned in terms of content and structure by a human, rather than generated in bulk. On top of that, there were the intensive, long-term tests mentioned earlier. This is why the authors are confident that the tool works stably and according to its assumptions.
A small technical note regarding Linux: if you want to run many pings in parallel, add the appropriate user or process to the ping group. This is because LinkSense performs pings asynchronously and efficiently, instead of being merely a wrapper around the system ping command.
Want to learn more about LinkSense directly from its creators? Watch the dedicated webinar with Maciej Wilamowski and Marcin Kaźmierczak, where they explain where the idea for the tool came from, how its architecture works and in which scenarios LinkSense can provide real support in monitoring distributed environments.
