{"id":21,"date":"2026-06-06T06:55:00","date_gmt":"2026-06-06T06:55:00","guid":{"rendered":"https:\/\/newsmagazinexpro.kinsta.cloud\/demo\/?p=21"},"modified":"2026-10-02T09:54:34","modified_gmt":"2026-10-02T09:54:34","slug":"inside-radar-telemetry-part-1-vps-dedicated","status":"publish","type":"post","link":"https:\/\/www.firevm.com\/blog\/inside-radar-telemetry-part-1-vps-dedicated\/","title":{"rendered":"Inside our Radar Telemetry &#8211; Part 1 (for VPS &amp; dedicated)"},"content":{"rendered":"\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>TL;DR:<\/strong> We monitored the hardware of every VPS and dedicated server in Zabbix, but customers couldn&#8217;t see any of it. So we built our own hardware monitoring app on top of Zabbix: a private, no-login view for each customer, plus email alerts that reach them and our team at the same time.<\/p>\n<\/blockquote>\n\n\n\n<h1 class=\"wp-block-heading\">How it all started<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">It all started when, one fine day, a customer asked us: <strong>&#8220;Why has my server been so slow, and can I see how the hardware behaved over the past few weeks?&#8221;<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We could see all of it. Every reading was sitting in Zabbix, with the full history behind it. But the customer couldn&#8217;t see any of it. He was digging through his own code, database and logs, and he had no way to line up what he found with what the hardware was doing. What he debugged on his side was his business, not ours. The hardware side was ours to show.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And he couldn&#8217;t get it anywhere else. Natively, a data center panel doesn&#8217;t keep a history of your hardware readings. You might get a bandwidth graph or a power status, but nothing that answers questions like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Did memory climb for weeks before the slowdown?<\/li>\n\n\n\n<li>Was the disk slowly filling up, or did it happen overnight?<\/li>\n\n\n\n<li>Did disk response times spike last Tuesday at 3 a.m.?<\/li>\n\n\n\n<li>Was the load heavy all day, or only in short bursts?<\/li>\n\n\n\n<li>Did a DDoS attack spike my memory last Sunday?<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Without that history, he was guessing. Only a system recording every reading, all the time, could answer those questions, and we had one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We couldn&#8217;t just hand him a login, either. Our Zabbix holds the details of every customer in our ecosystem, and that is not something one customer should ever see.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Perfect monitoring. Zero proof.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is why we built Radar Telemetry.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Scope:<\/strong> this article is about our VPS and dedicated servers. Shared and reseller hosting are monitored in a different way, not through Zabbix, and will be covered in Part 2.<\/p>\n<\/blockquote>\n\n\n\n<h1 class=\"wp-block-heading\">The problem we had to solve<\/h1>\n\n\n\n<h3 class=\"wp-block-heading\">We could see everything, but our customers could see <em><span style=\"text-decoration: underline;\">nothing<\/span><\/em><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A customer who wanted to know why their server was slow had to ask us and take our word for it. That hurt <strong>transparency<\/strong>, and it also left them guessing.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And even though we could see everything on the hardware side, we couldn&#8217;t connect it to the customer&#8217;s debugging. We had no visibility into their site or application, so we couldn&#8217;t line our graphs up with what they were finding in their code. Only the customer could make that link, and only if they had the hardware graphs in front of them, next to their own findings. That is how they could tell whether a slowdown started with the server or with their code.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That gap cost us in a few ways:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Customers couldn&#8217;t check their own server&#8217;s health.<\/li>\n\n\n\n<li>&#8220;Is it you or is it us?&#8221; questions ended up as tickets.<\/li>\n\n\n\n<li>Customers only heard about a problem when we told them.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">We also wanted it readable by someone who isn&#8217;t a sysadmin, and we didn&#8217;t want to give every customer another password to manage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why off-the-shelf tools didn&#8217;t fit<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We tested the obvious options first. In our testing, each one fell short in a different way:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Grafana public dashboards<\/strong> didn&#8217;t support Zabbix as a data source. This is a <a href=\"https:\/\/github.com\/grafana\/grafana-zabbix\/issues\/1635\" target=\"_blank\" rel=\"noopener\">known issue<\/a> in the Zabbix plugin, where its queries are rejected on public dashboards, so the graphs never loaded for outside viewers.<\/li>\n\n\n\n<li><strong>Per-customer logins<\/strong> on a big monitoring system meant managing accounts for every customer, and trusting that each login only sees what it should.<\/li>\n\n\n\n<li><strong>Icinga<\/strong> has no built-in way to share a dashboard.<\/li>\n\n\n\n<li><strong>Checkmk<\/strong> works, but its interface felt too heavy to hand to customers.<\/li>\n\n\n\n<li><strong>Checkmate<\/strong> can watch CPU, RAM and disk through its optional agent, but that didn&#8217;t cover the full range of hardware readings we wanted.<\/li>\n\n\n\n<li><strong>Uptime checkers<\/strong> only look at a server from the outside, so they can&#8217;t see inside it.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>None of them<\/strong> gave us what we wanted: one customer, one server, no login.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">How we built it<\/h1>\n\n\n\n<h3 class=\"wp-block-heading\">Zabbix underneath, our own app on top<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We kept Zabbix, which already does the hard part well. Here is how the pieces fit:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A <strong>Zabbix agent<\/strong> on each server collects the hardware readings.<\/li>\n\n\n\n<li><strong>Zabbix<\/strong> runs on a separate server. It stores the readings, keeps the history, and flags problems.<\/li>\n\n\n\n<li><strong>Our own purpose-built Node.js application<\/strong> reads from the Zabbix data store through its API and turns the readings into the dashboard our customers see.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The application only ever reads data from Zabbix. It never changes anything in the monitoring system.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><a href=\"https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch.png\" target=\"_blank\" rel=\" noopener\"><img loading=\"lazy\" decoding=\"async\" width=\"1600\" height=\"900\" src=\"https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch.png\" alt=\"\" class=\"wp-image-536\" style=\"box-shadow:var(--wp--preset--shadow--natural);width:749px;height:auto\" srcset=\"https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch.png 1600w, https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch-300x169.png 300w, https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch-768x432.png 768w, https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch-1024x576.png 1024w, https:\/\/www.firevm.com\/blog\/wp-content\/uploads\/2026\/06\/radar-telemetry-arch-1536x864.png 1536w\" sizes=\"auto, (max-width: 1600px) 100vw, 1600px\" \/><\/a><figcaption class=\"wp-element-caption\"><em><strong>Zabbix collects and stores the data. Our app makes it readable and safe to share.<\/strong><\/em><\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">How a customer sees only their own server<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In our admin panel, each server gets its own private, unguessable link, with a label, a status and a view count. That link is tied to exactly one server, so the page can only ever show that server&#8217;s readings. There is no login, because the link itself is the key.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If a link needs to go, we can <strong>revoke it in one click<\/strong>. The link stops working at once, and no alert emails go out for it either.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">What goes on the dashboard<\/h1>\n\n\n\n<h3 class=\"wp-block-heading\">Deciding what to show, and what to cut<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A dashboard with every possible reading is a dashboard nobody reads. We went through the full list of hardware and kept only what actually fails in the real world.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Our rule:<\/strong> if a reading doesn&#8217;t help a customer catch a real fault, it doesn&#8217;t go on the dashboard.<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">We cut things like CPU steal time, disk queue size and raw network throughput. They are useful in a deep investigation, but they don&#8217;t help a customer decide if something is wrong. What stayed:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CPU, memory and swap, plus load averages over 1, 5 and 15 minutes<\/li>\n\n\n\n<li>Disk space and file counts (inodes), including a separate view for data disks<\/li>\n\n\n\n<li>Disk utilization and read and write wait times<\/li>\n\n\n\n<li>Network interface status, plus TCP connection counts that help us spot a DDoS attack early<\/li>\n\n\n\n<li>Uptime and whether the monitoring agent itself is responding<\/li>\n\n\n\n<li>SMART drive health on dedicated servers, read directly from the drive<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hardware only, on purpose<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We deliver VPS and dedicated servers as hardware. What runs on them, such as databases, web servers and apps, belongs to the customer. So the dashboard doesn&#8217;t include any software or application checks. Adding them would mean guessing at stacks we don&#8217;t manage, and it would blur the line of who is responsible for what.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Alerts and history<\/h1>\n\n\n\n<h3 class=\"wp-block-heading\">How the alerts work<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When something crosses a fault threshold, Zabbix sends the event to our app. Zabbix itself marks whether it is a new problem or a recovery, so the app never has to poll or guess.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Here is what happens next:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>The customer gets an email with the issue, a link to their own dashboard, and a note that we&#8217;re already working on it. Each server can have several recipients.<\/li>\n\n\n\n<li>Our team gets the same alert from Zabbix at the same moment.<\/li>\n\n\n\n<li>When the issue is fixed, Zabbix confirms the recovery. The customer gets a second email saying it is fixed and how long it lasted. The problem also stays logged in the dashboard&#8217;s problem history, which the customer can open anytime for the next two years.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Emails only go out for servers with an email on file and an active link. Every event sends an email, with no cooldown, because we would rather send a repeat than miss one. For long or critical incidents, we follow up with our customers separately via support ticket or WhatsApp.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Resolved problems, one click away<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The dashboard also keeps a record of problems that were fixed. It opens as a pop-up with the same time range buttons as the graphs, but it starts at the last 30 days, since that is what a customer usually wants to check first. Readings are kept for two years on a rolling basis.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">The takeaway<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">We didn&#8217;t try to build a monitoring system for our VPS and dedicated servers. Zabbix already is one, and it is trusted, open source and well tested. What was missing was the layer in between: a view that is safe to share, readable by anyone, and connected to alerts that reach us as fast as they reach you.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Want to see the result from the customer&#8217;s side? Read the product story in <strong><a href=\"https:\/\/www.firevm.com\/blog\/server-health-dashboard-radar-telemetry\/\" target=\"_blank\" rel=\"noopener\">What if server hardware spoke to you?<\/a><\/strong> or open the <a href=\"https:\/\/radar.firevm.com\/d\/demo\" target=\"_blank\" rel=\"noopener\"><strong>live demo dashboard<\/strong><\/a>. It runs on sample data.<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Running shared or reseller hosting with us? Part 2 covers how those accounts are monitored.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>We monitored the hardware of every VPS and dedicated server in Zabbix, but customers couldn&#8217;t see any of it. So we built our own hardware monitoring app on top of Zabbix: a private, no-login view for each customer, plus email alerts that reach them and our team at the same time<\/p>\n","protected":false},"author":1,"featured_media":540,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[28,27],"class_list":["post-21","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-dedicated-servers","tag-vps-hosting"],"_links":{"self":[{"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/posts\/21","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/comments?post=21"}],"version-history":[{"count":8,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/posts\/21\/revisions"}],"predecessor-version":[{"id":557,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/posts\/21\/revisions\/557"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/media\/540"}],"wp:attachment":[{"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/media?parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/categories?post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.firevm.com\/blog\/wp-json\/wp\/v2\/tags?post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}