Reports

This section lists what the reports give you, and the tasks on this page.

What you get:

What you do here:

Apache Superset draws the platform’s dashboards. Deployment Manager installs it as the reporting preset. The preset is six containers on one host. That host can be any host of the installation. The containers read the FTACS database and ClickHouse. Of the six, only superset-nginx publishes ports. It publishes them on every network interface of its server, so the firewall decides who can reach them.

To add reports to an installation:

This section lists the containers of the preset and what each one does.

All six run on ONE host. They find each other by name on a Docker bridge network. A bridge network does not cross machines. For this reason the topology builder keeps them together and does not let you split them.

A seventh container, superset-embed-proxy, runs on every server that runs the portal. Nobody adds it. The installation places it there whenever Superset is installed. The topology builder does not offer it.

This section explains who opens Superset, on which address, and through which containers.

The installation deploys everything below. You do not install nginx on either server. You do not copy a certificate. You edit nothing in /etc. It does not matter which server runs Superset’s six containers. It can be a server of their own, or the same server as the portal.

<portal name> is the name the browser uses for the portal. It is FT_UI_HOST if that was set. Otherwise it is the load balancer in front of the portal servers. Otherwise it is the portal server’s own name. DM fills in SUPERSET_URL with that address on port 4443. UI Backend gives this address to the browser.

UI Backend does not use that address for its own calls to Superset. There are two reasons. First, a container often cannot reach the public name of its own server. The firewall or NAT does not route a server back to itself. Second, the container would have to trust the portal’s certificate. So DM sets SUPERSET_INTERNAL_URL in UI Backend’s compose file, per server:

A value set in the server’s .env wins. UI Backend images from before SUPERSET_INTERNAL_URL support ignore it. They keep calling SUPERSET_URL.

If the installation has no portal, there is no proxy. SUPERSET_URL is then Superset’s own name on the admin port. The customer may publish the route under other names. In that case you can still type both SUPERSET_URL and SUPERSET_EMBED_ORIGINS on the Superset card.

This section describes the two database connections Superset uses.

Superset does not own the product data. It queries it. There are two connections. You answer both at install time.

The passwords for both are asked once. They are asked on the database’s own screen, not on Superset’s screen, because the database creates those accounts. The passwords are SUPERSET_MYSQL_PASSWORD (or SUPERSET_ORACLE_PASSWORD) and SUPERSET_CH_PASSWORD. Both accounts are read-only. The FTACS account has SELECT on the FTACS schema and nothing else. The ClickHouse account, superset_read, uses ClickHouse’s read-only profile: it can read, but it cannot write. A reporting tool that can write can also lose the data it reports on. For a database the customer runs, the same passwords are asked on Superset’s screen instead. This happens once the host is filled in.

This section explains how Superset dashboards appear inside the portal.

UI Backend can show Superset dashboards inside the portal. When Superset is installed together with UI Backend, you fill in nothing. The address, the account and its password come from the Superset installation itself. UI Backend’s own three fields are not asked. They appear again if Superset is not part of the installation. You can still point the portal at a Superset that runs somewhere else.

The browser allows the embedding only for the origins in SUPERSET_EMBED_ORIGINS. DM fills it in from the portal with two addresses. The first is the portal’s HTTPS address (https://<portal name>:<FT_UI_HTTPS_PORT>). The second is its address on the embed port (https://<portal name>:4443). Add any other address people use to open the portal. Give scheme, host and port, separated by commas. If the installation has no portal, the variable stays empty, and no site may embed.

This section explains how the shipped dashboards get into Superset.

You do not import anything by hand. The superset container does it every time it starts, after its own setup. It installs the dashboards that ship in the bundle (superset/dashboards/ft-dashboards.zip). It also prepares the portal’s System reports pages. The container log shows this in [dashboards] lines. One line says how many dashboards are in Superset (in_superset=). The last line says how many reports are embedded (embedded reports=).

What it does, in order:

If a step fails, the log says [init] ERROR the dashboards are not fully installed. Superset starts anyway, so you can fix the connection in its screens. The next restart tries again.

The Support Center’s Sessions page has no dashboard in the bundle. It says "The identifier is not set" until someone chooses one in its settings.

You can apply a changed dashboard from a newer bundle over an existing one. To do that:

The mapping itself is in one file, superset/dashboards/EMBEDDED.txt.

This section lists what the bundle contains and which dashboards it leaves out.

The bundle carries 21 dashboards, 50 charts and 90 datasets.

Seven dashboards from the source export are not installed: Current Inventory Status, Device performance, Network Performance, Speed & Latency Analysis, User Experience, User Experience User Analysis and Wi-Fi client analysis. 31 of their charts arrived without a dataset. Superset refuses a bundle that contains even one such chart. Without those charts, the dashboards would show empty tiles. They come back when someone supplies a corrected export. None of them is used by a System reports page.

One dashboard from the source export, WI-FI Access Point Overview, is not installed on purpose. Its three Wi-Fi charts read database views (wifi_band_view, wifi_standard_view, wifi_security_view). No installation creates these views. Someone made them by hand on the machine the export came from. If the dashboard were shipped, it would show a database error instead of a chart. The dashboard comes back when those views become part of the product.

On Oracle, everything else works. The dialect differences are handled. The product’s own migrations create the tables the dashboards read, on Oracle as on MySQL.

This section explains the Superset administrator account.

The administrator account is created on first start from SUPERSET_USERNAME and SUPERSET_PASSWORD. If you later change the password in the installation’s variables, it does not change in Superset. By then the account already exists. To change the password, change it inside Superset. This also means a restart does not silently undo a password that was changed in Superset.

This section lists common symptoms and what they mean.