-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Forward Protocol Specification v0
This is a protocol specification for Fluentd forward input/output plugins. This protocol is also used by fluent-logger software, and many other software in ecosystem (e.g., Docker logging driver for Fluentd).
This protocol version is v0. This spec is supported by Fluentd v0.10 and v0.12, and will be changed at v0.14 (it will be versioned as protocol version v1).
- March 16, 2016: initial release of this specification
- August 30, 2016: add an optional field: size
This specification describes the fluentd forward protocol, which is used to transport events from hosts to hosts over network.
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119. The following terms are also used:
- event: a virtual set of tag, time and record. tag MAY be shared by 2 or more events in actual representation if these events have same tag.
- client: an endpoint that sends events.
out_forwardplugin is the reference client implementation shipped with the fluentd distribution. - server: an endpoint that receives events.
in_forwardplugin is the reference server implementation shipped with the fluentd distribution. - connection: a TCP connection between two endpoints.
- msgpack: a light weight binary representation of serialized objects.
- Client MAY send UDP packets to the same port of connection, to check existence of Servers.
- Server SHOULD listen the same port of connection, and SHOULD respond to source address when heartbeat message arrived.
UDP heartbeat message SHOULD be a byte of 0x00 in both of Client and Server.
- Client sends a msgpack
arraywhich contains one or more events to the server through TCP connection. - Client MUST choose a carrier mode from three:
Message,ForwardandPackedForwarddescribed below. - Client MAY send a msgpack
nilvalue for heartbeat health check usage without any event record payload. - Client MAY send multiple msgpack
arrays on a single connection, continuously.
- Server MUST receive one or more msgpack
arrays from the client through TCP connection. - Server MUST detect the carrier mode by inspecting the second element of the array.
- Server SHOULD ignore any request value other than
arrayformat. - Note: In addition to the three carrier modes,
in_forwardplugin also accepts JSON representation of a single event for convenience. It detect it by the first byte of the request.
It carries just a event.
-
tagis a string separated with '.' (e.g. myapp.access) to categorize events. -
timeis a number of seconds since Unix epoch. -
recordis key-value pairs of the event record. -
optionis optional key-value pairs, to bring data to control servers' behavior.
| name | Ruby type | msgpack fromat | content |
|---|---|---|---|
| tag | String | str | tag name |
| time | Integer | EventTime | int | ext | Unix time (second) |
| record | Hash | map | pairs of keys(String) and values(Object) |
| option | Hash | map | option (optional) |
[
"tag.name",
1441588984,
{"message": "bar"},
{"option": "optional"}
]NOTE for v1 protocol: time MAY be a representation of EventTime, which has nanosecond precision of time with msgpack ext format of type 0 is used when time_as_integer is false. Server SHOULD accept both formats.
It carries a series of events as a msgpack array on a single request.
| name | Ruby type | msgpack format | content |
|---|---|---|---|
| tag | String | str | tag name |
| entries | MultiEventStream | array | list of Entry |
| option | Object | map | option (optional) |
[
"tag.name",
[
[1441588984, {"message": "foo"}],
[1441588985, {"message": "bar"}],
[1441588986, {"message": "baz"}]
],
{"option": "optional"}
]It carries a series of events as a msgpack binary on a single request.
-
entriesis a binary chunk ofMessagePackEventStreamwhich contains multiple raw msgpack representations ofEntry. - Client SHOULD send a
MessagePackEventStreamas msgpackbinformat as it's a binary representation. - Client MAY send a
MessagePackEventStreamas msgpackstrformat for compatibility reasons. - Server MUST accept both formats of
binandstr. - Server MAY decode individual events on demand but MAY NOT do right after request arrival. It means it MAY costs less, compared to
Forwardmode, when decoding is not needed by any plugins. - Note:
out_forwardplugin sends events by thePackedForwardmode. It encloses event records with msgpackstrformat instead ofbinformat for a backward compatibility reason.
| name | Ruby type | msgpack format | content |
|---|---|---|---|
| tag | String | str | tag name |
| entries | MessagePackEventStream | str | bin | msgpack stream of Entry |
| option | Object | map | option (optional) |
[
"tag.name",
"<<MessagePackEventStream>>",
{"option": "optional"}
]Entry is an array representation of pairs of time and record, used in Forward and PackedForward mode.
| name | Ruby type | msgpack fromat | content |
|---|---|---|---|
| time | Integer | EventTime | int | ext | Unix time (second) |
| record | Hash | map | pairs of keys(String) and values(Object) |
It carries an optional meta data for the request.
- Client MAY send key-value pairs of options.
- Server MAY just ignore any options given.
-
size: Clients MAY send thesizeoption to show the number of event records in an entries by an integer as a value. Server can know the number of events without unpacking entries (especially for PackedForward mode). -
chunk: Clients MAY send thechunkoption to confirm the server receives event records. The value is a string of Base64 representation of 128 bitsunique_idwhich is an ID of a set of events.
{"chunk": "p8n9gmxTQVC8/nh2wlKKeQ==", "size": 1023}- Server SHOULD close the connection silently with no response when the
chunkoption is not sent. -
ack: Server MUST respondackwhen thechunkoption is sent by client. Theackresponse value MUST be the same value given bychunkoption from client. Client SHOULD retry to send events later when the request has achunkbut the response has noack.
{"ack": "p8n9gmxTQVC8/nh2wlKKeQ=="}EventTime uses msgpack extension format of type 0 to carry nanosecond precision of time.
- Client MAY send
EventTimeinstead of plain integer representation of second since unix epoch. - Server SHOULD accept both formats of integer and EventTime.
+----+----+----+----+----+----+----+----+----+----+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
+----+----+----+----+----+----+----+----+----+----+
| C7 | 00 | second from epoch | nanosecond |
+----+----+----+----+----+----+----+----+----+----+
|ext |type| 32bits integer BE | 32bits integer BE |
+----+----+----+----+----+----+----+----+----+----+-
Name?means thatNameis optional. -
Name*means thatNamecan occur zero or more times. -
<<Name>>means binary msgpack representation ofName. -
[ A, B, C ]means an array. -
nil,string,integerandobjectmeans as it is.
Connection ::= <<Request>>*
Request ::= Message | Forward | PackedForward | nil
Message ::= [ Tag, Time, Record, Option? ]
Forward ::= [ Tag, MultiEventStream, Option? ]
MultiEventStream ::= [ Event* ]
PackedForward ::= [ Tag, MessagePackEventStream, Option? ]
MessagePackEventStream ::= <<Event>>*
Event ::= [ Time, Record ]
Tag ::= string
Time ::= integer | EventTime
Record ::= object
Option ::= object