== Management

=== CLI
You can use the +CLI+ to perform management operations on a standalone node or a domain controller.

[source,options=nowrap,subs=attributes+]
----
$ bin/{brandcli}.sh
[disconnected /] connect
[standalone@localhost:9990 /] cd subsystem=datagrid-infinispan
[standalone@localhost:9990 subsystem=datagrid-infinispan] cd cache-container=local
[standalone@localhost:9990 cache-container=local] cd local-cache=default
[standalone@localhost:9990 local-cache=default]
----

The +CLI+ is extremely powerful and supports a number of useful features to navigate the management resource tree
as well as inspecting single resources or entire subtrees. It is also possible to batch multiple commands together so that
they are applied as a single operation.

=== Console
You can use the web console to perform management operations on servers running in either standalone or domain mode.
The console only supports a subset of the operations provided by the CLI, however you can perform the following
actions:

* View/Edit Cache Container Configuration
* Execute Tasks across Containers
* View/Edit Cache Configurations
* Create/Destroy Cache Instances
* View Cluster/Server/Cache Statistics
* View event logs
* Start/Stop servers/clusters (domain mode only)

To access the console start your server(s) in the required mode, navigate to `http://localhost:9990` and enter your user credentials.
If you would like to contribute to the development of the console, the source code can be found
link:https://github.com/infinispan/infinispan-management-console[here].

NOTE: Before you can use the web console, you must first setup at least one user account via the `./bin/add-user.sh` script.
Detailed instructions of this process are presented in your browser if you attempt to access the console before creating any user accounts.

=== JMX

You can monitor an {brandname} Server over JMX in two ways:

* Use JConsole or VisualVM running locally as the same user. This will use a local link:http://www.oracle.com/technetwork/java/jvmstat-142257.html[jvmstat] connection and requires no additional setup
* Use JMX remoting (aka JSR-160) to connect from any host. This requires connecting through the management port (usually 9990) using a special protocol which respects the server security configuration

ifndef::productized[]
To setup a client for JMX remoting, add +$ISPN_HOME/bin/client/jboss-client.jar+ to your client's classpath and use one of the following service URLs:
endif::productized[]
ifdef::productized[]
To setup a client for JMX remoting, add `$RHDG_HOME/bin/client/jboss-cli-client.jar` to your client's classpath and use one of the following service URLs:
endif::productized[]

ifndef::productized[]
* `service:jmx:remote-http-jmx://host:port` for plain connections through the management interface
* `service:jmx:remote-https-jmx://host:port` for TLS connections through the management interface (although this requires having the appropriate keys available)
* `service:jmx:remoting-jmx://localhost:port` for connections through the remoting interface (necessary for connecting to individual servers in a domain)
endif::productized[]
ifdef::productized[]
* `service:jmx:remote+http://hostname:9990` for plain connections through the management interface
* `service:jmx:remote+https://hostname:9993` for TLS connections through the management interface (although this requires having the appropriate keys available)
endif::productized[]

The JMX subsystem registers a service with the Remoting endpoint so that remote access to JMX can be obtained over the exposed Remoting connector.
This is switched on by default in standalone mode and accessible over port 9990 but in domain mode it is switched off so it needs to be enabled.
In domain mode the port will be the port of the Remoting connector for the Server instance to be monitored.

[source,xml]
----

<subsystem xmlns="urn:jboss:domain:jmx:1.3">
    <expose-resolved-model/>
    <expose-expression-model/>
    <remoting-connector use-management-endpoint="false"/>
</subsystem>

----

=== Exposing JMX Beans to Prometheus

* Start {brandname} servers as follows:
+
----
$ ./standalone.sh -c cloud.xml --jmx 8180:my-config.yaml
----

[[server_access_logs]]
=== Access Logs
Hot Rod and REST endpoints can record all inbound client requests as log entries with the following categories:

* `org.infinispan.HOTROD_ACCESS_LOG` logging category for the Hot Rod endpoint.
* `org.infinispan.REST_ACCESS_LOG` logging category for the REST endpoint.

[[server_access_logs_enable]]
==== Enabling Access Logs
Access logs for Hot Rod and REST endpoints are disabled by default. To enable
either logging category, set the level to `TRACE` in the server configuration file, as in the following example:

[source,xml,options=nowrap]
----
<logger category="org.infinispan.HOTROD_ACCESS_LOG" use-parent-handlers="false">
    <level name="TRACE"/>
    <handlers>
       <handler name="HR-ACCESS-FILE"/>
    </handlers>
</logger>
----

[[server_access_logs_properties]]
==== Access Log Properties
The default format for access logs is as follows:

`%X{address} %X{user} [%d{dd/MMM/yyyy:HH:mm:ss z}] &quot;%X{method} %m %X{protocol}&quot; %X{status} %X{requestSize} %X{responseSize} %X{duration}%n`

The preceding format creates log entries such as the following:

`127.0.0.1 - [30/Oct/2018:12:41:50 CET] "PUT /rest/default/key HTTP/1.1" 404 5 77 10`

Logging properties use the `%X{name}` notation and let you modify the format of access logs. The following are the default logging properties:

[%header,cols=2*]
|===
| Property
| Description

| `address`
| Either the `X-Forwarded-For` header or the client IP address.

| `user`
| Principal name, if using authentication.

| `method`
| Method used. `PUT`, `GET`, and so on.

| `protocol`
| Protocol used. `HTTP/1.1`, `HTTP/2`, `HOTROD/2.9`, and so on.

| `status`
| An HTTP status code for the REST endpoint. `OK` or an exception for the Hot Rod endpoint.

| `requestSize`
| Size, in bytes, of the request.

| `responseSize`
| Size, in bytes, of the response.

| `duration`
| Number of milliseconds that the server took to handle the request.
|===

[TIP]
====
Use the header name prefixed with `h:` to log headers that were included in requests; for example, `%X{h:User-Agent}`.
====
