|
|
|
|
@@ -155,11 +155,11 @@ vm_metric_exclude = [ "*" ]
|
|
|
|
|
## separator character to use for measurement and field names (default: "_")
|
|
|
|
|
# separator = "_"
|
|
|
|
|
|
|
|
|
|
## number of objects to retreive per query for realtime resources (vms and hosts)
|
|
|
|
|
## number of objects to retrieve per query for realtime resources (vms and hosts)
|
|
|
|
|
## set to 64 for vCenter 5.5 and 6.0 (default: 256)
|
|
|
|
|
# max_query_objects = 256
|
|
|
|
|
|
|
|
|
|
## number of metrics to retreive per query for non-realtime resources (clusters and datastores)
|
|
|
|
|
## number of metrics to retrieve per query for non-realtime resources (clusters and datastores)
|
|
|
|
|
## set to 64 for vCenter 5.5 and 6.0 (default: 256)
|
|
|
|
|
# max_query_metrics = 256
|
|
|
|
|
|
|
|
|
|
@@ -184,10 +184,10 @@ vm_metric_exclude = [ "*" ]
|
|
|
|
|
## Custom attributes from vCenter can be very useful for queries in order to slice the
|
|
|
|
|
## metrics along different dimension and for forming ad-hoc relationships. They are disabled
|
|
|
|
|
## by default, since they can add a considerable amount of tags to the resulting metrics. To
|
|
|
|
|
## enable, simply set custom_attribute_exlude to [] (empty set) and use custom_attribute_include
|
|
|
|
|
## enable, simply set custom_attribute_exclude to [] (empty set) and use custom_attribute_include
|
|
|
|
|
## to select the attributes you want to include.
|
|
|
|
|
## By default, since they can add a considerable amount of tags to the resulting metrics. To
|
|
|
|
|
## enable, simply set custom_attribute_exlude to [] (empty set) and use custom_attribute_include
|
|
|
|
|
## enable, simply set custom_attribute_exclude to [] (empty set) and use custom_attribute_include
|
|
|
|
|
## to select the attributes you want to include.
|
|
|
|
|
# custom_attribute_include = []
|
|
|
|
|
# custom_attribute_exclude = ["*"]
|
|
|
|
|
@@ -208,7 +208,7 @@ A vCenter administrator can change this setting, see this [VMware KB article](ht
|
|
|
|
|
Any modification should be reflected in this plugin by modifying the parameter `max_query_objects`
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
## number of objects to retreive per query for realtime resources (vms and hosts)
|
|
|
|
|
## number of objects to retrieve per query for realtime resources (vms and hosts)
|
|
|
|
|
## set to 64 for vCenter 5.5 and 6.0 (default: 256)
|
|
|
|
|
# max_query_objects = 256
|
|
|
|
|
```
|
|
|
|
|
@@ -275,12 +275,12 @@ We can extend this to looking at a cluster level: ```/DC0/host/Cluster1/*/hadoop
|
|
|
|
|
|
|
|
|
|
vCenter keeps two different kinds of metrics, known as realtime and historical metrics.
|
|
|
|
|
|
|
|
|
|
* Realtime metrics: Avaialable at a 20 second granularity. These metrics are stored in memory and are very fast and cheap to query. Our tests have shown that a complete set of realtime metrics for 7000 virtual machines can be obtained in less than 20 seconds. Realtime metrics are only available on **ESXi hosts** and **virtual machine** resources. Realtime metrics are only stored for 1 hour in vCenter.
|
|
|
|
|
* Realtime metrics: Available at a 20 second granularity. These metrics are stored in memory and are very fast and cheap to query. Our tests have shown that a complete set of realtime metrics for 7000 virtual machines can be obtained in less than 20 seconds. Realtime metrics are only available on **ESXi hosts** and **virtual machine** resources. Realtime metrics are only stored for 1 hour in vCenter.
|
|
|
|
|
* Historical metrics: Available at a 5 minute, 30 minutes, 2 hours and 24 hours rollup levels. The vSphere Telegraf plugin only uses the 5 minute rollup. These metrics are stored in the vCenter database and can be expensive and slow to query. Historical metrics are the only type of metrics available for **clusters**, **datastores** and **datacenters**.
|
|
|
|
|
|
|
|
|
|
For more information, refer to the vSphere documentation here: https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.wssdk.pg.doc_50%2FPG_Ch16_Performance.18.2.html
|
|
|
|
|
|
|
|
|
|
This distinction has an impact on how Telegraf collects metrics. A single instance of an input plugin can have one and only one collection interval, which means that you typically set the collection interval based on the most frequently collected metric. Let's assume you set the collection interval to 1 minute. All realtime metrics will be collected every minute. Since the historical metrics are only available on a 5 minute interval, the vSphere Telegraf plugin automatically skips four out of five collection cycles for these metrics. This works fine in many cases. Problems arise when the collection of historical metrics takes longer than the collecition interval. This will cause error messages similar to this to appear in the Telegraf logs:
|
|
|
|
|
This distinction has an impact on how Telegraf collects metrics. A single instance of an input plugin can have one and only one collection interval, which means that you typically set the collection interval based on the most frequently collected metric. Let's assume you set the collection interval to 1 minute. All realtime metrics will be collected every minute. Since the historical metrics are only available on a 5 minute interval, the vSphere Telegraf plugin automatically skips four out of five collection cycles for these metrics. This works fine in many cases. Problems arise when the collection of historical metrics takes longer than the collection interval. This will cause error messages similar to this to appear in the Telegraf logs:
|
|
|
|
|
|
|
|
|
|
```2019-01-16T13:41:10Z W! [agent] input "inputs.vsphere" did not complete within its interval```
|
|
|
|
|
|
|
|
|
|
|