By default the [InfluxdbWriter](09-object-types.md#objecttype-influxdbwriter) feature
expects the InfluxDB daemon to listen at `127.0.0.1` on port `8086`.
+Measurement names and tags are fully configurable by the end user. The InfluxdbWriter
+object will automatically add a `metric` tag to each data point. This correlates to the
+perfdata label. Fields (value, warn, crit, min, max, unit) are created from data if available
+and the configuration allows it. If a value associated with a tag is not able to be
+resolved, it will be dropped and not sent to the target host.
+
+Backslashes are allowed in tag keys, tag values and field keys, however they are also
+escape characters when followed by a space or comma, but cannot be escaped themselves.
+As a result all trailling slashes in these fields are replaced with an underscore. This
+predominantly affects Windows paths e.g. `C:\` becomes `C:_`.
+
+The database is assumed to exist so this object will make no attempt to create it currently.
+
More configuration details can be found [here](09-object-types.md#objecttype-influxdbwriter).
+#### Instance Tagging <a id="influxdb-writer-instance-tags"></a>
+
+Consider the following service check:
+
+```
+apply Service "disk" for (disk => attributes in host.vars.disks) {
+ import "generic-service"
+ check_command = "disk"
+ display_name = "Disk " + disk
+ vars.disk_partitions = disk
+ assign where host.vars.disks
+}
+```
+
+This is a typical pattern for checking individual disks, NICs, SSL certificates etc associated
+with a host. What would be useful is to have the data points tagged with the specific instance
+for that check. This would allow you to query time series data for a check on a host and for a
+specific instance e.g. /dev/sda. To do this quite simply add the instance to the service variables:
+
+```
+apply Service "disk" for (disk => attributes in host.vars.disks) {
+ ...
+ vars.instance = disk
+ ...
+}
+```
+
+Then modify your writer configuration to add this tag to your data points if the instance variable
+is associated with the service:
+
+```
+object InfluxdbWriter "influxdb" {
+ ...
+ service_template = {
+ measurement = "$service.check_command$"
+ tags = {
+ hostname = "$host.name$"
+ service = "$service.name$"
+ instance = "$service.vars.instance$"
+ }
+ }
+ ...
+}
+```
+
### Elastic Stack Integration <a id="elastic-stack-integration"></a>
[Icingabeat](https://github.com/icinga/icingabeat) is an Elastic Beat that fetches data
* [Logstash output](https://github.com/Icinga/logstash-output-icinga) for the Icinga 2 API.
* [Logstash Grok Pattern](https://github.com/Icinga/logstash-grok-pattern) for Icinga 2 logs.
-#### Elastic Writer <a id="elastic-writer"></a>
+#### Elasticsearch Writer <a id="elasticsearch-writer"></a>
This feature forwards check results, state changes and notification events
to an [Elasticsearch](https://www.elastic.co/products/elasticsearch) installation over its HTTP API.
> **Note**
>
-> Elasticsearch 5.x+ is required.
+> Elasticsearch 5.x is required. This feature has been successfully tested with Elasticsearch 5.6.4.
Enable the feature and restart Icinga 2.
```
-# icinga2 feature enable elastic
+# icinga2 feature enable elasticsearch
```
The default configuration expects an Elasticsearch instance running on `localhost` on port `9200
and writes to an index called `icinga2`.
-More configuration details can be found [here](09-object-types.md#objecttype-elasticwriter).
+More configuration details can be found [here](09-object-types.md#objecttype-elasticsearchwriter).
#### Current Elasticsearch Schema <a id="elastic-writer-schema"></a>