API#

The module provides HTTP RESTful interface for accessing in JSON format basic information about a web server instance, as well as metrics of client connections, shared memory zones, DNS queries, HTTP requests, HTTP responses cache, TCP/UDP sessions of Stream Module, and zones of Limit Conn, Limit Conn, Limit Req and Upstream modules.

The API accepts GET and HEAD HTTP requests; other request methods cause an error:

{
    "error": "MethodNotAllowed",
    "description": "The POST method is not allowed for the requested API element \"/\"."
}

The Angie PRO API has a dynamic configuration that allows updating the settings without reloading the configuration or restarting Angie itself; currently, it enables configuring individual peers in an upstream.

Directives#

api#

Syntax

api path;

Default

Context

location

Enables HTTP RESTful interface in location.

path parameter is mandatory and works similar to the alias directive, but operates over API tree, rather than filesystem hierarchy.

When specified in a prefix location:

location /stats/ {
    api /status/http/server_zones/;
}

the part of request URI matching particular prefix location /stats/ will be replaced by the path /status/http/server_zones/ in the directive parameter. For example, on a request of /stats/foo/ the /status/http/server_zones/foo/ API element will be accessed.

Also it's possible to use variables: api /status/$module/server_zones/$name/ and the directive can also be specified inside a regexp location:

location ~^/api/([^/]+)/(.*)$ {
    api /status/http/$1_zones/$2;
}

here, similar to alias, parameter defines the whole path to the API element. E.g., from /api/location/bar/data/ the following positional variables will be populated:

$1 = "location"
$2 = "bar/data/"

which results after interpolation in /status/http/location_zones/bar/data API request.

Note

In Angie PRO, you can decouple the dynamic configuration API from the immutable metrics API that reflects current state:

location /config/ {
    api /config/;
}

location /status/ {
    api /status/;
}

Overall, it serves for precise configuration of API access rights, e.g.:

location /status/ {
    api /status/;

    allow 127.0.0.1;
    deny  all;
}

Or:

location /blog/requests/ {
    api /status/http/server_zones/blog/requests/;

    auth_basic           "blog";
    auth_basic_user_file conf/htpasswd;
}

api_config_files#

Syntax

api_config_files on | off;

Default

off

Context

location

Enables or disables the config_files object, which enumerates the contents of all Angie config files that are currently loaded by the server instance, in the /status/angie/ API section. For example, with this configuration:

location /status/ {
    api /status/;
    api_config_files on;
}

A query to /status/angie/ returns approximately this:

{
    "version":"1.7.0",
    "address":"192.168.16.5",
    "generation":1,
    "load_time":"2024-09-19T12:58:39.789Z",
    "config_files": {
        "/etc/angie/angie.conf": "...",
        "/etc/angie/mime.types": "..."
    }
}

By default, the object is disabled because the config files can contain extra sensitive, confidential details.

Metrics#

Angie exposes usage metrics in the /status/ section of the API; you can make it accessible by defining a respective location. Full access:

location /status/ {
    api /status/;
}

Subtree access, already discussed earlier:

location /stats/ {
    api /status/http/server_zones/;
}

Example configuration#

Configured with location /status/, resolver, http upstream, http server, location, cache, limit_conn in http and limit_req zones:

http {

    resolver 127.0.0.53 status_zone=resolver_zone;
    proxy_cache_path /var/cache/angie/cache keys_zone=cache_zone:2m;
    limit_conn_zone $binary_remote_addr zone=limit_conn_zone:10m;
    limit_req_zone $binary_remote_addr zone=limit_req_zone:10m rate=1r/s;

    upstream upstream {
        zone upstream 256k;
        server backend.example.com service=_example._tcp resolve max_conns=5;
       keepalive 4;
    }

    server {
        server_name www.example.com;
        listen 443 ssl;

        status_zone http_server_zone;
        proxy_cache cache_zone;

        access_log /var/log/access.log main;

        location / {
            root /usr/share/angie/html;
            status_zone location_zone;
            limit_conn limit_conn_zone 1;
            limit_req zone=limit_req_zone burst=5;
        }
        location /status/ {
            api /status/;

            allow 127.0.0.1;
            deny all;
        }

    }
}

Responds to curl https://www.example.com/status/ with the following JSON:

JSON tree
{
    "angie": {
        "version":"1.7.0",
        "address":"192.168.16.5",
        "generation":1,
        "load_time":"2024-09-19T12:58:39.789Z"
    },

    "connections": {
        "accepted":2257,
        "dropped":0,
        "active":3,
        "idle":1
    },

    "slabs": {
        "cache_zone": {
            "pages": {
                "used":2,
                "free":506
            },

            "slots": {
                "64": {
                    "used":1,
                    "free":63,
                    "reqs":1,
                    "fails":0
                },

                "512": {
                    "used":1,
                    "free":7,
                    "reqs":1,
                    "fails":0
                }
            }
        },

        "limit_conn_zone": {
            "pages": {
                "used":2,
                "free":2542
            },

            "slots": {
                "64": {
                    "used":1,
                    "free":63,
                    "reqs":74,
                    "fails":0
                },

                "128": {
                    "used":1,
                    "free":31,
                    "reqs":1,
                    "fails":0
                }
            }
        },

        "limit_req_zone": {
            "pages": {
                "used":2,
                "free":2542
            },

            "slots": {
                "64": {
                    "used":1,
                    "free":63,
                    "reqs":1,
                    "fails":0
                },

                "128": {
                    "used":2,
                    "free":30,
                    "reqs":3,
                    "fails":0
                }
            }
        }
    },

    "http": {
        "server_zones": {
            "http_server_zone": {
                "ssl": {
                    "handshaked":4174,
                    "reuses":0,
                    "timedout":0,
                    "failed":0
                },

                "requests": {
                    "total":4327,
                    "processing":0,
                    "discarded":8
                },

                "responses": {
                    "200":4305,
                    "302":12,
                    "404":4
                },

                "data": {
                    "received":733955,
                    "sent":59207757
                }
            }
        },

        "location_zones": {
            "location_zone": {
                "requests": {
                    "total":4158,
                    "discarded":0
                },

                "responses": {
                    "200":4157,
                    "304":1
                },

                "data": {
                    "received":538200,
                    "sent":177606236
                }
            }
        },
        "caches": {
            "cache_zone": {
                "size":0,
                "cold":false,
                "hit": {
                    "responses":0,
                    "bytes":0
                },

                "stale": {
                    "responses":0,
                    "bytes":0
                },

                "updating": {
                    "responses":0,
                    "bytes":0
                },

                "revalidated": {
                    "responses":0,
                    "bytes":0
                },

                "miss": {
                    "responses":0,
                    "bytes":0,
                    "responses_written":0,
                    "bytes_written":0
                },

                "expired": {
                    "responses":0,
                    "bytes":0,
                    "responses_written":0,
                    "bytes_written":0
                },

                "bypass": {
                    "responses":0,
                    "bytes":0,
                    "responses_written":0,
                    "bytes_written":0
                }
            }
        },

        "limit_conns": {
            "limit_conn_zone": {
                "passed":73,
                "skipped":0,
                "rejected":0,
                "exhausted":0
            }
        },

        "limit_reqs": {
            "limit_req_zone": {
                "passed":54816,
                "skipped":0,
                "delayed":65,
                "rejected":26,
                "exhausted":0
            }
        },

        "upstreams": {
            "upstream": {
                "peers": {
                    "192.168.16.4:80": {
                        "server":"backend.example.com",
                        "service":"_example._tcp",
                        "backup":false,
                        "weight":5,
                        "state":"up",
                        "selected": {
                            "current":2,
                            "total":232
                        },

                        "max_conns":5,
                        "responses": {
                            "200":222,
                            "302":12
                        },

                        "data": {
                            "sent":543866,
                            "received":27349934
                        },

                        "health": {
                            "fails":0,
                            "unavailable":0,
                            "downtime":0
                        },

                        "sid":"<server_id>"
                    }
                },

                "keepalive":2
            }
        }
    },

    "resolvers": {
        "resolver_zone": {
            "queries": {
                "name":442,
                "srv":2,
                "addr":0
            },

            "responses": {
                "success":440,
                "timedout":1,
                "format_error":0,
                "server_failure":1,
                "not_found":1,
                "unimplemented":0,
                "refused":1,
                "other":0
            }
        }
    }
}

Each JSON branch can be requested separately with the request constructed accordingly, e.g.:

$ curl https://www.example.com/status/angie
$ curl https://www.example.com/status/connections
$ curl https://www.example.com/status/slabs
$ curl https://www.example.com/status/slabs/<zone>/slots
$ curl https://www.example.com/status/slabs/<zone>/slots/64
$ curl https://www.example.com/status/http/
$ curl https://www.example.com/status/http/server_zones
$ curl https://www.example.com/status/http/server_zones/<http_server_zone>
$ curl https://www.example.com/status/http/server_zones/<http_server_zone>/ssl

Note

By default, the module uses ISO 8601 strings for date values; to use the integer epoch format instead, add the date=epoch parameter to the query string:

$ curl https://www.example.com/status/angie/load_time

  "2024-04-01T00:59:59+01:00"

$ curl https://www.example.com/status/angie/load_time?date=epoch

  1711929599

Server status#

/status/angie#

{
    "version": "1.7.0",
    "address": "192.168.16.5",
    "generation": 1,
    "load_time": "2024-09-19T16:15:43.805Z"
    "config_files": {
        "/etc/angie/angie.conf": "...",
        "/etc/angie/mime.types": "..."
    }
}

version

String; version of the running Angie web server

build

String; particular build name when it specified during compilation

address

String; the address of the server that accepted API request

generation

Number; total number of configuration reloads since last start

load_time

String or number; time of the last configuration reload, formatted as a date; strings have millisecond resolution

config_files

Object; its members are absolute pathnames of all Angie configuration files that are currently loaded by the server instance, and their values are string representations of the files' contents, for example:

{
    "/etc/angie/angie.conf": "server {\n  listen 80;\n  # ...\n\n}\n"
}

Caution

The config_files object is available in /status/angie/ only if the api_config_files directive is enabled.

Connections global metrics#

/status/connections#

{
  "accepted": 2257,
  "dropped": 0,
  "active": 3,
  "idle": 1
}

accepted

Number; the total number of accepted client connections

dropped

Number; the total number of dropped client connections

active

Number; the current number of active client connections

idle

Number; the current number of idle client connections

Slab allocator metrics of shared memory zones#

/status/slabs/<zone>#

Usage statistics of shared memory zones that utilize slab allocation, such as limit_conn, limit_req, and HTTP cache:

limit_conn_zone $binary_remote_addr zone=limit_conn_zone:10m;
limit_req_zone $binary_remote_addr zone=limit_req_zone:10m rate=1r/s;
proxy_cache cache_zone;

The specified shared memory zone will collect the following statistics:

pages

Object; memory pages statistics

    used

Number; the number of currently used memory pages

    free

Number; the number of currently free memory pages

slots

Object; memory slots statistics for each slot size. The slots object contains fields for requested memory slot sizes (e.g. 8, 16, 32, etc., up to half of the page size)

    used

Number; the number of currently used memory slots of specified size

    free

Number; the number of currently free memory slots of specified size

    reqs

Number; the total number of attempts to allocate memory slot of specified size

    fails

Number; the number of unsuccessful attempts to allocate memory slot of specified size

Example:

{
  "pages": {
    "used": 2,
    "free": 506
  },

  "slots": {
    "64": {
      "used": 1,
      "free": 63,
      "reqs": 1,
      "fails": 0
  }
}

Resolver DNS queries#

/status/resolvers/<zone>#

To collect resolver statistics, the resolver directive must set the status_zone parameter (HTTP and Stream):

resolver 127.0.0.53 status_zone=resolver_zone;

The specified shared memory zone will collect the following statistics:

queries

Object; queries statistics

    name

Number; the number of queries to resolve names to addresses (A and AAAA queries)

    srv

Number; the number of queries to resolve services to addresses (SRV queries)

    addr

Number; the number of queries to resolve addresses to names (PTR queries)

responses

Object; responses statistics

    success

Number; the number of successful responses

    timedout

Number; the number of timed out queries

    format_error

Number; the number responses with code 1 (Format Error)

    server_failure

Number; the number responses with code 2 (Server Failure)

    not_found

Number; the number responses with code 3 (Name Error)

    unimplemented

Number; the number responses with code 4 (Not Implemented)

    refused

Number; the number responses with code 5 (Refused)

    other

Number; the number of queries completed with other non-zero code

sent

Object; sent DNS queries statistics

    a

Number; the number of A type queries

    aaaa

Number; the number of AAAA type queries

    ptr

Number; the number of PTR type queries

    srv

Number; the number of SRV type queries

The response codes are described in RFC 1035, section 4.1.1.

Various DNS record types are detailed in RFC 1035, RFC 2782, and RFC 3596.

Example:

{
  "queries": {
    "name": 442,
    "srv": 2,
    "addr": 0
  },

  "responses": {
    "success": 440,
    "timedout": 1,
    "format_error": 0,
    "server_failure": 1,
    "not_found": 1,
    "unimplemented": 0,
    "refused": 1,
    "other": 0
  },

  "sent": {
    "a": 185,
    "aaaa": 245,
    "srv": 2,
    "ptr": 12
  }
}

HTTP server and location#

/status/http/server_zones/<zone>#

To collect the server metrics, set the status_zone directive in the server context:

server {
    ...
    status_zone server_zone;
}

The specified shared memory zone will collect the following statistics:

ssl

Object; SSL statistics. Present if server sets listen ssl;

    handshaked

Number; the total number of successful SSL handshakes

    reuses

Number; the total number of session reuses during SSL handshake

    timedout

Number; the total number of timed out SSL handshakes

    failed

Number; the total number of failed SSL handshakes

requests

Object; requests statistics

    total

Number; the total number of client requests

    processing

Number; the number of currently being processed client requests

    discarded

Number; the total number of client requests completed without sending a response

responses

Object; responses statistics

    <code>

Number; a non-zero number of responses with status <code> (100-599)

    xxx

Number; a non-zero number of responses with other status codes

data

Object; data statistics

    received

Number; the total number of bytes received from clients

    sent

Number; the total number of bytes sent to clients

Example:

"ssl": {
  "handshaked": 4174,
  "reuses": 0,
  "timedout": 0,
  "failed": 0
},

"requests": {
  "total": 4327,
  "processing": 0,
  "discarded": 0
},

"responses": {
  "200": 4305,
  "302": 6,
  "304": 12,
  "404": 4
},

"data": {
  "received": 733955,
  "sent": 59207757
}

/status/http/location_zones/<zone>#

To collect the location metrics, set the status_zone directive in the context of location or if in location:

location / {
    root /usr/share/angie/html;
    status_zone location_zone;

    if ($request_uri ~* "^/condition") {
        # ...
        status_zone if_location_zone;
    }
}

The specified shared memory zone will collect the following statistics:

requests

Object; requests statistics

    total

Number; the total number of client requests

    discarded

Number; the total number of client requests completed without sending a response

responses

Object; responses statistics

    <code>

Number; a non-zero number of responses with status <code> (100-599)

    xxx

Number; a non-zero number of responses with other status codes

data

Object; data statistics

    received

Number; the total number of bytes received from clients

    sent

Number; the total number of bytes sent to clients

Example:

{
  "requests": {
    "total": 4158,
    "discarded": 0
  },

  "responses": {
    "200": 4157,
    "304": 1
  },

  "data": {
    "received": 538200,
    "sent": 177606236
  }
}

Stream server#

/status/stream/server_zones/<zone>#

To collect the server metrics, set the status_zone directive in the server context:

server {
    ...
    status_zone server_zone;
}

The specified shared memory zone will collect the following statistics:

ssl

Object; SSL statistics. Present if server sets listen ssl;

    handshaked

Number; the total number of successful SSL handshakes

    reuses

Number; the total number of session reuses during SSL handshake

    timedout

Number; the total number of timed out SSL handshakes

    failed

Number; the total number of failed SSL handshakes

connections

Object; connections statistics

    total

Number; the total number of client connections

    processing

Number; the number of currently being processed client connections

    discarded

Number; the total number of client connections completed without creating a session

    discarded

Number; the total number of client connections relayed to another listening port with pass directives

sessions

Object; sessions statistics

    success

Number; the number of sessions completed with code 200, which means successful completion

    invalid

Number; the number of sessions completed with code 400, which happens when client data could not be parsed, e.g. the PROXY protocol header

    forbidden

Number; the number of sessions completed with code 403, when access was forbidden, for example, when access is limited for certain client addresses

    internal_error

Number; the number of sessions completed with code 500, the internal server error

    bad_gateway

Number; the number of sessions completed with code 502, bad gateway, for example, if an upstream server could not be selected or reached

    service_unavailable

Number; the number of sessions completed with code 503, service unavailable, for example, when access is limited by the number of connections

data

Object; data statistics

    received

Number; the total number of bytes received from clients

    sent

Number; the total number of bytes sent to clients

Example:

{
  "ssl": {
    "handshaked": 24,
    "reuses": 0,
    "timedout": 0,
    "failed": 0
  },

  "connections": {
    "total": 24,
    "processing": 1,
    "discarded": 0,
    "passed": 2
  },

  "sessions": {
    "success": 24,
    "invalid": 0,
    "forbidden": 0,
    "internal_error": 0,
    "bad_gateway": 0,
    "service_unavailable": 0
  },

  "data": {
    "received": 2762947,
    "sent": 53495723
  }
}

HTTP caches#

proxy_cache cache_zone;

/status/http/caches/<cache>#

For each zone configured with proxy_cache, the following data is stored:

{
  "name_zone": {
    "size": 0,
    "cold": false,
    "hit": {
      "responses": 0,
      "bytes": 0
    },

    "stale": {
      "responses": 0,
      "bytes": 0
    },

    "updating": {
      "responses": 0,
      "bytes": 0
    },

    "revalidated": {
      "responses": 0,
      "bytes": 0
    },

    "miss": {
      "responses": 0,
      "bytes": 0,
      "responses_written": 0,
      "bytes_written": 0
    },

    "expired": {
      "responses": 0,
      "bytes": 0,
      "responses_written": 0,
      "bytes_written": 0
    },

    "bypass": {
      "responses": 0,
      "bytes": 0,
      "responses_written": 0,
      "bytes_written": 0
    }
  }
}

size

Number; the current size of the cache

max_size

Number; configured limit on the maximum size of the cache

cold

Boolean; true while the cache loader loads data from disk

hit

Object; statistics of valid cached responses (proxy_cache_valid)

    responses

Number; the total number of responses read from the cache

    bytes

Number; the total number of bytes read from the cache

stale

Object; statistics of expired responses taken from the cache (proxy_cache_use_stale)

    responses

Number; the total number of responses read from the cache

    bytes

Number; the total number of bytes read from the cache

updating

Object; statistics of expired responses taken from the cache while responses were being updated (proxy_cache_use_stale updating)

    responses

Number; the total number of responses read from the cache

    bytes

Number; the total number of bytes read from the cache

revalidated

Object; statistics of expired and revalidated responses taken from the cache (proxy_cache_revalidate)

    responses

Number; the total number of responses read from the cache

    bytes

Number; the total number of bytes read from the cache

miss

Object; statistics of responses not found in the cache

    responses

Number; the total number of corresponding responses

    bytes

Number; the total number of bytes read from the proxied server

    responses_written

Number; the total number of responses written to the cache

    bytes_written

Number; the total number of bytes written to the cache

expired

Object; statistics of expired responses not taken from the cache

    responses

Number; the total number of corresponding responses

    bytes

Number; the total number of bytes read from the proxied server

    responses_written

Number; the total number of responses written to the cache

    bytes_written

Number; the total number of bytes written to the cache

bypass

Object; statistics of responses not looked up in the cache (proxy_cache_bypass)

    responses

Number; the total number of corresponding responses

    bytes

Number; the total number of bytes read from the proxied server

    responses_written

Number; the total number of responses written to the cache

    bytes_written

Number; the total number of bytes written to the cache

Added in version 1.2.0: PRO

In Angie PRO, if cache sharding is enabled with proxy_cache_path directives, individual shards are exposed as object members of a shards object:

shards

Object; lists individual shards as members

    <shard>

Object; represents an individual shard with its cache path for name

        sizes

Number; the shard's current size

        max_size

Number; maximum shard size, if configured

        cold

Boolean; true while the cache loader loads data from disk

{
  "name_zone": {
    "shards": {
        "/path/to/shard1": {
            "size": 0,
            "cold": false
        },

        "/path/to/shard2": {
            "size": 0,
            "cold": false
        }
    }
}

limit_conn#

limit_conn_zone $binary_remote_addr zone=limit_conn_zone:10m;

/status/http/limit_conns/<zone>, /status/stream/limit_conns/<zone>#

Objects for each configured limit_conn in http or limit_conn in stream contexts with the following fields

{
  "passed": 73,
  "skipped": 0,
  "rejected": 0,
  "exhausted": 0
}

passed

Number; the total number of passed connections

skipped

Number; the total number of connections passed with zero-length key, or key exceeding 255 bytes

rejected

Number; the total number of connections exceeding the configured limit

exhausted

Number; the total number of connections rejected due to exhaustion of zone storage

limit_req#

limit_req_zone $binary_remote_addr zone=limit_req_zone:10m rate=1r/s;

/status/http/limit_reqs/<zone>#

Objects for each configured limit_req with the following fields

{
  "passed": 54816,
  "skipped": 0,
  "delayed": 65,
  "rejected": 26,
  "exhausted": 0
}

passed

Number; the total number of passed connections

skipped

Number; the total number of requests passed with zero-length key, or key exceeding 65535 bytes

delayed

Number; the total number of delayed requests

rejected

Number; the total number of rejected requests

exhausted

Number; the total number of requests rejected due to exhaustion of zone storage

HTTP upstream#

Added in version 1.1.0.

To enable collection of the following metrics, set the zone directive in the upstream context, for instance:

upstream upstream {
    zone upstream 256k;
    server backend.example.com service=_example._tcp resolve max_conns=5;
    keepalive 4;
}

/status/http/upstreams/<upstream>#

where <upstream> is the name of any upstream specified with the zone directive

{
    "peers": {
        "192.168.16.4:80": {
            "server": "backend.example.com",
            "service": "_example._tcp",
            "backup": false,
            "weight": 5,
            "state": "up",
            "selected": {
                "current": 2,
                "total": 232
            },

            "max_conns": 5,
            "responses": {
                "200": 222,
                "302": 12
            },

            "data": {
                "sent": 543866,
                "received": 27349934
            },

            "health": {
                "fails": 0,
                "unavailable": 0,
                "downtime": 0
            },

            "sid": "<server_id>"
        }
    },

    "keepalive": 2
}

peers

Object; contains the metrics of the upstream's peers as subobjects whose names are canonical representations of the peers' addresses. Members of each subobject:

    server

String; the parameter of the server directive

    service

String; name of service as it's specified in server directie, if configured

    slow_start
    (PRO 1.4.0+)

Number; the specified slow_start value for the server, expressed in seconds.

When setting the value via the respective subsection of the dynamic configuration API, you can specify either a number or a time value with millisecond precision.

    backup

Boolean; true for backup servers

    weight

Number; configured weight

    state

String; current state of the peer:

  • checking (PRO): set to essential, being checked now, only probe requests are sent

  • down: disabled manually, no requests are sent

  • draining (PRO): similar to down, but requests from sessions that were earlier bound using sticky are still sent

  • recovering: recovering after failure according to slow_start, more requests are sent gradually

  • unavailable: reached the max_fails limit, a client request is attempted at fail_timeout intervals

  • unhealthy (PRO): not functioning properly, only probe requests are sent

  • up: operational, requests are sent as usual

    selected

Object; peer selection statistics

        current

Number; the current number of connections to peer

        total

Number; total number of requests forwarded to peer

        last

String or number; time when peer was last selected, formatted as a date

    max_conns

Number; the configured maximum number of simultaneous connections, if specified

    responses

Object; responses statistics

        <code>

Number; a non-zero number of responses with status <code> (100-599)

        xxx

Number; a non-zero number of responses with other status codes

    data

Object; data statistics

        received

Number; the total number of bytes received from peer

        sent

Number; the total number of bytes sent to peer

    health

Object; health statistics

        fails

Number; the total number of unsuccessful attempts to communicate with the peer

        unavailable

Number; how many times peer became unavailable due to reaching the max_fails limit

        downtime

Number; the total time (in milliseconds) when peer was unavailable for selection

        downstart

String or number; time when peer became unavailable, formatted as a date

        header_time
        (PRO 1.3.0+)

Number; average time (in milliseconds) to receive the response headers from the peer; see response_time_factor (PRO)

        response_time
        (PRO 1.3.0+)

Number; average time (in milliseconds) to receive the entire peer response; see response_time_factor (PRO)

    sid

String; configured id of the server in upstream group

keepalive

Number; the number of currently cached connections

health/probes (PRO)#

Changed in version 1.2.0: PRO

If the upstream has upstream_probe (PRO) probes configured, the health object also has a probes subobject that stores the peer's health probe counters, while the peer's state can also be checking and unhealthy, apart from the values listed in the table above:

{
    "192.168.16.4:80": {
        "state": "unhealthy",
        "...": "...",
        "health": {
            "...": "...",
            "probes": {
                "count": 10,
                "fails": 10,
                "last": "2024-09-19T09:56:07Z"
            }
        }
    }
}

The checking value of state isn't counted as downtime and means that the peer, which has a probe configured as essential, hasn't been checked yet; the unhealthy value means that the peer is malfunctioning. Both states also imply that the peer isn't included in load balancing. For details of health probes, see upstream_probe.

Counters in probes:

count

Number; total probes for this peer

fails

Number; total failed probes

last

String or number; last probe time, formatted as a date

queue#

Changed in version 1.4.0.

If a request queue is configured for the upstream, the upstream object also contains a nested queue object, which holds counters for requests in the queue:

{
    "queue": {
        "queued": 20112,
        "waiting": 1011,
        "dropped": 6031,
        "timedout": 560,
        "overflows": 13
    }
}

The counter values are aggregated across all worker processes:

queued

Number; total count of requests that entered the queue

waiting

Number; current count of requests in the queue

dropped

Number; total count of requests removed from the queue due to the client prematurely closing the connection

timedout

Number; total count of requests removed from the queue due to timeout

overflows

Number; total count of queue overflow occurrences

Stream upstream#

To enable collection of the following metrics, set the zone directive in the upstream context, for instance:

upstream upstream {
    zone upstream 256k;
    server backend.example.com service=_example._tcp resolve max_conns=5;
    keepalive 4;
}

/status/stream/upstreams/<upstream>#

Here, <upstream> is the name of an upstream that is configured with a zone directive.

{
    "peers": {
        "192.168.16.4:1935": {
            "server": "backend.example.com",
            "service": "_example._tcp",
            "backup": false,
            "weight": 5,
            "state": "up",
            "selected": {
                "current": 2,
                "total": 232
            },

            "max_conns": 5,
            "data": {
                "sent": 543866,
                "received": 27349934
            },

            "health": {
                "fails": 0,
                "unavailable": 0,
                "downtime": 0
            }
        }
    }
}

peers

Object; contains the metrics of the upstream's peers as subobjects whose names are canonical representations of the peers' addresses. Members of each subobject:

    server

String; address set by the server directive

    service

String; service name, if set by server directive

    slow_start
    (PRO 1.4.0+)

Number; the specified slow_start value for the server, expressed in seconds.

When setting the value via the respective subsection of the dynamic configuration API, you can specify either a number or a time value with millisecond precision.

    backup

Boolean; true for backup server

    weight

Number; the weight of the peer

    state

String; current state of the peer:

  • up: operational, requests are sent as usual

  • down: disabled manually, no requests are sent

  • draining (PRO): similar to down, but requests from sessions that were earlier bound using sticky are still sent

  • unavailable: reached the max_fails limit, a client request is attempted at fail_timeout intervals

  • recovering: recovering after failure according to slow_start, more requests are sent gradually

  • checking (PRO): set to essential, being checked now, only probe requests are sent

  • unhealthy (PRO): not functioning properly, only probe requests are sent

    selected

Object; the peer's selection metrics

        current

Number; current connections to the peer

        total

Number; total connections forwarded to the peer

        last

String or number; time when the peer was last selected, formatted as a date

    max_conns

Number; maximum number of simultaneous active connections to the peer, if set

    data

Object; data transfer metrics

        received

Number; total bytes received from the peer

        sent

Number; total bytes sent to the peer

    health

Object; peer health metrics

        fails

Number; total failed attempts to reach the peer

        unavailable

Number; times the peer became unavailable due to reaching the max_fails

        downtime

Number; total time (in milliseconds) that the peer was unavailable for selection

        downstart

String or number; time when the peer last became unavailable, formatted as a date

        connect_time
        (PRO 1.4.0+)

Number; average time (in milliseconds) taken to establish a connection with the peer; see the response_time_factor (PRO) directive.

        first_byte_time
        (PRO 1.4.0+)

Number; average time (in milliseconds) to receive the first byte of the response from the peer; see the response_time_factor (PRO) directive.

        last_byte_time
        (PRO 1.4.0+)

Number; average time (in milliseconds) to receive the complete response from the peer; see the response_time_factor (PRO) directive.

Changed in version 1.4.0: PRO

In Angie PRO, if the upstream has upstream_probe (PRO) probes configured, the health object also has a probes subobject that stores the peer's health probe counters, while the peer's state can also be checking and unhealthy, apart from the values listed in the table above:

{
    "192.168.16.4:80": {
        "state": "unhealthy",
        "...": "...",
        "health": {
            "...": "...",
            "probes": {
                "count": 2,
                "fails": 2,
                "last": "2024-09-19T11:03:54Z"
            }
        }
    }
}

The checking value of state isn't counted as downtime and means that the peer, which has a probe configured as essential, hasn't been checked yet; the unhealthy value means that the peer is malfunctioning. Both states also imply that the peer isn't included in load balancing. For details of health probes, see upstream_probe.

Counters in probes:

count

Number; total probes for this peer

fails

Number; total failed probes

last

String or number; last probe time, formatted as a date

Dynamic Configuration API (PRO only)#

Added in version 1.2.0.

The API includes a /config section that enables dynamic updates to Angie's configuration in JSON with PUT, PATCH, and DELETE HTTP requests. All updates are atomic; new settings are applied as a whole, or none are applied at all. On error, Angie reports the reason.

Subsections of /config#

Currently, configuration of individual servers within upstreams is available in the /config section for the HTTP and stream modules; the number of settings eligible for dynamic configuration is steadily increasing.

/config/http/upstreams/<upstream>/servers/<name>#

Enables configuring individual upstream peers, including deleting existing peers or adding new ones.

URI path parameters:

<upstream>

Name of the upstream; to be configurable via /config, it must have a zone directive configured, defining a shared memory zone.

<name>

The peer's name within the upstream, defined as <service>@<host>, where:

  • <service>@ is an optional service name, used for SRV record resolution.

  • <host> is the domain name of the service (if resolve is present) or its IP; an optional port can be defined here.

For example, the following configuration:

upstream backend {
    server backend.example.com:8080 service=_http._tcp resolve;
    server 127.0.0.1;
    zone backend 1m;
}

Allows the following peer names:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/_http._tcp@backend.example.com:8080/
$ curl http://127.0.0.1/config/http/upstreams/backend/servers/127.0.0.1/

This API subsection enables setting the weight, max_conns, max_fails, fail_timeout, backup, down and sid parameters, as described in server.

Note

There is no separate drain option here; to enable drain, set down to the string value drain:

$ curl -X PUT -d "drain" \
  http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com/down

Example:

curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com?defaults=on
{
    "weight": 1,
    "max_conns": 0,
    "max_fails": 1,
    "fail_timeout": 10,
    "backup": true,
    "down": false,
    "sid": ""
}

Actually available parameters are limited to the ones supported by the current load balancing method of the upstream. So, if the upstream is configured as random:

upstream backend {
    zone backend 256k;
    server backend.example.com resolve max_conns=5;
    random;
}

You will be unable to add a new peer that defines backup:

$ curl -X PUT -d '{ "backup": true }' \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend1.example.com
{
    "error": "FormatError",
    "description": "The \"backup\" field is unknown."
}

Note

Even with a compatible load balancing method, the backup parameter can only be set at new peer creation.

When deleting servers, you can set the connection_drop=<value> argument (PRO) to override the proxy_connection_drop, grpc_connection_drop, fastcgi_connection_drop, scgi_connection_drop, and uwsgi_connection_drop settings:

$ curl -X DELETE \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend1.example.com?connection_drop=off

$ curl -X DELETE \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend2.example.com?connection_drop=on

$ curl -X DELETE \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend3.example.com?connection_drop=1000

/config/stream/upstreams/<upstream>/servers/<name>#

Enables configuring individual upstream peers, including deleting existing peers or adding new ones.

URI path parameters:

<upstream>

Name of the upstream; to be configurable via /config, it must have a zone directive configured, defining a shared memory zone.

<name>

The peer's name within the upstream, defined as <service>@<host>, where:

  • <service>@ is an optional service name, used for SRV record resolution.

  • <host> is the domain name of the service (if resolve is present) or its IP; an optional port can be defined here.

For example, the following configuration:

upstream backend {
    server backend.example.com:8080 service=_example._tcp resolve;
    server 127.0.0.1:12345;
    zone backend 1m;
}

Allows the following peer names:

$ curl http://127.0.0.1/config/stream/upstreams/backend/servers/_example._tcp@backend.example.com:8080/
$ curl http://127.0.0.1/config/stream/upstreams/backend/servers/127.0.0.1:12345/

This API subsection enables setting the weight, max_conns, max_fails, fail_timeout, backup and down parameters, as described in server.

Note

There is no separate drain option here; to enable drain, set down to the string value drain:

$ curl -X PUT -d "drain" \
  http://127.0.0.1/config/stream/upstreams/backend/servers/backend.example.com/down

Example:

curl http://127.0.0.1/config/stream/upstreams/backend/servers/backend.example.com?defaults=on
{
    "weight": 1,
    "max_conns": 0,
    "max_fails": 1,
    "fail_timeout": 10,
    "backup": true,
    "down": false,
}

Actually available parameters are limited to the ones supported by the current load balancing method of the upstream. So, if the upstream is configured as random:

upstream backend {
    zone backend 256k;
    server backend.example.com resolve max_conns=5;
    random;
}

You will be unable to add a new peer that defines backup:

$ curl -X PUT -d '{ "backup": true }' \
    http://127.0.0.1/config/stream/upstreams/backend/servers/backend1.example.com
{
    "error": "FormatError",
    "description": "The \"backup\" field is unknown."
}

Note

Even with a compatible load balancing method, the backup parameter can only be set at new peer creation.

When deleting servers, you can set the connection_drop=<value> argument (PRO) to override the proxy_connection_drop settings:

$ curl -X DELETE \
    http://127.0.0.1/config/stream/upstreams/backend/servers/backend1.example.com?connection_drop=off

$ curl -X DELETE \
    http://127.0.0.1/config/stream/upstreams/backend/servers/backend2.example.com?connection_drop=on

$ curl -X DELETE \
    http://127.0.0.1/config/stream/upstreams/backend/servers/backend3.example.com?connection_drop=1000

HTTP Methods#

Let's consider the semantics of all HTTP methods applicable to this section, given this upstream configuration:

http {
    # ...

    upstream backend {
        zone upstream 256k;
        server backend.example.com resolve max_conns=5;
        # ...
    }

    server {
        # ...

        location /config/ {
            api /config/;

            allow 127.0.0.1;
            deny all;
        }
    }
}

GET#

The GET HTTP method queries an entity at any existing path within /config, just as it does for other API sections.

For example, the /config/http/upstreams/backend/servers/ upstream server branch enables these queries:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com/max_conns
$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
$ curl http://127.0.0.1/config/http/upstreams/backend/servers
$ # ...
$ curl http://127.0.0.1/config

You can obtain default parameter values with defaults=on:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers?defaults=on
{
    "backend.example.com": {
        "weight": 1,
        "max_conns": 5,
        "max_fails": 1,
        "fail_timeout": 10,
        "backup": false,
        "down": false,
        "sid": ""
    }
}

PUT#

The PUT HTTP method creates a new JSON entity at the specified path or entirely replaces an existing one.

For example, to set the max_fails parameter, not specified earlier, of the backend.example.com server within the backend upstream:

$ curl -X PUT -d '2' \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com/max_fails
{
    "success": "Updated",
    "description": "Existing configuration API entity \"/config/http/upstreams/backend/servers/backend.example.com/max_fails\" was updated with replacing."
}

Verify the changes:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
{
    "max_conns": 5,
    "max_fails": 2
}

DELETE#

The DELETE HTTP method deletes previously defined settings at the specified path; at doing that, it returns to the default values if there are any.

For example, to delete the previously set max_fails parameter of the backend.example.com server within the backend upstream:

$ curl -X DELETE \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com/max_fails
{
    "success": "Reset",
    "description": "Configuration API entity \"/config/http/upstreams/backend/servers/backend.example.com/max_fails\" was reset to default."
}

Verify the changes using defaults=on:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com?defaults=on
{
    "weight": 1,
    "max_conns": 5,
    "max_fails": 1,
    "fail_timeout": 10,
    "backup": false,
    "down": false,
    "sid": ""
}

The max_fails setting is back to its default value.

PATCH#

The PATCH HTTP method creates a new entity at the specified path or partially replaces or complements an existing one (RFC 7386) by supplying a JSON definition in its payload.

The method operates as follows: if the entities from the new definition exist in the configuration, they are overwritten; otherwise, they are added.

For example, to change the down setting of the backend.example.com server within the backend upstream, leaving the rest intact:

$ curl -X PATCH -d '{ "down": true }' \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
{
    "success": "Updated",
    "description": "Existing configuration API entity \"/config/http/upstreams/backend/servers/backend.example.com\" was updated with merging."
}

Verify the changes:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
{
    "max_conns": 5,
    "down": true
}

The JSON object supplied with the PATCH request was merged with the existing one instead of overwriting it, as would be the case with PUT.

The null values are a corner case; they are used to delete specific configuration items during such merge.

Note

This deletion is identical to DELETE; in particular, it reinstates the default values.

For example, to delete the down setting added earlier and simultaneously update max_conns:

$ curl -X PATCH -d '{ "down": null, "max_conns": 6 }' \
    http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
{
    "success": "Updated",
    "description": "Existing configuration API entity \"/config/http/upstreams/backend/servers/backend.example.com\" was updated with merging."
}

Verify the changes:

$ curl http://127.0.0.1/config/http/upstreams/backend/servers/backend.example.com
{
    "max_conns": 6
}

The down parameter, for which a null was supplied, was deleted; max_conns was updated.