Interface Health

Health service interface

interface Health {
    checks?: Checks;
    description?: string;
    instanceId: string;
    links?: { about?: string; related?: string; self?: string };
    name: string;
    namespace?: `x-${string}`;
    notes?: string[];
    output?: string;
    release: string;
    serviceGroupId?: string;
    serviceId?: string;
    status: "pass" | "fail" | "warn";
    tags?: string[];
    version: string;
}

Hierarchy (View Summary)

Properties

checks? description? instanceId links? name namespace? notes? output? release serviceGroupId? serviceId? status tags? version

Properties

Optionalchecks

checks?: Checks

The “checks” object MAY have a number of unique keys, one for each logical sub-components. Since each sub-component may be backed by several nodes with varying health statuses, the key points to an array of objects. In case of a single-node sub-component (or if presence of nodes is not relevant), a single-element array should be used as the value, for consistency. The key identifying an element in the object should be a unique string within the details section. It MAY have two parts: {componentName}:{metricName}, in which case the meaning of the parts SHOULD be as follows:

  • componentName: Human-readable name for the component. MUST not contain a colon, in the name, since colon is used as a separator
  • metricName: Name of the metrics that the status is reported for. MUST not contain a colon, in the name, since colon is used as a separator and can be one of:
    • Pre-defined value from this spec. Pre-defined values include:
      • utilization
      • responseTime
      • connections
      • uptime
    • A common and standard term from a well-known source such as schema.org, IANA or microformats.
    • A URI that indicates extra semantics and processing rules that MAY be provided by a resource at the other end of the URI. URIs do not have to be dereferenceable, however. They are just a namespace, and the meaning of a namespace CAN be provided by any convenient means (e.g. publishing an RFC, Swagger document or a nicely printed book).

Optionaldescription

description?: string

Service description

Example

`My own service description`

instanceId

instanceId: string

Service instance unique identification within the scope of the service identification

Example

`085f47e9-7fad-4da1-b5e5-31fc6eed9f94`

Optionallinks

links?: { about?: string; related?: string; self?: string }

Service related links

Type declaration

  • Optionalabout?: string

    About link for the service

    Example

    `https://www.mytra.es/about`
  • Optionalrelated?: string

    Related link for the service

    Example

    `https://www.mytra.es`
  • Optionalself?: string

    Link to the own service or health endpoint

    Example

    `http://localhost:3000/v1/health`

name

name: string

Service name

Example

`myOwnService`

Optionalnamespace

namespace?: `x-${string}`

Service namespace, used to identify declare which namespace the service belongs to. It must start with x- as it is a custom namespace and will be used for custom headers, openc2 commands, etc.

Example

`x-mytra`

Optionalnotes

notes?: string[]

Array of notes relevant to current state of health

Optionaloutput

output?: string

Raw error output, in case of “fail” or “warn” states. This field SHOULD be omitted for “pass” state.

release

release: string

Service release. Its recommended to use semantic versioning.

Example

`1.0.0`

OptionalserviceGroupId

serviceGroupId?: string

Service group unique identification

Example

`firehose`, `driver`

OptionalserviceId

serviceId?: string

Service unique identification

Example

`uplink-firehose`, `mqtt-driver`

status

status: "pass" | "fail" | "warn"

Indicates whether the service status is acceptable or not

Optionaltags

tags?: string[]

List of string values that can be used to add service-level labels.

Example

`["primary", "test"]`

version

version: string

Service version

Example

`1`

Settings

Member Visibility

On This Page

Properties