[[watcher-api-stats]]
=== Stats API

The `stats` API returns the current {watcher} metrics. You can control what
metrics this API returns using the `metric` parameter.

The supported metrics are:

[options="header"]
|======
| Metric               | Description
| `executing_watches`  | Include the current executing watches in the response.
| `queued_watches`     | Include the watches queued for execution in the response.
| `_all`               | Include all metrics in the response.
|======

The {watcher} `stats` API always returns basic metrics regardless of the
`metric` option. The following example calls the `stats` API including the
basic metrics:

[source,js]
--------------------------------------------------
GET _xpack/watcher/stats
--------------------------------------------------
// CONSOLE

A successful call returns a JSON structure similar to the following example:

[source,js]
--------------------------------------------------
{
   "watcher_state": "started",  <1>
   "watch_count": 1, <2>
   "execution_thread_pool": {
      "size": 1000, <3>
      "max_size": 1 <4>
   }
}
--------------------------------------------------

<1> The current state of watcher. May be either `started`, `starting` or `stopped`.
<2> The number of watches currently registered.
<3> The number of watches that were triggered and currently queued for execution.
<4> The largest size of the execution thread pool indicating the largest number
    of concurrent executing watches.

==== Current executing watches metric

The current executing watches metric gives insight into the watches that are
currently being executed by {watcher}. Additional information is shared per
watch that is currently executing. This information includes the `watch_id`,
the time its execution started and its current execution phase.

To include this metric, the `metric` option should be set to `executing_watches`
or `_all`.

The following example specifies the `metric` option as a query string argument
and will include the basic metrics and metrics about the current executing watches:

[source,js]
--------------------------------------------------
GET _xpack/watcher/stats?metric=executing_watches
--------------------------------------------------
// CONSOLE

The following example specifies the `metric` option as part of the url path:

[source,js]
--------------------------------------------------
GET _xpack/watcher/stats/current_watches
--------------------------------------------------
// CONSOLE

The following snippet shows an example of a successful JSON response that
captures a watch in execution:

[source,js]
--------------------------------------------------
{
   "watcher_state": "started",
   "watch_count": 2,
   "execution_thread_pool": {
      "queue_size": 1000,
      "max_size": 20
   },
   "current_watches": [ <1>
      {
         "watch_id": "slow_condition", <2>
         "watch_record_id": "slow_condition_3-2015-05-13T07:42:32.179Z", <3>
         "triggered_time": "2015-05-12T11:53:51.800Z", <4>
         "execution_time": "2015-05-13T07:42:32.179Z", <5>
         "execution_phase": "condition" <6>
      }
   ]
}
--------------------------------------------------

<1> A list of all the Watches that are currently being executed by {watcher}.
    When no watches are currently executing an empty array is returned. The
    captured watches are sorted by execution time in descending order. Thus the
    longest running watch is always at the top.
<2> The id of the watch being executed.
<3> The id of the watch record.
<4> The time the watch was triggered by the trigger engine.
<5> The time the watch was executed. This is just before the input is being
    executed.
<6> The current watch execution phase. Can be `input`, `condition` `actions`,
    `awaits_execution`, `started`, `watch_transform`, `aborted`, `finished`.

In addition you can also specify the `emit_stacktraces=true` parameter, which
adds stack traces for each watch that is being executed. These stacktraces can
give you more insight into an execution of a watch.

==== Queued watches metric

{watcher} moderates the execution of watches such that their execution won't put
too much pressure on the node and its resources. If too many watches trigger
concurrently and there isn't enough capacity to execute them all, some of the
watches are queued, waiting for the current executing watches to finish their
execution. The queued watches metric gives insight on these queued watches.

To include this metric, the `metric` option should include `queued_watches` or
`_all`.

The following example specifies the `queued_watches` metric option and includes
both the basic metrics and the queued watches:

[source,js]
--------------------------------------------------
GET _xpack/watcher/stats/queued_watches
--------------------------------------------------
// CONSOLE

An example of a successful JSON response that captures a watch in execution:

[source,js]
--------------------------------------------------
{
   "watcher_state": "started",
   "watch_count": 10,
   "execution_thread_pool": {
      "queue_size": 1000,
      "max_size": 20
   },
   "queued_watches": [ <1>
         {
            "watch_id": "slow_condition4", <2>
            "watch_record_id": "slow_condition4_223-2015-05-21T11:59:59.811Z", <3>
            "triggered_time": "2015-05-21T11:59:59.811Z", <4>
            "execution_time": "2015-05-21T11:59:59.811Z" <5>
         },
      ...
   ]
}
--------------------------------------------------
<1> A list of all watches that are currently queued for execution. When no
    watches are queued, an empty array is returned.
<2> The id of the watch queued for execution.
<3> The id of the watch record.
<4> The time the watch was triggered by the trigger engine.
<5> The time the watch was went into a queued state.