The GUI, the CLI, and the Prometheus exporter
MooseFS ships three ways to observe a cluster: a GUI, the mfscli command, and a Prometheus metrics endpoint. None of them is part of any data or metadata path. They are clients of the cluster. The cluster runs the same without them. This page describes their place in the architecture: where each tool runs, where its data comes from, and what it is allowed to change.
One Python core serves all three
The GUI pages, mfscli, and the exporter are built on a shared Python core. One module of that core opens the connections. Another module models the cluster and its servers. A third module holds every query that the GUI and the CLI make. All of them use the MooseFS client protocol to reach the Master Server on its client port, 9421 by default, the same port that clients use for metadata. The full port list is in network ports.
Two things do not come from the Master Server: per-disk details and per-server chart data. The tools fetch both directly from each Chunkserver, on the port that the Chunkserver serves data on. Everything that the tools show comes from what the servers report about themselves. The tools read nothing from metadata files or disks.
Because the connection is an ordinary TCP client connection, the tools run on any machine that can reach those ports. An address, not an installation, sets which cluster the tools observe. The CLI takes the Master Server's address as an argument. The GUI takes the address as a request parameter. Both default to the host name mfsmaster. The tools resolve that name to all of its addresses and query each one. In a cluster with more than one Master Server PRO (PRO Edition only), a single name is therefore enough to find the Leader and to show the state of every Master Server.
The GUI is its own HTTP server
mfsgui is a daemon written in C. The daemon listens for web browsers on the address and port set in mfsgui.cfg (GUISERV_LISTEN_PORT, 9425 by default) and serves the interface to any browser that can reach that port. mfsgui.cfg is covered in configuration files. The server itself contains no cluster logic: it serves the static assets and runs the Python page scripts as CGI child processes, one per request. The host that it runs on therefore needs a Python 3 interpreter. That host does not need to be a Master Server or any other cluster machine.
These scripts compute the alerts that the GUI shows, from the same numbers that the servers report. The catalog of the alerts, with the meaning and the suggested fix for each, is in alerts.
The GUI server keeps no cluster state of its own. The Master Servers and the Chunkservers record the history that feeds the charts in their own stats files. The GUI fetches that history on request, so moving the GUI to another machine loses nothing.
The CLI prints text or JSON
mfscli is the GUI's terminal counterpart: the same queries against the same port, printed as text tables or, with -j, as JSON. Each switch selects one data set, so a script can ask for exactly the part of the cluster state that it needs. The commands and their manual pages are listed in command line tools. The switches themselves are listed in mfscli(1).
At installation the shared core is inlined into the mfscli script, so the command is one self-contained file that needs a Python 3 interpreter and nothing else from MooseFS on its host.
The exporter is a route on the GUI server
There is no exporter daemon and no separate exporter port. The GUI server's routing table maps /metrics to the same Python dispatcher as the pages. A scrape runs mfscli with JSON output on the GUI host, then converts the answer into the Prometheus text format. The exporter is the GUI and the CLI working together. Every scrape queries the cluster again.
Parameters in the scrape URL choose the data sets and charts that a scrape asks for. The load that a monitoring system puts on the Master Server therefore equals the load of the equivalent mfscli calls, repeated as often as that system scrapes. The metric names, and what the exporter leaves out, are listed in metrics.
Writing is limited to administrative commands
Everything above is reading. Both the GUI and the CLI also include a short list of administrative commands, which they send to the Master Server over the same client port. The commands switch a Chunkserver in or out of maintenance mode, send a Chunkserver back to work from its grace period, and remove a disconnected Chunkserver or a client session from the Master Server's lists. The GUI has one more command: dismissing a disk's reported error. That command goes directly to the Chunkserver that holds the disk, not through the Master Server. Nothing else that the tools do writes to the cluster.