Renders information about clients registered to Finagle's ClientRegistry in an html fragment.
Dumps a simple string representation of the current Dtab.
Dumps a simple string representation of the current Dtab.
From the Dtab docs: A Dtab--short for delegation table--comprises a sequence of delegation rules. Together, these describe how to bind a path to an Addr.
Renders failed lint rule alert in an html fragment onto /admin/failedlint.
A handler which outputs patterns
as html anchors.
A handler which outputs patterns
as html anchors. By default,
it outputs the patterns from the globals com.twitter.finagle.http.HttpMuxer
and com.twitter.finagle.http.HttpMuxer.
UI for running the globally registered lint Rules.
A handler which accepts metrics queries via http query strings and returns json encoded metrics.
A com.twitter.finagle.Service for displaying the current state of the registry.
A com.twitter.finagle.Service for displaying the current state of the registry.
It's intended to be used as a handler for TwitterServer.
As an admin endpoint, it displays the GlobalRegistry
in JSON format.
It takes an optional HTTP request parameter, "filter", which allows for simple filtering of the returned data.
See the user guide for additional details.
A handler designed to serve static resources.
A simple http service for serving up information pulled from a build.properties file.
A simple http service for serving up information pulled from a build.properties file. The ClassLoader for the given object is used to load the build.properties file, which is first searched for relative to the given object's class's package (class-package-name/build.properties), and if not found there, then it is searched for with an absolute path ("/build.properties").
Renders information about servers registered to Finagle's ServerRegistry in an html fragment.
Renders information about servers registered to Finagle's ServerRegistry in an html fragment. Servers can be queried by passing in the server name as part of the uri (ex. "/admin/servers/myserver").
"Controller" for displaying the current state of threads.
"Controller" for displaying the current state of threads.
Possibilities for future endeavors in the web ui: - group threads by "similarity" - provide a mechanism for exp/imp - javascript control for searching within stacktraces
ThreadsView
Admin UI for seeing and modifying the server's com.twitter.finagle.toggle.Toggles
.
Admin UI for seeing and modifying the server's com.twitter.finagle.toggle.Toggles
.
This handler should be available at "/admin/toggles".
GET requests shows the current state of all StandardToggleMaps. Requests should be of the form "/admin/toggles{/$libraryName}{/$id}". Note that the library name and toggle id components are optional but do allow for filtering the output on those constraints. The output is JSON and it looks roughly like:
{ "libraries": [ { "libraryName" : "$libraryName", "toggles" : [ { "current" : { "id" : "$id", "fraction" : $fraction, "description" : "$description" }, "components" : [ { "source" : "$ToggleMapSource", "fraction" : $fraction }, { <other sources here> } ] }, { <other toggles here> } ] }, { <other libraries here> } ] }
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 update/create of the mutable Toggles while DELETE requests allow for removal. These apply only to the ToggleMap.Mutable 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.
In-memory Tunables can be manipulated using the endpoint /admin/tunables/
.
In-memory Tunables can be manipulated using the endpoint /admin/tunables/
. PUT and DELETE
requests to update the Tunables for a given id should be made to /admin/tunables/$id
and have a JSON body in the same format as a Tunable configuration file:
{ "tunables": [ { "id" : "$id1", "value" : $value, "type" : "$class" }, { "id" : "$id2", "value" : $value, "type" : "$class" } ] }
In the case of a PUT, these Tunables will be updated or added for the TunableMap corresponding
to id
. Note that this PUT request will *not* cause any existing Tunables to be removed.
In the case of a DELETE, these Tunables will cleared from the TunableMap corresponding
to id
. 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.
Renders information about clients registered to Finagle's ClientRegistry in an html fragment. Clients can be queried by passing in the client name as part of the uri (ex. "/admin/clients/myclient").