write_prometheus plugin: New plugin for exposing metrics to Prometheus.
[collectd.git] / src / collectd.conf.pod
index 9088163..dcf6c36 100644 (file)
@@ -7144,6 +7144,13 @@ Use the greatest number only.
 
 Use the last number found.
 
+=item B<GaugePersist>
+
+Use the last number found. The number is not reset at the end of an interval.
+It is continously reported until another number is matched. This is intended
+for cases in which only state changes are reported, for example a thermometer
+that only reports the temperature when it changes.
+
 =item B<CounterSet>
 
 =item B<DeriveSet>
@@ -7773,10 +7780,6 @@ option is set to 0, refreshing is disabled completely.
 
 =item B<BlockDevice> I<name:dev>
 
-=item B<lockDeviceFormat> B<source>|B<dev>
-
-=item B<BlockDeviceFormatBasename> B<false>|B<true>
-
 =item B<InterfaceDevice> I<name:dev>
 
 =item B<IgnoreSelected> B<true>|B<false>
@@ -7802,52 +7805,48 @@ Example:
 Ignore all I<hdb> devices on any domain, but other block devices (eg. I<hda>)
 will be collected.
 
-If I<BlockDeviceFormat> is set to B<dev>, then the device names will be the ones
-in the I<target> node for the device in the XML definition of the domain. The
-default is B<dev>. This is the behavior before adding the option.
-
-If I<BlockDeviceFormat> is set to B<source>, then the device names will be the ones
-in the I<source> node for the device in the XML definition of the domain.
-
-Example:
-
-If the domain XML have the following device defined:
-
-   <disk type='block' device='disk'>
-      <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
-      <source dev='/var/lib/libvirt/images/image1.qcow2'/>
-      <target dev='sda' bus='scsi'/>
-      <boot order='2'/>
-      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
-    </disk>
-
-setting 
+=item B<BlockDeviceFormat> B<target>|B<source>
 
-        BlockDeviceFormat dev
+If I<BlockDeviceFormat> is set to B<target>, the default, then the device name
+seen by the guest will be used for reporting metrics. 
+This corresponds to the C<E<lt>targetE<gt>> node in the XML definition of the
+domain.
 
-will name the device in the graph as sda 
+If I<BlockDeviceFormat> is set to B<source>, then metrics will be reported
+using the path of the source, e.g. an image file.
+This corresponds to the C<E<lt>sourceE<gt>> node in the XML definition of the
+domain.
 
-setting
-       BlockDeviceFormat source
+B<Example:>
 
-will name the device in the graph as var_lib_libvirt_images_image1.qcow2
+If the domain XML have the following device defined:
 
-These names will also be part of the RRD filename.
+  <disk type='block' device='disk'>
+    <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
+    <source dev='/var/lib/libvirt/images/image1.qcow2'/>
+    <target dev='sda' bus='scsi'/>
+    <boot order='2'/>
+    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+  </disk>
 
-I<BlockDeviceFormatBasename> - this option is honored if and only if 
-option I<BlockDeviceFormat> is set to B<source>. If set to B<true> then 
-only the last part of the path will be used for device name and naming the
-RRD file.
+Setting C<BlockDeviceFormat target> will cause the I<type instance> to be set
+to C<sda>.
+Setting C<BlockDeviceFormat source> will cause the I<type instance> to be set
+to C<var_lib_libvirt_images_image1.qcow2>.
 
-Example: 
+=item B<BlockDeviceFormatBasename> B<false>|B<true>
 
-if the device path (source tag) is: /var/lib/libvirt/images/image1.qcow2
+The B<BlockDeviceFormatBasename> controls whether the full path or the
+L<basename(1)> of the source is being used as the I<type instance> when
+B<BlockDeviceFormat> is set to B<source>. Defaults to B<false>.
 
-setting:
-       BlockDeviceFormatBasename true
+B<Example:>
 
-will set the device name to: image1.qcow2
+Assume the device path (source tag) is C</var/lib/libvirt/images/image1.qcow2>.
+Setting C<BlockDeviceFormatBasename false> will cause the I<type instance> to
+be set to C<var_lib_libvirt_images_image1.qcow2>.
+Setting C<BlockDeviceFormatBasename true> will cause the I<type instance> to be
+set to C<image1.qcow2>.
 
 =item B<HostnameFormat> B<name|uuid|hostname|...>
 
@@ -8149,6 +8148,41 @@ want to use authentication all three fields must be set.
 
 =back
 
+=head2 Plugin C<write_prometheus>
+
+The I<write_prometheus plugin> implements a tiny webserver that can be scraped
+using I<Prometheus>.
+
+B<Options:>
+
+=over 4
+
+=item B<Port> I<Port>
+
+Port the embedded webserver should listen on. Defaults to B<9103>.
+
+=item B<StalenessDelta> I<Seconds>
+
+Time in seconds after which I<Prometheus> considers a metric "stale" if it
+hasn't seen any update for it. This value must match the setting in Prometheus.
+It defaults to B<300> seconds (5 minutes), same as Prometheus.
+
+B<Background:>
+
+I<Prometheus> has a global setting, C<StalenessDelta>, which controls after
+which time a metric without updates is considered "stale". This setting
+effectively puts an upper limit on the interval in which metrics are reported.
+
+When the I<write_prometheus plugin> encounters a metric with an interval
+exceeding this limit, it will inform you, the user, and provide the metric to
+I<Prometheus> B<without> a timestamp. That causes I<Prometheus> to consider the
+metric "fresh" each time it is scraped, with the time of the scrape being
+considered the time of the update. The result is that there appear more
+datapoints in I<Prometheus> than were actually created, but at least the metric
+doesn't disappear periodically.
+
+=back
+
 =head2 Plugin C<write_http>
 
 This output plugin submits values to an HTTP server using POST requests and