bloomberg / collectd-cookbook

collectd-cookbook

Application cookbook which installs and configures the collectd monitoring daemon.

This cookbook provides a dead-simple installation and configuration of the collectd monitoring daemon. It provides two resources: the first is for managing the collectd system service, and the second is for configuring the daemon's plugins. Additionally, the collectd_plugins cookbook may be used to configure many of the common plugins that ship with the daemon.

It is very important to note that distributions may ship different major versions of the package, but the following platforms are tested using the integration tests via Test Kitchen.

• Ubuntu ~> 10.04, 12.04, 14.04
• CentOS ~> 5.8, 6.4, 7.1
• RHEL ~> 5.8, 6.4, 7.1

Basic Usage

The default recipe in this cookbook simply configures the monitoring daemon to run as a system service. The configuration for this service can be tuned using the node attributes. Additionally, a resource is provided to configure plugins for the daemon. After a plugin has been configured the daemon should be restarted.

Enabling Syslog

One of the simplest plugins to enable is the collectd Syslog plugin which receives log messages from the daemon and dispatches them to the to syslog. This allows the daemon's logs to easily integrate with existing UNIX utilities.

collectd_plugin 'syslog' do
  options do
    log_level 'info'
    notify_level 'OKAY'
  end
end

Advanced Usage

In order to enable the full functionality of some of the more intrusive collectd plugins the daemon will need to run as the root user. Since this is obviously a security risk it is not the default. To achieve this behavior you're required to write a wrapper cookbook which overrides the service user with the proper root user.

node.default['collectd']['service_user'] = node['root_user']
node.default['collectd']['service_group'] = node['root_group']
include_recipe 'collectd::default'

collectd-cookbook's Issues

Collectd cookbook creates duplicate startup files/instances

This was originally filed under poise/poise-service#20 and closed.

What it comes down to is this: the collectd cookbook installs system packages, and those system packages have an SysV init file included, which is also started (as is the usual on Debian/Ubuntu systems). Then the collectd cookbook calls Poise, which creates an Upstart config file, and starts that one as well. This leaves two instances of collectd running. The author of poise-service says it's not within the scope of that package to determine if there are other init scripts. Does the collectd cookbook need to test for the presence of other init scripts before it calls poise?

Not 100% sure what the solution is here, but having to manually disable one of the scripts makes the cookbook somewhat frustrating to work with. Other than that, it's helped me a lot! :)

Supermarket release does not match current release. 2.2.2 vs. 2.2.3

Allow sub-configurations as needed by Aggregation Plugin.

The collectd plugin 'aggregation' uses a sub-configurations on how to aggregate data from other plugins. In addition, the 'network' plugin uses multiple attributes in sub-configuration element.
Example:

File: /etc/collectd.d/aggregation.conf
LoadPlugin "aggregation"
<Plugin "aggregation">
    <Aggregation>
        Plugin "cpu"
        Type "cpu"
        GroupBy "Host"
        GroupBy "TypeInstance"
        CalculateNum false
        CalculateSum false
        CalculateAverage true
        CalculateMinimum false
        CalculateMaximum false
        CalculateStddev false
    </Aggregation>
</Plugin>

File: /etc/collectd.d/network.conf
LoadPlugin "network"
<Plugin "network">
    <Server "192.168.0.1" "25826">
    </Server>
</Plugin>

This can be accomplished by modifying Line:63 of plugin_config.rb to:

            elsif value.kind_of?(Hash) # rubocop:disable Style/ClassCheck
              id = value.delete('id')
              if !id.nil?
                if id.is_a?(Array)  # handle case where id is an array of attributes
                  id = id.map { |s| "\"#{s}\"" }.join(' ')
                else
                  id = "\"#{id}\""
                end
                [%(#{tabs}<#{key} #{id}>),
                 write_elements(value, indent.next),
                 %(#{tabs}</#{key}>)
                ].join("\n")
              else   # add sub-configuration elements
                [%(#{tabs}<#{key}>),
                 write_elements(value, indent.next),
                 %(#{tabs}</#{key}>)
                ].join("\n")
              end              

And attributes using:

default['collectd_plugins']['aggregation']['aggregation'] = {
    'plugin' => 'cpu',
    'type' => 'cpu',
    'group_by' => %w(Host TypeInstance),
    'calculate_num' => false,
    'calculate_sum' => false,
    'calculate_average' => true,
    'calculate_minimum' => false,
    'calculate_maximum' => false,   
    'calculate_stddev' => false
}

default['collectd_plugins']['network']['server'] = {
    'id' => ['192.168.0.1', '25826']
}

Upstart configuration should use 'expect stop' for compatibility with Collectd v5.5+

Collectd version >= 5.5 automatically recognises that it's supervised by Upstart based on the UPSTART_JOB environment variable, and attempts to signal Upstart by raising SIGSTOP instead of forking.

Unfortunately this means that if Upstart is configured with 'expect fork' as per 9481210 then when the service is started Upstart will hang indefinitely.

Using 'expect stop' instead will allow Upstart to recognise that Collectd has started and, as a bonus, when it has finished initialising.

Allow config blocks with identical keys.

Unfortunately my environment is a bit of a disaster which prevents me from using your cookbook directly, but I did lift CollectdConfig::write_elements() for writing collectd configs. However, I have come across some situations where I need multiple config blocks of the same type, eg:

LoadPlugin "foo"
<Plugin "foo">
  <Ignore "bar>
    ...
  </Ignore>
  <Ignore "baz>
    ...
  </Ignore>
</Plugin>

Which doesn't work with the current version of this function, so I've modified it as follows to allow for arrays of hashes:

def write_elements(directives, indent = 0)
  tabs = ("\t" * indent)
  directives.dup.map do |key, value|
    next if value.nil?
    if value.is_a?(Array)
      value.map do |val|
        if val.is_a?(String)
          %(#{tabs}#{key} "#{val}")
        elsif val.is_a?(Hash)
          write_block(key, val, indent)
        else
          %(#{tabs}#{key} #{val})
        end
      end.join("\n")
    elsif value.kind_of?(Hash) # rubocop:disable Style/ClassCheck
      write_block(key, value, indent)
    elsif value.is_a?(String)
      %(#{tabs}#{key} "#{value}")
    else
      %(#{tabs}#{key} #{value})
    end
  end.flatten.join("\n")
end

def write_block(key, value, indent=0)
    tabs = ("\t" * indent)
    id = value.delete('id')
    if id.nil?
      id = ''
    else
      id = " \"#{id}\""
    end
    [%(#{tabs}<#{key}#{id}>),
      write_elements(value, indent.next),
      %(#{tabs}</#{key}>)
    ].join("\n")
end

So now the directive hash below will produce the desired config in the example above.

{
  'LoadPlugin' => 'foo',
  'Plugin' => {
    'id' => 'foo',
    'Ignore' => [
      {
        'id' => 'bar'
        # ...
      },
      {
        'id' => 'baz'
        # ...
      }
    ]
  }
}

On Ubuntu, Collectd restarts every chef run

It seems like on every chef run on Ubuntu, this shuts the collectd service down, does nothing, and then starts it up again.

Ideally, it would only restart the collectd service on changes.