|
| 1 | +UDP (input plugin) |
| 2 | +================== |
| 3 | + |
| 4 | +The plugin receives IPFIX messages over UDP transport protocol from one or more exporters |
| 5 | +and pass them into the collector. Multiple instances of the plugin can run concurrently. |
| 6 | +However, they must listen on different ports or local IP addresses. |
| 7 | + |
| 8 | +Keep in mind that connection between the exporter and the collector is unreliable because of UDP and |
| 9 | +IPFIX protocol is unidirectional (the collector can only receive). Because various exporters |
| 10 | +can measure different features of flows, IPFIX specifies templates that describe structure |
| 11 | +of transmitted flow records and the collector uses these templates to interpret them. In case of |
| 12 | +connection over UDP, templates are regularly retransmitted by exporters. However, if the collector |
| 13 | +starts after an exporter, it could miss all templates and it is unable to interpret |
| 14 | +records until next retransmission. *In other words, it may take up to a few minutes for the |
| 15 | +first record to be successfully interpret* (depends on template retransmission interval of the |
| 16 | +exporter). |
| 17 | + |
| 18 | +**Warning**: One of the most common causes of lost flow records transmitted over networks |
| 19 | +using UDP protocol is an undersized receive buffer of a system socket. The actual size of the buffer |
| 20 | +your operating system provides is limited by operating system-level maximums. The plugin |
| 21 | +automatically changes default size to the maximum size during startup. However, the size is usually |
| 22 | +not optimal for monitoring high-speed network or reception from multiple exporters. |
| 23 | +It is recommended to increase the limits before the start of the collector. For the most Linux |
| 24 | +distributions, you can use, for example, following command (value in bytes): |
| 25 | + |
| 26 | +.. code-block:: bash |
| 27 | +
|
| 28 | + sysctl -w net.core.rmem_max=16777216 |
| 29 | +
|
| 30 | +
|
| 31 | +Example configuration |
| 32 | +--------------------- |
| 33 | + |
| 34 | +.. code-block:: xml |
| 35 | +
|
| 36 | + <input> |
| 37 | + <name>UDP input</name> |
| 38 | + <plugin>udp</plugin> |
| 39 | + <params> |
| 40 | + <localPort>4739</localPort> |
| 41 | + <localIPAddress></localIPAddress> |
| 42 | + <!-- Optional parameters --> |
| 43 | + <connectionTimeout>600</connectionTimeout> |
| 44 | + <templateLifeTime>1800</templateLifeTime> |
| 45 | + <optionsTemplateLifeTime>1800</optionsTemplateLifeTime> |
| 46 | + </params> |
| 47 | + </input> |
| 48 | +
|
| 49 | +Parameters |
| 50 | +---------- |
| 51 | + |
| 52 | +Mandatory parameters: |
| 53 | + |
| 54 | +:``localPort``: |
| 55 | + Local port on which the plugin listens. [default: 4739] |
| 56 | +:``localIPAddress``: |
| 57 | + Local IPv4/IPv6 address an which the UDP input plugin listens. If the element |
| 58 | + is left empty, the plugin binds to all available network interfaces. The element can occur |
| 59 | + multiple times (one IP address per occurrence) to manually select multiple interfaces. |
| 60 | + [default: empty] |
| 61 | + |
| 62 | +Optional parameters: |
| 63 | + |
| 64 | +:``connectionTimeout``: |
| 65 | + Exporter connection timeout in seconds. If no message is received from an exporter |
| 66 | + for a specified time, the connection is considered closed and all resources (associated |
| 67 | + with the exporter) are removed, such as flow templates, etc. [default: 600] |
| 68 | +:``templateLifeTime``, ``optionsTemplateLifeTime``: |
| 69 | + (Options) Template lifetime in seconds for all UDP Transport Sessions terminating at |
| 70 | + this UDP socket. (Options) Templates that are not received again within the configured |
| 71 | + lifetime become invalid. The lifetime of Templates and Options Templates should be at |
| 72 | + least three times higher than the same values configured on the corresponding exporter. |
| 73 | + [default: 1800] |
0 commit comments