Ekalix Radar · how it works

From your servers to a page, a chart and an alert.

Ekalix Radar watches SQL Server and Azure SQL, PostgreSQL, MongoDB, Windows, IIS and Linux without installing anything on them. One Windows service on one machine reads them, keeps what it learns in one SQL Server database, shows it in a web page and tells people when something needs them. Here is how, part by part.

1 Windows service1 SQL Server database6 estates, read onlypage and API on :81000 agents on your servers

Drawn from Ekalix Radar 14.2 as it is built. Intervals and limits are the defaults; most can be changed in Configuration.

The big picture

Five stages, from your estate to people.

Everything Ekalix knows travels the same way: it is read from your servers over read-only connections, written to the Ekalix database, and served to people as pages, charts and notifications. Live views are the one exception: they go straight to the page and are never stored. Pick a flow to follow it.

Swipe the drawing sideways to see all of it.

SERVICE runs inside Ekalix.exe DASHBOARD runs inside the dashboard engine collection recorder alerts and notices pages and live views Library

Collection

A full picture of each server, every few minutes or when someone presses Monitor.

Automatic collection wakes, or someone presses Monitor.
The service collects SQL Server; the platform collectors do Windows, IIS, PostgreSQL, MongoDB and Linux.
Each snapshot is saved with its history line, changes and alerts.
The web server reads the snapshots and the page shows them.

Recorder

The measures behind every chart, once a minute.

The recorder reads each server once a minute.
The readings are written as samples, then rolled up into 15-minute and hourly buckets.
Each night, baselines learn what is usual for every hour of the week.
Performance charts read the samples and baselines.

Alerts and notices

From a problem on a server to a message in a channel.

The Sentinel, Ekalix's alerting, checks each server every minute; collections bring their own alerts.
Alerts are kept in the database, open until clean checks clear them.
Every 15 seconds routing decides who is told, and when.
Channels get the notice: Teams, Slack, e-mail, incident tools, SMS, syslog, the Event Log. The weekly report goes by e-mail.

Live views

The one path that skips the database.

A page opens a stream and says which servers and topics it shows.
The live hub reads only those, as often as each topic needs (vitals every 2 seconds).
Readings go straight to the page and are never stored.
When nobody watches, reading stops.

Library

Built-in questions and your own, on many servers at once.

Someone runs a question on up to 250 servers; a guard screens it first.
Twelve workers share the servers, so it runs on up to twelve at a time; T-SQL runs in a transaction that Ekalix rolls back.
The results are saved, encrypted, for 30 days.
The page shows the rows and can export them.

What runs where

One Windows service, one dashboard engine, one database.

Ekalix.exe is the Windows service Ekalix Radar. It starts the dashboard engine (Ekalix.Engine.exe, which runs the PowerShell web server and its background work) and runs its own recorder, alerting and SQL Server collector. The two talk over named pipes that only the account running Ekalix can open. A second Ekalix server can share the database as a standby.

The moving dots show which way things travel: requests and answers on the pipes, reads and writes on the database, notices on their way out.

Swipe the drawing sideways to see all of it.

SERVICE Ekalix.exe, the Windows service DASHBOARD Ekalix.Engine.exe, the dashboard engine pipes and control the database notices the page

Step by step

What happens, in the order it happens.

Each card follows one event through the product. The tag says where the step runs: service Ekalix.exe, dashboard the dashboard engine, database the Ekalix database, browser the page, server a monitored server.

A collection pass

dashboard Automatic collection wakes (every 15 minutes on a new installation; you choose 2 to 15), or someone presses Monitor.
dashboard Windows, IIS, PostgreSQL, MongoDB and Linux are collected by their own collectors, several at once, each saved as soon as it is in.
service SQL Server goes over the collector pipe to the service. It reads many machines at once, the servers on one machine one after another, and builds a full snapshot of each one.
database Each snapshot is saved: its configuration items and changes, the snapshot itself (compressed), its alerts and database sizes, then a history line.
database Across servers, availability-group databases are checked together, so a database backed up on another replica is not flagged; the estate's backup status is written once.
browser The page shows the new snapshots. If the service cannot be reached, PowerShell collects SQL Server in the same run.

A minute of the recorder

service The recorder takes a turn about every second and reads each server once a minute (one server at a time unless you add parallel readers).
server SQL Server: one batch of vitals, 11 wait groups and the cost of reading itself; every 5 minutes also the top statements and applications.
server Windows and IIS: performance counters over a kept session. MongoDB, PostgreSQL and Linux through the reader helper.
database The readings are written as samples. If the database refuses them for a moment, they wait in a file and are written later; a long outage leaves a gap.
service On the active server: roll-ups to 15-minute and hourly buckets every 5 minutes, upkeep every hour, baselines each night.
browser Performance charts read the stored samples and baselines.

A problem becomes a Teams message

service Every minute the Sentinel checks each server against the rules for its platform (56 built-in rules in all). Your custom SQL checks run every 15 minutes.
database A finding opens an alert after the rule's number of bad checks in a row. Alerts from collections arrive the same way.
service Every 15 seconds routing decides who is told: acknowledged, snoozed, known issues, maintenance, flapping and duplicates are taken into account.
service A matching policy sends the notice after its delay. Teams gets a card with the recent trend and how often this has happened.
service A send that may work later is retried after 1, 2, 5, 10, 30 and 60 minutes, then hourly, for up to 24 hours.
service Reminders follow every 60 minutes (three at most) until someone acknowledges. When the problem clears, the channels that were told get "resolved".

Someone acknowledges

browser They press "Acknowledge in Ekalix" in the message. The page opens the alert and asks them to confirm.
dashboard The acknowledgement is stored with the alert and written to the audit log.
service On the next routing pass the reminders stop, and incident tools, syslog, the Event Log and signed webhooks that were told hear about it once.

Opening a server and watching it live

browser The page loads its files (compressed, cached for a year by version), then asks for the configuration and status.
database Opening a server returns its stored snapshot as it is, plus its history for the small charts.
browser Live parts open one stream per tab and say which servers and topics they show.
server The live hub reads only what someone is watching (vitals every 2 seconds) and stops as soon as nobody is.
browser If the stream cannot be held, the page asks for readings instead.

A server is added

browser Someone fills in the form and presses Test: the connection is tried with that platform's own client.
database The server is saved; a password goes to the encrypted secrets, never into the server's definition. The change is audited.
server On SQL Server the MonitorEx event session is created if you leave it ticked (not on Azure SQL Database).
service Within 30 seconds the recorder notices and starts reading the server every minute.
dashboard Its first snapshot comes from Monitor or the next automatic pass.

A Library question on 40 servers

browser Someone runs a question on 40 servers. A guard screens the script first.
server Twelve workers share the 40 servers, up to twelve at a time: T-SQL in a transaction that Ekalix rolls back, PowerShell over WinRM, or MongoDB commands.
browser The page follows the run and can export the rows.
database The finished run is saved encrypted for 30 days and audited in the name of the person who started it.

A second Ekalix server takes over

database Two Ekalix servers share one database. The active one holds a lock in SQL Server and renews its leader record every 30 seconds.
dashboard The standby reads nothing, checks nothing and sends nothing. It asks for the lock every 10 seconds; its page says which server is active.
database When the active server stops, crashes or restarts, SQL Server releases its lock at once; the standby takes it within about 10 seconds and audits the change. If the server loses power or its network, SQL Server releases the lock after about half a minute.
service The new active server's alerting carries a new number, so the old one could not send even if it came back half-alive.

When the service stops answering

dashboard A bridge hears nothing from the service for 20 seconds, gets an error it cannot recover from, or sees no progress for 3 minutes.
dashboard It starts the PowerShell recorder or Sentinel to do the same work; pages do not change. This lasts until the dashboard restarts.
service The service, for its part, stops doing that work once it has heard nothing from the bridge for 15 seconds, so the two never do it at once.
service If the dashboard engine itself ends, the supervisor starts it again after 10 seconds, then three times longer each time, up to 5 minutes.

A licence reaches the product

browser The customer downloads a signed licence file from their account on ekalix.com.
dashboard They upload it in Administration. It is checked offline against Ekalix's public keys, its dates and the database it was issued for.
database It becomes the active licence. The dashboard reads it again every 30 seconds, the service every 10 minutes.
dashboard When a paid licence ends there are 30 days' grace with a warning; after that, or when a trial ends, collecting and adding servers pause. Everything already stored stays readable.

The database

What the Ekalix database keeps, and for how long.

One SQL Server database holds everything Ekalix keeps, apart from a few files on the Ekalix server's own disk (the last card). Snapshots are compressed; secrets, and the Library's questions and results, are encrypted; the audit log is append-only and hash-chained, with its head written outside the database each day, so a change to it can be detected. Retention is configurable; these are the defaults.

Servers and settings

The monitored servers and their definitions, without passwords mon.target
Every setting, with its full change history core.setting
Alerting, routing, known issues, maintenance, the leader record, the pause core.document
The licence, the Ekalix servers that use this database, the schema version

kept until changed; retired servers go after 90 days

What collections found

The latest snapshot of each server, compressed mon.snapshot
A history line per collection mon.collection · 400 days
Configuration items and graded changes mon.config_change · 400 days
Database sizes · 730 days; disk capacity and forecasts · 400 days

the estate's backup status, availability groups included, is one record

What the recorder measured

Raw readings in daily partitions mon.sample · 48 hours
15-minute buckets · 95 days; hourly buckets · 730 days
Baselines: low, typical and high for each hour of the week, from six weeks mon.baseline
Top statements and applications every 5 minutes · 14 days

roll-ups every 5 minutes, baselines nightly

Alerts and events

Alerts from collections, from the Sentinel's checks and from custom SQL mon.event
Acknowledgements and snoozes, stored with the alert
Captured events from the MonitorEx session: deadlocks, long queries, errors, file growth, blocking

open alerts kept; closed ones and events 400 days

Security

Passwords, keys and channel secrets (webhook addresses, integration keys), encrypted with the repository key - the key file you export at setup sec.secret
Sign-in sessions and Ekalix's own API tokens, kept only as hashes
The audit log: each line linked to the one before by a hash, and a trigger refuses updates and deletes audit.event

audit lines are never purged; sessions end after 60 min idle, 12 h at most

Library

Questions and every saved version, compressed and encrypted lib.item
Runs and their rows, compressed and encrypted lib.run

runs kept 30 days

On the Ekalix server's disk

Where the database is, and the repository key (protected by Windows) config\
Readings the database refused for a moment buffer\readings.jsonl
Pinned Linux host keys state\ssh\known_hosts
The daily audit anchors audit\anchors.jsonl; logs, kept 30 days

plus the Windows Event Log, source "Ekalix"

Service or PowerShell

Which parts run in the service today, and the way back.

The recorder, the alerting and SQL Server collection run in the compiled Windows service. Each keeps its PowerShell version, which takes over if the service stops answering. Everything else runs in the dashboard engine, which the service starts and keeps running.

Part	Runs in	If it stops
Recorder	The service	PowerShell takes over after 20 s without an answer, until the dashboard restarts
Alerting (Sentinel)	The service	The same: PowerShell takes over. The weekly report and the daily audit anchor run in the dashboard engine
SQL Server collection	The service	PowerShell collects in the same run
Windows, IIS, PostgreSQL, MongoDB and Linux collection	The dashboard engine	The service's supervisor starts the engine again
Web server, API, live hub, Library, setup	The dashboard engine	The service's supervisor starts the engine again: after 10 s, then longer each time, up to 5 min

When Ekalix is started without the service (an older scheduled task or Ekalix.cmd), everything runs in PowerShell.

Timings and limits

The numbers behind the drawing.

The defaults on a new installation. Most of them can be changed in Configuration.

Reading and collecting	Default
Recorder, each server	60 s 30 to 900 s, or off
Top statements and applications	5 min
Automatic collection	15 min 2, 5, 10 or 15 min, or off
Servers collected at once	2 × processors 4 to 16; 1 to 64 if set
Time limit per host	90-150 s Linux 90, Windows and IIS 120, MongoDB and PostgreSQL 150
Automatic pass time limit	30 min
Monitor runs at once	4
Live vitals	2 s only while watched
Library	250 servers 5,000 rows each by default; 30 s per server

Alerts and the server itself	Default
Sentinel check, each server	60 s 30 to 900 s
Event session read	5 min
Custom SQL checks	15 min 15 s time-out, always rolled back
Routing	15 s
Messages per channel	20 per hour then one note of what was held; incident tools, syslog, the Event Log, acknowledgements and resolves are never held
Reminders	every 60 min 3 at most
Retries of a failed send	up to 24 h 1, 2, 5, 10, 30, 60 min, then hourly
Leader lock, standby asks	10 s
Engine restart	10 s → 5 min

Safety and trust

What Ekalix does, and does not do.

Read only, no agents, secrets encrypted and changes audited. The details, for the people who sign off on it.

Read only, no agents

Nothing is installed on a monitored server. Ekalix connects with an account you choose: read-only rights on SQL Server, Azure SQL, PostgreSQL, MongoDB and Linux; on Windows and IIS it must be a local administrator.
The one write it makes is the MonitorEx event session on SQL Server: offered ticked as you add a server, it can be unticked then or removed later from Events.
Library questions and custom SQL checks are screened for statements that write, and T-SQL runs in a transaction that Ekalix rolls back. The rights you grant are the real limit: give the read-only rights from the install guide, not sysadmin.
The install guide lists the rights for every platform, and Setup writes the SQL Server and Windows grants to config\access.

Secrets and the audit log

Passwords and keys are encrypted with the repository key; the key file is protected by Windows and by the folder's permissions.
Statement text can be kept in full, masked (the default on new installations) or not at all.
Changes people make are audited in a hash-linked chain; once a day its head is written outside the database, so a rewritten trail no longer matches.

Who may do what

Sign-in with Windows (NTLM by default, Negotiate optional) or single sign-on.
Five roles (Owner, Administrator, Operator, Auditor and Viewer) over fifteen permissions, optionally limited to some servers.
Scripts use API tokens (90 days by default); every change they make is audited too.
Pausing all monitoring needs an Owner or Administrator whose access covers every server.

On the network

The page answers only on the Ekalix server itself until you open it to the network, which adds an address reservation (http://+:8100/) and a firewall rule.
For HTTPS, put the page behind your reverse proxy or load balancer and list that address in Configuration.
Licences are checked offline: Ekalix never needs to reach ekalix.com.
Outbound, Ekalix connects only where you point it: notification channels, single sign-on and, if you turn it on, the explanation service, which sends short excerpts of monitoring data to the provider you choose.

Glossary

The words used here.

Snapshot: Everything one collection learned about one server: configuration, health, backups, jobs, alerts. The latest one per server is kept.
Sample: One recorded reading of one measure (CPU, waits, sessions...) at one moment.
Roll-up: Samples summarised into 15-minute and hourly buckets (low, average, high), so history stays small.
Baseline: What is usual for a measure at this hour of the week, learned from six weeks of history.
Alert: A problem Ekalix found, open until enough clean checks clear it.
Notice: A message about an alert sent to a channel: fired, reminder, escalated, acknowledged or resolved.
Routing policy: Your rule for which alerts go to which channels, when and how often.
Sentinel: Ekalix's alerting: its checks, the alert list, routing and the channels.
Live hub: The part of the dashboard engine that reads a server only while someone watches it live, and streams the readings to the page without storing them.
Library: Questions, built in or your own (T-SQL, PowerShell or MongoDB commands), screened before they run, then run on up to 250 servers, twelve at a time; results kept encrypted for 30 days.
Bridge, pipe: How the dashboard engine and the service talk: a named pipe on the same machine that only the account Ekalix runs as can open.
Reader helper: A second copy of the engine that reads MongoDB, PostgreSQL and Linux for the service's recorder and checks.
Active, standby: With two Ekalix servers on one database, only the one holding the lock works; the other waits.
Audit anchor: Once a day the head of the audit chain (its entry number and hash) is written outside the database - to audit\anchors.jsonl, the Windows Application log and any channel that forwards the audit log - so a chain rewritten inside the database no longer matches.
MonitorEx: The optional event session on SQL Server that captures deadlocks, long queries, errors, file growth and blocking.

See it on a made-up estate.

The live demo is the real product with invented servers. The trial is fourteen days, every feature, up to 100 servers.

Open the live demo Free 14-day trial