Docs · Automating

Monitors

A page that says whether something is up — every store's server, every till — drawn from a workflow's last answer.

A Check asks whether two systems agree. A monitor asks a plainer question, every few minutes: is it up? Is every store's server answering? Is every till reachable before the shops open?

A monitor is a page in the tree, in its own Monitors section between Checks and Apps. Each one is drawn from the last answer of a workflow: a table of what the workflow found, with status columns drawn as a coloured dot and a word, and the counts of each state above it.

#Live Hosts

The first kind of monitor, and the one New monitor builds:

Whether each store's server answers on a port, like nc -zvw 3 <host> 22.

It needs Business Locations to hold each store's server address as a property, a hostname or an IP. The setup asks for:

Create monitor builds a workflow and switches it on. It is an ordinary workflow, with four nodes:

1. On a schedule: every five minutes, or whatever you chose.
2. Places from Business Locations: one item for each store the query chose, with its address as host. The levels above the stores, which have no address, are left out.
3. Check a port: a TCP connection to each host, 32 at once, without a shell, so it works on Windows too.
4. Show on a monitor: what reaches it becomes the monitor's answer.

Each store comes out Online (green), Offline (red) or No address (grey), with its response time and, for one that did not answer, why.

#The monitor's page

The counts of each state sit above the table. Click one to show only the rows in that state; All shows them all again. Search narrows the rows by any value.

The page says when it was Checked. While it is open, it reads the answer again every 30 seconds. Check now runs the workflow at once rather than at its next scheduled time.

A monitor keeps up to 5,000 rows of an answer. One that held more says how many it shows of how many.

Settings reopens the Live Hosts setup, filled in from the workflow: which stores, where the addresses are kept, the port, the wait and how often. Saving writes them back into the workflow's nodes and checks again at once. The workflow is the one place those settings live, so its canvas shows the change.

#Display

Display decides how the workflow's answer is drawn:

• Which fields of the answer are columns, in what order, under what heading.
• Which columns are shown as a status. Each value a status column can hold is given a colour (green, amber, red or grey) and a word to show: online is a green dot and Online. * stands for any value not named above it.

The Live Hosts columns are where a new monitor starts: Store, Code, Server, Status, Response (ms), Why and Checked. From then on they are yours to change.

#The workflow behind it

Under each monitor in the tree, a Workflow folder lists the workflows that feed it: every workflow with a Show on a monitor node that names it.

Because it is an ordinary workflow, it can do more than the setup asks. Add a Send an email after Show on a monitor and filter it to the stores that went offline. Swap Check a port for a Run a script that asks each till for its software version. Anything that ends in Show on a monitor draws on the page.

#Who can do what

A viewer reads a monitor. Making one, changing its settings or display, pressing Check now and deleting it are an administrator's, as building a workflow is.

A monitor that has never been checked checks itself once, the first time an administrator opens it.

Deleting a monitor moves it to the bin and switches off the workflows that feed it. They are kept, not deleted. Restoring the monitor brings back its page; switch its workflows on again to have it checked.

A monitor can also be a tile on the Overview: its counts, one figure, what needs attention, or the whole table.