github.com/outbrain/consul@v1.4.5/website/source/docs/agent/rpc.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "RPC" 4 sidebar_current: "docs-agent-rpc" 5 description: |- 6 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. 7 --- 8 9 # RPC Protocol 10 11 ~> The RPC Protocol is deprecated and support was removed in Consul 12 0.8. Please use the [HTTP API](/api/index.html), which has 13 support for all features of the RPC Protocol. 14 15 The Consul agent provides a complete RPC mechanism that can 16 be used to control the agent programmatically. This RPC 17 mechanism is the same one used by the CLI but can be 18 used by other applications to easily leverage the power 19 of Consul without directly embedding. 20 21 It is important to note that the RPC protocol does not support 22 all the same operations as the [HTTP API](/api/index.html). 23 24 ## Implementation Details 25 26 The RPC protocol is implemented using [MsgPack](http://msgpack.org/) 27 over TCP. This choice was driven by the fact that all operating 28 systems support TCP, and MsgPack provides a fast serialization format 29 that is broadly available across languages. 30 31 All RPC requests have a request header, and some requests have 32 a request body. The request header looks like: 33 34 ```javascript 35 { 36 "Command": "Handshake", 37 "Seq": 0 38 } 39 ``` 40 41 All responses have a response header, and some may contain 42 a response body. The response header looks like: 43 44 ```javascript 45 { 46 "Seq": 0, 47 "Error": "" 48 } 49 ``` 50 51 The `Command` in the request is used to specify what command the server should 52 run, and the `Seq` is used to track the request. Responses are 53 tagged with the same `Seq` as the request. This allows for some 54 concurrency on the server side as requests are not purely FIFO. 55 Thus, the `Seq` value should not be re-used between commands. 56 All responses may be accompanied by an error. 57 58 Possible commands include: 59 60 * handshake - Initializes the connection and sets the version 61 * force-leave - Removes a failed node from the cluster 62 * join - Requests Consul join another node 63 * members-lan - Returns the list of LAN members 64 * members-wan - Returns the list of WAN members 65 * monitor - Starts streaming logs over the connection 66 * stop - Stops streaming logs 67 * leave - Instructs the Consul agent to perform a graceful leave and shutdown 68 * stats - Provides various debugging statistics 69 * reload - Triggers a configuration reload 70 71 Each command is documented below along with any request or 72 response body that is applicable. 73 74 ### handshake 75 76 This command is used to initialize an RPC connection. As it informs 77 the server which version the client is using, handshake MUST be the 78 first command sent. 79 80 The request header must be followed by a handshake body, like: 81 82 ```javascript 83 { 84 "Version": 1 85 } 86 ``` 87 88 The body specifies the IPC version being used; however, only version 89 1 is currently supported. This is to ensure backwards compatibility 90 in the future. 91 92 There is no special response body, but the client should wait for the 93 response and check for an error. 94 95 ### force-leave 96 97 This command is used to remove failed nodes from a cluster. It takes 98 the following body: 99 100 ```javascript 101 { 102 "Node": "failed-node-name" 103 } 104 ``` 105 106 There is no special response body. 107 108 ### join 109 110 This command is used to join an existing cluster using one or more known nodes. 111 It takes the following body: 112 113 ```javascript 114 { 115 "Existing": [ 116 "192.168.0.1:6000", 117 "192.168.0.2:6000" 118 ], 119 "WAN": false 120 } 121 ``` 122 123 The `Existing` nodes are each contacted, and `WAN` controls if we are adding a 124 WAN member or LAN member. LAN members are expected to be in the same datacenter 125 and should be accessible at relatively low latencies. WAN members are expected to 126 be operating in different datacenters with relatively high access latencies. It is 127 important that only agents running in "server" mode are able to join nodes over the 128 WAN. 129 130 The response contains both a header and body. The body looks like: 131 132 ```javascript 133 { 134 "Num": 2 135 } 136 ``` 137 138 'Num' indicates the number of nodes successfully joined. 139 140 ### members-lan 141 142 This command is used to return all the known LAN members and associated 143 information. All agents will respond to this command. 144 145 There is no request body, but the response looks like: 146 147 ```javascript 148 { 149 "Members": [ 150 { 151 "Name": "TestNode" 152 "Addr": [127, 0, 0, 1], 153 "Port": 5000, 154 "Tags": { 155 "role": "test" 156 }, 157 "Status": "alive", 158 "ProtocolMin": 0, 159 "ProtocolMax": 3, 160 "ProtocolCur": 2, 161 "DelegateMin": 0, 162 "DelegateMax": 1, 163 "DelegateCur": 1, 164 }, 165 ... 166 ] 167 } 168 ``` 169 170 ### members-wan 171 172 This command is used to return all the known WAN members and associated 173 information. Only agents in server mode will respond to this command. 174 175 There is no request body, and the response is the same as `members-lan` 176 177 ### monitor 178 179 The monitor command subscribes the channel to log messages from the Agent. 180 181 The request looks like: 182 183 ```javascript 184 { 185 "LogLevel": "DEBUG" 186 } 187 ``` 188 189 This subscribes the client to all messages of at least DEBUG level. 190 191 The server will respond with a standard response header indicating if the monitor 192 was successful. If so, any future logs will be sent and tagged with 193 the same `Seq` as in the `monitor` request. 194 195 Assume we issued the previous monitor command with `"Seq": 50`. We may start 196 getting messages like: 197 198 ```javascript 199 { 200 "Seq": 50, 201 "Error": "" 202 } 203 204 { 205 "Log": "2013/12/03 13:06:53 [INFO] agent: Received event: member-join" 206 } 207 ``` 208 209 It is important to realize that these messages are sent asynchronously 210 and not in response to any command. If a client is streaming 211 commands, there may be logs streamed while a client is waiting for a 212 response to a command. This is why the `Seq` must be used to pair requests 213 with their corresponding responses. 214 215 The client can only be subscribed to at most a single monitor instance. 216 To stop streaming, the `stop` command is used. 217 218 ### stop 219 220 This command stops a monitor. 221 222 The request looks like: 223 224 ```javascript 225 { 226 "Stop": 50 227 } 228 ``` 229 230 This unsubscribes the client from the monitor with `Seq` value of 50. 231 232 There is no response body. 233 234 ### leave 235 236 This command is used to trigger a graceful leave and shutdown. 237 There is no request body or response body. 238 239 ### stats 240 241 This command provides debug information. There is no request body, and the 242 response body looks like: 243 244 ```javascript 245 { 246 "agent": { 247 "check_monitors": 0, 248 ... 249 }, 250 "consul: { 251 "server": "true", 252 ... 253 }, 254 ... 255 } 256 ``` 257 258 ### reload 259 260 This command is used to trigger a reload of configurations. 261 There is no request body or response body.