Skip to content

Architectural Diagram

This page shows how WISdom fits together: what runs inside your network, what runs in Azure, and what crosses between the two. For the detail behind it, including encryption, retention, client isolation, and exact firewall rules, see Architecture and Security.

WISdom end-to-end architecture: a collector on its own host reads your SQL Server instances over the local network and sends data outbound over HTTPS to the WISdom platform in Azure

Nothing is installed on the instances you monitor. The WISdom Collector Service runs on its own machine and reads your SQL Server and Azure SQL instances over your local network using a service account. No agent is deployed to a database server.

Every connection out of your network is outbound and starts on your side. The collector opens an HTTPS connection to WISdom. Your people open HTTPS to the portal. WISdom never initiates a connection into your network, so no inbound internet rule is needed.

The two halves are independent. Collection keeps running when nobody has the portal open, and the portal keeps working while a collector is offline, showing data up to the last successful upload.

Where What Why it is there
Your environment WISdom Collector Service Reads the monitored instances and uploads to WISdom. One host serves many instances.
Your environment Collector Installer One-time setup that installs and registers the collector.
Your environment Monitored instances The SQL Server and Azure SQL instances themselves. Untouched by WISdom beyond being read.
Azure, public tier Collector API The single endpoint your collector uploads to.
Azure, public tier Portal UI and Portal UI API The application you log in to, and the backend that serves it.
Azure, private services Feed services Ingest and normalize what arrives from collectors.
Azure, private services Business services Analytics, the cost model, and everything the screens read.
Azure, private services Notification and scheduler Alert delivery and scheduled reports.
Azure, storage Blob Storage, SQL Server, ClickHouse, PostgreSQL WISdom’s own storage engines. See the note below.

How data gets from an instance to a screen

Section titled “How data gets from an instance to a screen”
  1. The collector reads metadata and workload data from each monitored instance on its collection schedule.
  2. The collector uploads to the Collector API over HTTPS, and reads its own configuration back from the same endpoint. A failed upload is retried, so a network interruption delays data rather than losing it.
  3. Feed services normalize the upload and write it to storage.
  4. Business services turn it into the metrics, costs, and findings the product shows.
  5. You open the Portal UI, authenticate through your own identity provider, and the Portal UI API serves the screens from what business services produced.

Internal service names, message protocols, container topology, and per-service scaling are not shown. They change without changing anything you need to plan for. What matters for planning is on this page: a collection host per network segment, one outbound HTTPS destination, local network access to the instances, and single sign-on for the portal.

Everything above is either ours to run or already yours. What you have to supply is short, and each item has a page with the exact detail:

What Where the detail is
A host for the collector, sized to the instance count [Installation and accounts2 and [Collection server sizing3
A service account the collector reads with [Collection accounts4
Windows-side prerequisites on the collection host [Windows collection requirements5
SQL Server permissions on the monitored instances [SQL collection requirements6
One outbound HTTPS destination through the firewall [Installation and accounts7
An identity provider for single sign-on [Single sign-on8

Read Installation and accounts before installing anything. It carries the operating-system rules, the exact ports, the antivirus exclusions, the service-account requirements, and the host sizing table.

If you are being asked to clear WISdom through a security review, Architecture and Security is the page to send. It covers encryption in transit and at rest, client isolation, what WISdom collects and what it explicitly does not, retention, and the network rules.

For the artifacts a reviewer usually asks for next, including the SOC 2 Type II and SOC 3 reports, the penetration test summary, the information security program, the subprocessor list, and the data-handling policies, go to the Fortified Trust Center.