MongoDB Output Plugin
out_mongo Buffered Output plugin writes records into MongoDB, the emerging document-oriented database system.
|If you're using ReplicaSet, please see the out_mongo_replset article instead.|
|This document doesn't describe all parameters. If you want to know full features, check the Further Reading section.|
Table of Contents
- Why Fluentd with MongoDB?
- Example Configuration
- type (required)
- host (required)
- port (required)
- database (required)
- collection (required, if not tag_mapped)
- Buffered Output Parameters
- buffer_queue_limit, buffer_chunk_limit
- retry_wait, max_retry_wait
- retry_limit, disable_retry_limit
- Further Reading
Why Fluentd with MongoDB?
Fluentd enables your apps to insert records to MongoDB asynchronously with batch-insertion, unlike direct insertion of records from your apps. This has the following advantages:
- less impact on application performance
- higher MongoDB insertion throughput while maintaining JSON record structure
out_mongo is included in td-agent by default. Fluentd gem users will need to install the fluent-plugin-mongo gem using the following command.
$ fluent-gem install fluent-plugin-mongo
# Single MongoDB <match mongo.**> @type mongo host fluentd port 27017 database fluentd collection test # for capped collection capped capped_size 1024m # authentication user michael password jordan # key name of timestamp time_key time # flush flush_interval 10s </match>
Please see the Store Apache Logs into MongoDB article for real-world use cases.
|Please see the Config File article for the basic structure and syntax of the configuration file.|
The value must be
The MongoDB hostname.
The MongoDB port.
The database name.
collection (required, if not tag_mapped)
The collection name.
This option enables capped collection. This is always recommended because MongoDB is not suited to storing large amounts of historical data.
Sets the capped collection size.
The username to use for authentication.
The password to use for authentication.
The key name of timestamp. (default is “time”)
This option will allow out_mongo to use Fluentd’s tag to determine the destination collection. For example, if you generate records with tags ‘mongo.foo’, the records will be inserted into the
foo collection within the
<match mongo.*> @type mongo host fluentd port 27017 database fluentd # Set 'tag_mapped' if you want to use tag mapped mode. tag_mapped # If the tag is "mongo.foo", then the prefix "mongo." is removed. # The inserted collection name is "foo". remove_tag_prefix mongo. # This configuration is used if the tag is not found. The default is 'untagged'. collection misc </match>
This option is useful for flexible log collection.
Buffered Output Parameters
For advanced usage, you can tune Fluentd’s internal buffering mechanism with these parameters.
The length of the chunk queue and the size of each chunk, respectively. Please see the Buffer Plugin Overview article for the basic buffer structure. The default values are 64 and 8m, respectively. The suffixes “k” (KB), “m” (MB), and “g” (GB) can be used for buffer_chunk_limit.
The interval between data flushes. The default is 60s. The suffixes “s” (seconds), “m” (minutes), and “h” (hours) can be used.
If set to true, Fluentd waits for the buffer to flush at shutdown. By default, it is set to true for Memory Buffer and false for File Buffer.
The initial and maximum intervals between write retries. The default values are 1.0 seconds and unset (no limit). The interval doubles (with +/-12.5% randomness) every retry until
max_retry_wait is reached. In the default configuration the last retry waits for approximately 131072 sec, roughly 36 hours.
The limit on the number of retries before buffered data is discarded, and an
option to disable that limit (if true, the value of
retry_limit is ignored and
there is no limit). The default values are 17 and false (not disabled). If the limit is reached, buffered data is discarded and the retry interval is reset to its initial value (
The number of threads to flush the buffer. This option can be used to parallelize writes into the output(s) designated by the output plugin. Increasing the number of threads improves the flush throughput to hide write / network latency. The default is 1.
log_level option allows the user to set different levels of logging for each plugin. The supported log levels are:
Please see the logging article for further details.
If this article is incorrect or outdated, or omits critical information, please let us know.