sure B<cpufreqd> (L<http://cpufreqd.sourceforge.net/>) or a similar tool is
installed and an "cpu governor" (that's a kernel module) is loaded.
+If the system has the I<cpufreq-stats> kernel module loaded, this plugin reports
+the rate of p-state (cpu frequency) transitions and the percentage of time spent
+in each p-state.
+
=head2 Plugin C<cpusleep>
This plugin doesn't have any options. It reads CLOCK_BOOTTIME and
=back
+=head2 Plugin C<gpu_nvidia>
+
+Efficiently collects various statistics from the system's NVIDIA GPUs using the
+NVML library. Currently collected are fan speed, core temperature, percent
+load, percent memory used, compute and memory frequencies, and power
+consumption.
+
+=over 4
+
+=item B<GPUIndex>
+
+If one or more of these options is specified, only GPUs at that index (as
+determined by nvidia-utils through I<nvidia-smi>) have statistics collected.
+If no instance of this option is specified, all GPUs are monitored.
+
+=item B<IgnoreSelected>
+
+If set to true, all detected GPUs B<except> the ones at indices specified by
+B<GPUIndex> entries are collected. For greater clarity, setting IgnoreSelected
+without any GPUIndex directives will result in B<no> statistics being
+collected.
+
+=back
+
=head2 Plugin C<grpc>
The I<grpc> plugin provides an RPC interface to submit values to or query
=back
+=head2 Plugin C<sysevent>
+
+The I<sysevent> plugin monitors rsyslog messages.
+
+B<Synopsis:>
+
+ <Plugin sysevent>
+ Listen "192.168.0.2" "6666"
+ BufferSize 1024
+ BufferLength 10
+ RegexFilter "regex"
+ </Plugin>
+
+ rsyslog should be configured such that it sends data to the IP and port you
+ include in the plugin configuration. For example, given the configuration
+ above, something like this would be set in /etc/rsyslog.conf:
+
+ if $programname != 'collectd' then
+ *.* @192.168.0.2:6666
+
+ This plugin is designed to consume JSON rsyslog data, so a more complete
+ rsyslog configuration would look like so (where we define a JSON template
+ and use it when sending data to our IP and port):
+
+ $template ls_json,"{%timestamp:::date-rfc3339,jsonf:@timestamp%, \
+ %source:::jsonf:@source_host%,\"@source\":\"syslog://%fromhost-ip:::json%\", \
+ \"@message\":\"%timestamp% %app-name%:%msg:::json%\",\"@fields\": \
+ {%syslogfacility-text:::jsonf:facility%,%syslogseverity:::jsonf:severity-num%, \
+ %syslogseverity-text:::jsonf:severity%,%programname:::jsonf:program%, \
+ %procid:::jsonf:processid%}}"
+
+ if $programname != 'collectd' then
+ *.* @192.168.0.2:6666;ls_json
+
+ Please note that these rsyslog.conf examples are *not* complete, as rsyslog
+ requires more than these options in the configuration file. These examples
+ are meant to demonstration the proper remote logging and JSON format syntax.
+
+B<Options:>
+
+=over 4
+
+=item B<Listen> I<host> I<port>
+
+Listen on this IP on this port for incoming rsyslog messages.
+
+=item B<BufferSize> I<length>
+
+Maximum allowed size for incoming rsyslog messages. Messages that exceed
+this number will be truncated to this size. Default is 4096 bytes.
+
+=item B<BufferLength> I<length>
+
+Maximum number of rsyslog events that can be stored in plugin's ring buffer.
+By default, this is set to 10. Once an event has been read, its location
+becomes available for storing a new event.
+
+=item B<RegexFilter> I<regex>
+
+Enumerate a regex filter to apply to all incoming rsyslog messages. If a
+message matches this filter, it will be published.
+
+=back
+
=head2 Plugin C<syslog>
=over 4
if there is only one package and C<pkgE<lt>nE<gt>-coreE<lt>mE<gt>> if there is
more than one, where I<n> is the n-th core of package I<m>.
+=item B<RestoreAffinityPolicy> I<AllCPUs>|I<Restore>
+
+Reading data from CPU has side-effect: collectd process's CPU affinity mask
+changes. After reading data is completed, affinity mask needs to be restored.
+This option allows to set restore policy.
+
+B<AllCPUs> (the default): Restore the affinity by setting affinity to any/all
+CPUs.
+
+B<Restore>: Save affinity using sched_getaffinity() before reading data and
+restore it after.
+
+On some systems, sched_getaffinity() will fail due to inconsistency of the CPU
+set size between userspace and kernel. In these cases plugin will detect the
+unsuccessful call and fail with an error, preventing data collection.
+Most of configurations does not need to save affinity as Collectd process is
+allowed to run on any/all available CPUs.
+
+If you need to save and restore affinity and get errors like 'Unable to save
+the CPU affinity', setting 'possible_cpus' kernel boot option may also help.
+
+See following links for details:
+
+L<https://github.com/collectd/collectd/issues/1593>
+L<https://sourceware.org/bugzilla/show_bug.cgi?id=15630>
+L<https://bugzilla.kernel.org/show_bug.cgi?id=151821>
+
=back
=head2 Plugin C<unixsock>
=over 4
+=item B<Host> I<Host>
+
+Bind to the hostname / address I<Host>. By default, the plugin will bind to the
+"any" address, i.e. accept packets sent to any of the hosts addresses.
+
+This option is supported only for libmicrohttpd newer than 0.9.0.
+
=item B<Port> I<Port>
Port the embedded webserver should listen on. Defaults to B<9103>.
projects / collectd.git / blobdiff