A user interface for capturing the current stacktraces. Includes filtering
of inactive threads as well as deadlock detection. JSON output is also available
through tools like curl via the inspection of the HTTP Accept header.

Displays how the service is currently configured across a variety of dimensions
including the client stack, server stack, flags, service loader values,
system properties, environment variables, build properties and more.

The HTTP request parameter filter allows for simple filtering of the returned data.
The value takes the form “path/to/data” and returns registry entries whose prefix
matches the parameter. A glob, *, can be used to match any component of the path.
For example, using “filter=registry/server/http” will output all Finagle Http servers.
Using “filter=registry/client/*/user_service” would output all Finagle clients with
a label of “user_service” regardless of protocol.

Due to the usage of / as a delimiter, it means you cannot match components
containing a /. The choice of * as a glob also means you cannot match registry
components with the exact value of *. For these use cases, there is the
more powerful jq command-line JSON processing
tool.

See and modify the server’s in-memory mutable com.twitter.finagle.toggle.Toggles.

GET requests show the current state of all StandardToggleMap StandardToggleMaps.
Requests should be of the form /admin/toggles{/$libraryName}{/$id}.
Note that the library name and toggle id components are optional and allow
for filtering the output on those constraints.
The output is JSON and it looks roughly like:

There will be a hash for each library registered with
com.twitter.finagle.toggle.StandardToggleMap. For each Toggle
the “current” hash shows the current configuration while the
“components” array has a hash per ToggleMap source. These
are ordered by evaluation order and as such, sources earlier in a
component array are used first.

PUT requests allow for updates/creation of the mutable Toggles
while DELETE requests allow for removal. These apply only to the
ToggleMap.MutableToggleMaps within a StandardToggleMap.
Requests must be of the form /admin/toggles/$libraryName/$id.
For create and update, and an additional fraction request parameter
must be set as well.

For a PUT request, these Tunables will be updated or added. Note that PUT requests
will not cause any existing Tunables to be removed.

For a DELETE request, these Tunables will cleared from the TunableMap. The Tunables are keyed
by “id” and “type”; the “value” for each of Tunables to delete can be any valid value for this
Tunable. Because the value of a Tunable is the result of a composition of TunableMaps
(see StandardTunableMap), deleting an in-memory Tunable will cause the value from the
composition of the other TunableMaps to be used.

This metrics endpoint provides the ability to both watch specific metrics in
real-time, as well as download data for a specific metric. It is available in
TwitterServer regardless of the particular stats library implementation you are
using.

Selecting the Watch menu item or navigating to the page directly in your web
browser displays all of the reported metrics for this TwitterServer instance.
Choosing an individual metric from the list will allow you to watch how its
value changes over time.

If you know the exact name of the metric that you would like to watch, you can
use a fragment (named anchor) within the url to navigate directly to viewing
that specific metric.

/admin/metrics#mediainfo/mux/failuredetector/ping

If you would like to download data for an individual metric instead, you may use
the m request parameter with the full metric name. The response returned will be
JSON and include the name, delta (change since the metric was last sampled), and
value (instantaneous value) for the specific metric.

Export a snapshot of the current statistics of the program. You can
use the StatsReceiver in your application for add new
counters/gauges/histograms, simply use the statsReceiver variable
provided by TwitterServer.

This endpoint is available when you are using the finagle-stats library.
See the metrics section for more information.

Visualize and download histogram-style metrics. The metrics endpoint exposes a
summary of the histogram, but it doesn’t expose the full histogram. The full
histogram can be useful for seeing the different modes of your metric, which often
represent different states of your program.

This endpoint is available when you are using the finagle-stats library.
See the metrics section for more information.

Export a snapshot of a histogram-style metric in json. This exports the entire
histogram, which can be used for correctly aggregating over a cluster, or to
efficiently record historic histogram data, or to compare modes in different
usages patterns, like times of day. You may add new histograms by adding new
stats to your statsReceiver variable.

This endpoint is available when you are using the finagle-stats library.
See the metrics section for more information.

Returns a CPU contention profile which identifies blocked threads
(Thread.State.BLOCKED).
The output is in pprof format.
The process will be profiled for 10 seconds at a frequency of 100 hz. These
values can be controlled via HTTP request parameters seconds and hz
respectively.

$ curl localhost:9990/admin/contention
Blocked:
"util-jvm-timer-1" Id=11 TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@33aac3c
at sun.misc.Unsafe.park(Native Method)
- waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@33aac3c
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
...

Returns a CPU usage profile. The output is in pprof format.
The process will be profiled for 10 seconds at a frequency of 100 hz. These
values can be controlled via HTTP request parameters seconds and hz
respectively.