2014-02-08 00:41:03 +00:00
---
layout: "docs"
page_title: "RPC"
sidebar_current: "docs-agent-rpc"
2014-10-19 23:40:10 +00:00
description: |-
2015-02-03 22:07:03 +00:00
The Consul agent provides a complete RPC mechanism that can be used to control the agent programmatically. This RPC mechanism is the same one used by the CLI but can be used by other applications to easily leverage the power of Consul without directly embedding.
2014-02-08 00:41:03 +00:00
---
# RPC Protocol
2014-02-18 23:30:07 +00:00
The Consul agent provides a complete RPC mechanism that can
2014-02-08 00:41:03 +00:00
be used to control the agent programmatically. This RPC
2015-02-03 22:07:03 +00:00
mechanism is the same one used by the CLI but can be
2014-02-08 00:41:03 +00:00
used by other applications to easily leverage the power
2015-02-03 22:07:03 +00:00
of Consul without directly embedding.
It is important to note that the RPC protocol does not support
all the same operations as the [HTTP API ](/docs/agent/http.html ).
2014-02-08 00:41:03 +00:00
## Implementation Details
The RPC protocol is implemented using [MsgPack ](http://msgpack.org/ )
2015-02-03 22:07:03 +00:00
over TCP. This choice was driven by the fact that all operating
2014-02-08 00:41:03 +00:00
systems support TCP, and MsgPack provides a fast serialization format
that is broadly available across languages.
All RPC requests have a request header, and some requests have
a request body. The request header looks like:
2014-10-19 23:40:10 +00:00
```javascript
{
"Command": "Handshake",
"Seq": 0
}
2014-02-08 00:41:03 +00:00
```
All responses have a response header, and some may contain
a response body. The response header looks like:
2014-10-19 23:40:10 +00:00
```javascript
{
"Seq": 0,
"Error": ""
}
2014-02-08 00:41:03 +00:00
```
2015-02-03 22:20:50 +00:00
The `Command` in the request is used to specify what command the server should
2014-02-08 00:41:03 +00:00
run, and the `Seq` is used to track the request. Responses are
tagged with the same `Seq` as the request. This allows for some
2015-02-03 22:07:03 +00:00
concurrency on the server side as requests are not purely FIFO.
2014-02-08 00:41:03 +00:00
Thus, the `Seq` value should not be re-used between commands.
All responses may be accompanied by an error.
Possible commands include:
2015-02-03 22:20:50 +00:00
* handshake - Initializes the connection and sets the version
2014-02-08 00:41:03 +00:00
* force-leave - Removes a failed node from the cluster
2014-02-18 23:30:07 +00:00
* join - Requests Consul join another node
2015-01-04 11:57:48 +00:00
* members-lan - Returns the list of LAN members
* members-wan - Returns the list of WAN members
2014-02-08 00:41:03 +00:00
* monitor - Starts streaming logs over the connection
2014-02-18 23:30:07 +00:00
* stop - Stops streaming logs
2015-02-03 22:20:50 +00:00
* leave - Instructs the Consul agent to perform a graceful leave and shutdown
2014-02-24 01:09:59 +00:00
* stats - Provides various debugging statistics
2014-06-11 17:54:36 +00:00
* reload - Triggers a configuration reload
2014-02-08 00:41:03 +00:00
2015-02-03 22:07:03 +00:00
Each command is documented below along with any request or
2014-02-08 00:41:03 +00:00
response body that is applicable.
### handshake
2015-02-03 22:20:50 +00:00
This command is used to initialize an RPC connection. As it informs
the server which version the client is using, handshake MUST be the
first command sent.
2014-02-08 00:41:03 +00:00
2015-02-03 22:07:03 +00:00
The request header must be followed by a handshake body, like:
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"Version": 1
}
2014-02-08 00:41:03 +00:00
```
2015-02-03 22:07:03 +00:00
The body specifies the IPC version being used; however, only version
2014-02-08 00:41:03 +00:00
1 is currently supported. This is to ensure backwards compatibility
in the future.
There is no special response body, but the client should wait for the
response and check for an error.
### force-leave
This command is used to remove failed nodes from a cluster. It takes
the following body:
2014-10-19 23:40:10 +00:00
```javascript
{
"Node": "failed-node-name"
}
2014-02-08 00:41:03 +00:00
```
There is no special response body.
### join
2015-02-03 22:07:03 +00:00
This command is used to join an existing cluster using one or more known nodes.
2014-02-08 00:41:03 +00:00
It takes the following body:
2014-10-19 23:40:10 +00:00
```javascript
{
"Existing": [
"192.168.0.1:6000",
"192.168.0.2:6000"
],
"WAN": false
}
2014-02-08 00:41:03 +00:00
```
2014-02-18 23:30:07 +00:00
The `Existing` nodes are each contacted, and `WAN` controls if we are adding a
2015-02-03 22:07:03 +00:00
WAN member or LAN member. LAN members are expected to be in the same datacenter
2014-02-18 23:30:07 +00:00
and should be accessible at relatively low latencies. WAN members are expected to
2015-02-03 22:07:03 +00:00
be operating in different datacenters with relatively high access latencies. It is
2014-02-18 23:30:07 +00:00
important that only agents running in "server" mode are able to join nodes over the
WAN.
2015-02-03 22:07:03 +00:00
The response contains both a header and body. The body looks like:
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"Num": 2
}
2014-02-08 00:41:03 +00:00
```
2015-02-03 22:07:03 +00:00
'Num' indicates the number of nodes successfully joined.
2014-02-08 00:41:03 +00:00
2014-02-18 23:30:07 +00:00
### members-lan
2015-02-03 22:07:03 +00:00
This command is used to return all the known LAN members and associated
2014-02-18 23:30:07 +00:00
information. All agents will respond to this command.
2014-02-08 00:41:03 +00:00
2014-02-18 23:30:07 +00:00
There is no request body, but the response looks like:
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"Members": [
{
"Name": "TestNode"
"Addr": [127, 0, 0, 1],
"Port": 5000,
"Tags": {
"role": "test"
},
"Status": "alive",
"ProtocolMin": 0,
"ProtocolMax": 3,
"ProtocolCur": 2,
"DelegateMin": 0,
"DelegateMax": 1,
"DelegateCur": 1,
},
...
]
}
2014-02-08 00:41:03 +00:00
```
2014-02-18 23:30:07 +00:00
### members-wan
2014-02-08 00:41:03 +00:00
2015-02-03 22:07:03 +00:00
This command is used to return all the known WAN members and associated
2014-02-18 23:30:07 +00:00
information. Only agents in server mode will respond to this command.
2014-02-08 00:41:03 +00:00
2014-02-18 23:30:07 +00:00
There is no request body, and the response is the same as `members-lan`
2014-02-08 00:41:03 +00:00
### monitor
2014-02-18 23:30:07 +00:00
The monitor command subscribes the channel to log messages from the Agent.
2014-02-08 00:41:03 +00:00
2015-02-03 22:07:03 +00:00
The request looks like:
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"LogLevel": "DEBUG"
}
2014-02-08 00:41:03 +00:00
```
This subscribes the client to all messages of at least DEBUG level.
The server will respond with a standard response header indicating if the monitor
2015-02-03 22:07:03 +00:00
was successful. If so, any future logs will be sent and tagged with
the same `Seq` as in the `monitor` request.
2014-02-08 00:41:03 +00:00
2015-02-03 22:20:50 +00:00
Assume we issued the previous monitor command with `"Seq": 50` . We may start
getting messages like:
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"Seq": 50,
"Error": ""
}
{
"Log": "2013/12/03 13:06:53 [INFO] agent: Received event: member-join"
}
2014-02-08 00:41:03 +00:00
```
2015-02-03 22:07:03 +00:00
It is important to realize that these messages are sent asynchronously
and not in response to any command. If a client is streaming
2014-02-08 00:41:03 +00:00
commands, there may be logs streamed while a client is waiting for a
response to a command. This is why the `Seq` must be used to pair requests
with their corresponding responses.
The client can only be subscribed to at most a single monitor instance.
To stop streaming, the `stop` command is used.
### stop
2015-02-03 22:07:03 +00:00
This command stops a monitor.
2014-02-08 00:41:03 +00:00
The request looks like:
2014-10-19 23:40:10 +00:00
```javascript
{
"Stop": 50
}
2014-02-08 00:41:03 +00:00
```
2014-02-18 23:30:07 +00:00
This unsubscribes the client from the monitor with `Seq` value of 50.
2014-02-08 00:41:03 +00:00
2015-02-03 22:07:03 +00:00
There is no response body.
2014-02-08 00:41:03 +00:00
### leave
2015-02-03 22:20:50 +00:00
This command is used to trigger a graceful leave and shutdown.
There is no request body or response body.
2014-02-08 00:41:03 +00:00
2014-02-24 01:09:59 +00:00
### stats
2015-02-03 22:07:03 +00:00
This command provides debug information. There is no request body, and the
response body looks like:
2014-02-24 01:09:59 +00:00
2014-10-19 23:40:10 +00:00
```javascript
{
"agent": {
"check_monitors": 0,
...
},
"consul: {
"server": "true",
...
},
...
}
2014-02-24 01:09:59 +00:00
```
2014-06-11 17:54:36 +00:00
### reload
2015-02-03 22:20:50 +00:00
This command is used to trigger a reload of configurations.
There is no request body or response body.