Status API§

Unit collects information about the loaded language models, as well as instance- and app-wide metrics, and makes them available via the GET-only /status section of the control API:

Example:

{
    "modules": {
        "python": [
            {
                "version": "3.12.3",
                "lib": "/opt/unit/modules/python.unit.so"
            },
            {
                "version": "3.8",
                "lib": "/opt/unit/modules/python-3.8.unit.so"
            }
        ],

        "php": {
           "version": "8.3.4",
           "lib": "/opt/unit/modules/php.unit.so"
        }
    },

    "connections": {
        "accepted": 1067,
        "active": 13,
        "idle": 4,
        "closed": 1050
    },

    "requests": {
        "total": 1307
    },

    "telemetry": {
        "spans": {
            "exported": 1200,
            "failed": 0
        }
    },

    "applications": {
        "wp": {
            "processes": {
                "running": 14,
                "starting": 0,
                "idle": 4
            },

            "requests": {
                "active": 10
            }
        }
    }
}

The modules object has one member for each loaded language module. The member name is the module name, such as python or php. The member value is an object with the options below. If several versions of a module are loaded, the value is an array of these objects, one for each version:

The connections object offers the following Unit instance metrics:

Example:

"connections": {
    "accepted": 1067,
    "active": 13,
    "idle": 4,
    "closed": 1050
}

The requests object currently exposes a single instance-wide metric:

Example:

"requests": {
    "total": 1307
}

The telemetry object reports the health of the OpenTelemetry span exporter. It is omitted entirely unless Unit was built with OpenTelemetry support, the /config/settings/telemetry option is set, and the exporter was initialised successfully; its absence is how you tell telemetry is off rather than idle. An exporter that could not be built -- an unusable endpoint or protocol -- leaves the object absent despite the option being set, and reports the reason in the log. Its single spans member exposes two counters:

Both counters are cumulative since the exporter was last built, so changing any telemetry setting resets them to zero; re-applying an identical configuration does not. They count spans rather than export batches, and count only spans an export was attempted for: a span the sampling_ratio dropped appears in neither. Neither does a span the exporter discarded before attempting an export, which is what happens once the export queue fills behind a stalled collector -- so failed staying at zero does not by itself prove that nothing was lost.

A healthy pipeline shows exported rising while failed stays at zero. A rising failed means telemetry is being lost before it reaches the collector.

Example:

"telemetry": {
    "spans": {
        "exported": 1200,
        "failed": 0
    }
}

Each item in applications describes an app currently listed in the /config/applications section:

Example:

"applications": {
    "wp": {
        "processes": {
            "running": 14,
            "starting": 0,
            "idle": 4
        },

        "requests": {
            "active": 10
        }
    }
}

The processes object exposes the following per-app metrics:

Example:

"processes": {
    "running": 14,
    "starting": 0,
    "idle": 4
}