How to monitor particular kit with Oversight: which sensor to use, where on the device to set up access, which user function and extraction rows read the response, and how to write the rules that turn it into an alarm. Search for a vendor, a product or an error message. A misspelt word still finds its article when nothing matches exactly.
Oversight 1.x and 2.x work in opposite directions. 1.x only ever pulled: Oversight reached out from the centre, over a VPN, and took each reading itself. 2.x only ever receives: probes take the readings where they sit and push the results to Oversight. Oversight never reaches in to take a reading. This article explains the difference and the order in which the move is made.
What changes
| Oversight 1.x | Oversight 2.x | |
|---|---|---|
| Direction | Pull: Oversight fetches every reading | Push: probes send their results to Oversight |
| The path | A VPN to each remote network, usually IPsec | A WireGuard mesh, joined by two or more of your servers |
| Where checks are made from | The centre, across the VPN | Probe groups: GEN's in the UK, USA and Europe, and your own on your network |
| Proxmox clusters, devices and agents | Reached from the centre across the VPN | Checked by a probe on your own network |
The 1.x approach worked well. 2.x makes each check from wherever it makes most sense, and carries the results over two paths rather than one.
Step 1: the mesh
Two or more servers in your organisation join the Oversight mesh. Everything passing between your network and Oversight then travels over WireGuard, encrypted end to end, with nothing exposed to the internet.
There are at least two so that there are two paths. One server can be patched, rebooted or lost without results from anything behind it being held up. GEN sets the mesh up with you.
Step 2: probes
Probes are deployed on your network and gathered into a probe group of your own. It appears alongside GEN's groups when a sensor is configured, and only your organisation can see or use it. GEN enrols the probes and creates the group.
Your own group is for anything that is only reachable, or only meaningful, from inside: a Proxmox cluster, switches, storage, internal services. Its probes check them on your network and push the results to Oversight over the mesh. With two probes in the group, one can be down without its sensors going with it.
Step 3: agents
Servers that should give a verdict on their own health get an agent: see Linux agent and Windows agent. A probe reads the agent and pushes its verdict to Oversight along with its other results, so the agent need only answer the probe.
Step 4: configure Oversight
With the paths, probes and agents in place, the estate is built in Configuration as usual: see The Tree and Sensors.
Each sensor chooses its own probe groups, so groups can be mixed freely, even on one device:
| What is watched | Probe groups | Why |
|---|---|---|
| Your public web site | UK, USA and EU | Seen as your customers see it, from three places, so one bad path on the internet does not raise the alarm. |
| A Proxmox cluster | Your own group | Only reachable from inside, so checked there by your own probes. |
A sensor checked from one group has one view, so any failure it sees counts as ALL. See Rollup.
Remote support
If your agreement with GEN includes remote support, our support team reaches your systems over the same mesh. If it does not, the mesh is used for monitoring only.
The old VPN
Once your probes are pushing every reading, Oversight no longer pulls anything over the 1.x VPN. Whether it is taken down is your decision, since it may carry other traffic of your own.