Support Center Home

Setting up Fluentd Logs Ingestion

Fluentd is an open-source data collector which provides a unifying layer between different types of log inputs and outputs. If you already use Fluentd to collect application and system logs, you can forward the logs to LogicMonitor using the LM Logs Fluentd plugin.

The Fluentd plugin for LM Logs can be found at the following link:


  • LogicMonitor API tokens to authenticate all requests to the log ingestion API.
  • Logs sent to the log ingestion API must include a “message” field. Requests sent without a “message” will not be accepted.

Install the plugin

You have a few options for installing the plugin:

  • With gem: gem install lm-logs-fluentd
  • For Debian packages: td-agent-gem install fluent-plugin-lm-logs

Alternatively, you can add out_lm.rb to your Fluentd plugins directory.

Configure the plugin

Create a custom fluent.conf file or edit the existing one to specify which logs should forward to LogicMonitor. See Configuration properties for more details.

# Match events tagged with "lm.**" and
# send them to LogicMonitor
<match lm.**>
    @type lm
    resource_mapping {"<event_key>": "<lm_property>"}
    company_name <lm_company_name>
    access_id <lm_access_id>
    access_key <lm_access_key>
        @type memory
        flush_interval 1s
        chunk_limit_size 5m
    debug false
    compression gzip

Request example

Sending the following request:

curl -X POST -d 'json={"message":"hello LogicMonitor from fluentd", "event_key":"lm_property_value"}' http://localhost:8888/lm.test

Returns the event:

    "message": "hello LogicMonitor from fluentd"

Configuration properties

Property Description
company_name Your LogicMonitor company or account name in the target URL: https://<account>
resource_mapping The mapping that defines the source of the log event to the LogicMonitor resource. In this case, the <event_key> in the incoming event is mapped to the value of <lm_property>.
For more details and examples, see Resource mapping.
access_id The LogicMonitor API tokens access ID. We recommend creating an API-only user.
access_key The LogicMonitor API tokens access key.
flush_interval Defines the time in seconds to wait before sending batches of logs to LogicMonitor. Default is 60s.
debug When true, logs more information to the Fluentd console.
force_encoding Specify charset when logs contains invalid utf-8 characters.
compression Enable compression for incoming events. Currently supports gzip encoding.

Resource Mapping

When defining the resource mapping for the fluent event, the <event_key> in the incoming event is mapped to the LogicMonitor resource, which is the value of <lm_property>.

For example, you may map a hostname field in the log event to the LogicMonitor property system.hostname using:

resource_mapping {"hostname": 'system.hostname"}

If the LogicMonitor resource mapping is known, the event_key property can be overridden by specifying _lm.resourceId in each record. See Resource mapping examples below.

Example 1

In this example, all incoming records that match lm.** will go through the filter and the specified _lm.resourceId mapping is added before it is sent to LogicMonitor.

<filter lm.**>
    @type record_transformer
_lm.resourceId { "": "arn:aws:ec2:us-west-1:xxx:instance/i-xxx"}
   	tag ${tag}

Example 2

For Kubernetes logs in Fluentd, the resource mapping can always be defined with the statement:

 resource_mapping {"kubernetes.pod_name": ""}

Fluentd Examples

Because Fluentd provides a unified logging layer, you’re able to use it collect many types of logs which you can then forward to LogicMonitor for analysis.

We provide configuration examples for using the Fluentd plugin to send Windows Event Logs, Apache access logs, and more at:


Enable debug logging by setting the debug property to “true” in fluent.conf to see additional information in the Fluentd console.

See the Troubleshooting guide for more information.

In This Article