logo
logo

Status

Status is an endpoint part of the REST API that can be used for monitoring purposes. Only the GET method is supported.

Note that from the version 2.9.0 of Sitecore Content Hub (including) the resource is expected to be always available unless the web server itself is experiencing problems. That means the resource HTTP code can not longer be used as the sole source information about the system status or health. For health monitoring purposes the resource itself has been extended with additional information.

Actions:

Here we describe most of the status resources. Note the resources are designed to be mostly self descriptive.

All the resources but the /api/status require authorized use, logged in as an administrator.

Status

GET /api/status

This action provides access to the index of all the available actions as well as some basic and minimal status information. Note this resource does not require authorization and is thus publicly visible.

The example of the resource payload is as follows:

{
    "hostname": "host_name",
    "aggregated_service_status_label": "{status}",
    "queues": {
        "href": "http://localhost:8080/api/status/queues",
        "title": "Status of the message queues"
    },
    "jobs": {
        "href": "http://localhost:8080/api/status/jobs",
        "title": "Status of the processing jobs"
    },
    "users": {
        "href": "http://localhost:8080/api/status/users",
        "title": "Status of the user base"
    },
    "licenses": {
        "href": "http://localhost:8080/api/status/licenses",
        "title": "State of your license"
    },
    "system": {
        "href": "http://localhost:8080/api/status/system",
        "title": "Obsolete resource, use graph, storage and or search resource instead"
    },
    "data_storage": {
        "href": "http://localhost:8080/api/status/datastorage",
        "title": "Status and statistics of the storage layer"
    },
    "search": {
        "href": "http://localhost:8080/api/status/search",
        "title": "Status and statistics of the search services"
    },
    "graph": {
        "href": "http://localhost:8080/api/status/graph{?forceRefresh}",
        "title": "Status and statistics of the graph server and its workers",
        "templated": true
    },
    "service_status": {
        "href": "http://localhost:8080/api/status/servicestatus",
        "title": "Detailed service status ecplaining the aggregating status here"
    },
    "kpis": {
        "href": "http://localhost:8080/api/status/kpis",
        "title": "Key performance indicators state"
    }
}

The resource provides access to all sub-resources and the following status information:

  • hostname : host name of the machine serving you this resource
  • aggregated_service_status_label: scalar service status describing overall health of the system. The value is color code string as described further. If it is not set to value Green it is advised to seek for more information in the /api/status/servicestatus resource.

Color coded service status: This color code is used not only in status resource but in the detailed services status listing as well. The code should be treated case insensitive. The values and their corresponding interpretation are:

  • Green: Everything is OK
  • Yellow: Everything is functional (i.e. service is available), however the Yellow status signalizes some performance issues. Under normal operation this status will be resolved to the Green status automatically in the reasonable short time. If that is not the case and yellow status lasts long, it should be perceived as a warning about the serious system performance degradation and resolved by human intervention.
  • Orange: this status is the first severe status of the service signalizing potentially severe issues, the service availability is not fully guaranteed if this status is set. It requires human intervention to decide if this state is blocking (like Red) or can be reasonably ignored (like Yellow). This state can signalize data loss, repetitive errors which can result in blocking behavior or any serious but not fatal condition.
  • Red: This is fatal, signalizing complete or severe service unavailability.

Queues

GET /api/status/queues

This action is returning statistics about the messages queues.

Version

GET /api/status/version

This action is returning an overview of the assemblies and corresponding versions.

Jobs

GET /api/status/jobs/{retentionPeriod}

This action is returning statistics about the job types and conditions using a specified retention period.
The retentionPeriod is an optional parameter (the default value is 30 days).

System

GET /api/status/system

This is obsolete resource, as of version 2.9.0 of Sitecore Content Hub, providing statistical information about Redis and Elasticsearch services. You should use instead the following resources:

  • /api/status/datastorage
  • /api/status/search
  • /api/status/graph
  • /api/status/servicestatus

Data storage

GET /api/status/datastorage

This resource provides status and statistics of the data storage, which is the core application storage excluding media assets storage. At the present time the data storage services are provided by the Redis instance and the provided statistical and status information heavily depends on the storage type.

Search

GET /api/status/search

This resource provides status and statistics of the search services. At the present time the search services are provided by Elasticsearch cluster with data retrieval backed up by the data storage. The statistical and status information heavily depends on the search services implementation and it is provided as is.

Graph

GET /api/status/system

This resource provides status and statistics of the graph service which is now hosted by the base service graph worker. The graph service acts as a bridge between the data storage and search services and it is vital for up to date information in the search services. The statistical and status information provided by this resource are the same as those exposed by the graph native REST API.

Service status

GET /api/status/servicestatus

In addition to the scalar service status value present in /api/status this resource provides a complete hierarchical listing of the services, their status (health) and additional metadata for troubleshooting. This resource is build with an intent to be service implementation agnostic, providing clear, human and machine readable overview. Example of this resource is as follows:

{
    "service_status_label": "Green",
    "service_status_message": "OK",
    "aggregated_service_status_label": "Yellow",
    "downstream_services": {
        "search": {
            "service_status_label": "Yellow",
            "service_status_message": "All primary shards are active, but not all replica shards are active.",
            "aggregated_service_status_label": "Yellow",
            "downstream_services": null
        },
        "data_storage": {
            "service_status_label": "Green",
            "service_status_message": "OK",
            "aggregated_service_status_label": "Green",
            "downstream_services": null
        },
        "graph": {
            "service_status_label": "Green",
            "service_status_message": "OK",
            "aggregated_service_status_label": "Green",
            "downstream_services": {
                "Stylelabs.M.Graph.Audit.AuditGraphWorker": {
                    "service_status_label": "Green",
                    "service_status_message": "No severe incidents have been reported",
                    "aggregated_service_status_label": "Green",
                    "downstream_services": null
                },
                "Stylelabs.M.Graph.ContinuousTests.FuzzServer": {
                    "service_status_label": "Green",
                    "service_status_message": "No severe incidents have been reported",
                    "aggregated_service_status_label": "Green",
                    "downstream_services": null
                },
                "Stylelabs.M.Graph.ElasticSearch.ElasticSearchGraphWorker": {
                    "service_status_label": "Green",
                    "service_status_message": "No severe incidents have been reported",
                    "aggregated_service_status_label": "Green",
                    "downstream_services": null
                }
            }
        }
    },
    "self": {
        "href": "{host}/api/status/servicestatus"
    }
}

As can be seen from the above example one can easily follow aggregated_service_status_label and downstream_services to pinpoint the source of the degraded performance or serious problems. The messages provided in service_status_message are meant to be brief but useful, at the present time it is necessary to reach for the individual services logs to get all available forensic information.

Can we improve this article ? Provide feedback