Giter Club home page Giter Club logo

sensu-puppet's Introduction

Sensu-Puppet

Table of Contents

  1. Module Description
  2. Setup - The basics of getting started with Sensu
  3. Usage - Configuration options and additional functionality
  4. Reference
  5. Examples
  6. Limitations - OS compatibility, etc.
  7. Development - Guide for contributing to the module
  8. License

Module description

Installs and manages Sensu Go, the open source monitoring framework.

Please note, that this is a Partner Supported module, which means that technical customer support for this module is solely provided by Sensu. Puppet does not provide support for any Partner Supported modules. Technical support for this module is provided by Sensu at https://sensu.io/support.

Documented with Puppet Strings

Puppet Strings documentation

Compatibility - supported Sensu versions

If not explicitly stated it should always support the latest Sensu release. Beginning with v5.0.0 this module will only support Sensu Go 6.0+. Please log an issue if you identify any incompatibilities.

Sensu Go Version Recommended Puppet Module Version
5.0 - 5.15 latest v3
5.16+ latest v4
6.0 v5.0.0
6.1+ v5.1.0+

Upgrade note

Sensu Go 5.x is a rewrite of Sensu and no longer depends on redis and rabbitmq. Version 3 of this module supports Sensu Go >= 5.0.0 to < 5.16.0. Version 4 of this module supports Sensu Go >= 5.16.0 < 6.0.0. Version 5.0.0 of this module supports Sensu Go >= 6.0.0 < 6.1.0. Version 5.1.0+ of this module supports Sensu Go >= 6.1.0 < 7.0.0.

Users wishing to use the previous Ruby based Sensu should use the sensu/sensuclassic module.

Updating this module from 4.x to 5.x

This module begins supporting Sensu Go 6 with version >= 5.0.0

NOTE Upgrading to support Sensu Go 6 requires backends have Puppet applied before agents will begin to work as there is an agent specifc Sensu user and role added to support modifying agent entities via the API.

Class parameter changes:

  • Remove deprecated sensu::old_password and sensu::old_agent_password, these parameters are no longer needed and were removed

Type property changes:

  • Remove deprecated url, sha512 and filters properties from sensu_asset, use builds property instead

Changes for backend

There is a manual step to perform to upgrade the sensu-backend after upgrading the backend to 6.x. This module provides the sensu::backend_upgrade bolt task as a way to execute the necessary sensu-backend upgrade command.

Changes for agents

Beginning with Sensu Go 6, some changes to agent.yml will only bootstrap an agent entity, they will not update the entity. If you wish to make changes to values such as subscriptions, labels or annotations after a host is added to Sensu this must be done via the Sensu Go API. To support this it's now required that agents have the ability to make API calls.

In order to ensure agents can make API calls either via API or sensuctl the agent must be told about the admin password and API host:

class { 'sensu':
  api_host                     => 'sensu-backend.example.com',
  agent_entity_config_password => 'supersecret',
}
class { 'sensu::agent':
  ...
}

See API Providers for example Hiera that can be used in a file like common.yaml to easily share the admin password with agents.

This module will still continue to write subscriptions and other agent configurations to agent.yml so that if an agent entity is deleted it can be recreated by restarting the sensu-agent service.

Beginning with Sensu Go 6.2.0 you can go back to making agent.yml the authoritative source for an agent's config by setting sensu::agent::agent_managed_entity to true.

Updating this module from 3.x to 4.x

Class parameter changes:

  • Move sensu::backend::cli_package_name to sensu::cli::package_name
  • Move sensu::backend::sensuctl_chunk_size to sensu::cli::sensuctl_chunk_size
  • Move sensu::backend::url_host to sensu::api_host
  • Move sensu::backend::url_port to sensu::api_port
  • Move sensu::backend::password to sensu::password
  • Move sensu::backend::old_password to sensu::old_password
  • Move sensu::backend::agent_password to sensu::agent_password
  • Move sensu::backend::agent_old_password to sensu::agent_old_password
  • The following parameters were moved from sensu::backend class to sensu::resources class. (Example: sensu::backend::checks becomes sensu::resources::checks)
    • ad_auths
    • assets
    • bonsai_assets
    • checks
    • cluster_members
    • cluster_role_bindings
    • cluster_roles
    • configs (removed)
    • entities
    • etcd_replicators
    • filters
    • handlers
    • hooks
    • ldap_auths
    • mutators
    • namespaces
    • oidc_auths
    • role_bindings
    • roles
    • users

Type property changes:

  • Replace sensu_check proxy_requests* properties with proxy_requests Hash
  • Replace sensu_entity deregistration_handler with deregistration Hash
  • Replace sensu_handler socket_* properties with socket Hash
  • Refactor sensu_ldap_auth and sensu_ad_auth on how properties are defined.
    • Move server_binding, server_group_search and server_user_search into servers property

Breaking changes:

  • Remove sensu_event type, replaced with sensu::event Bolt task
  • Remove sensu_silenced type, replaced with sensu::silenced Bolt task
  • Remove sensu_config type, replaced with sensu::cli::config_format and sensu::cli::config_namespace parameters

Setup

What sensu affects

This module will install packages, create configuration and start services necessary to manage Sensu agents and backend.

Setup requirements

Plugin sync is required if the custom sensu types and providers are used.

Soft module dependencies

For systems using apt:

For systems using yum and Puppet >= 6.0.0:

For Windows:

Beginning with Sensu

This module provides Vagrant definitions that can be used to get started with Sensu.

vagrant up sensu-backend
vagrant ssh sensu-backend

Beginning with a Sensu cluster

Multiple Vagrant boxes are available for testing a sensu-backend cluster.

vagrant up sensu-backend-peer1 sensu-backend-peer2
vagrant provision sensu-backend-peer1 sensu-backend-peer2

Beginning with a Sensu federated cluster

Multiple Vagrant boxes are available for testing a Sensu Go federated cluster. First build and provision both then provision the first a second time to view that the custom role was replicated.

vagrant up sensu-backend-federated1 sensu-backend-federated2
vagrant provision sensu-backend-federated1

The provision command should output from sensuctl the test Sensu Go Role that was created on the other backend. The output should look like the following:

    sensu-backend-federated1:   Name   Namespace   Rules  
    sensu-backend-federated1:  ────── ─────────── ─────── 
    sensu-backend-federated1:   test   default         1  

Usage

Location of Resources

Sensu Go is designed to have resources like checks and assets defined on the backend host. For Puppet this means that the simplest configuration will be one where checks and other resources are defined on the host using sensu::backend class. Hosts with only the sensu::agent class do not need to have checks defined on them, rather just have to have a subscription assigned that matches a check.

Basic Sensu backend

The following example will configure sensu-backend, sensu-agent on backend and add a check. By default this module will configure the backend to use Puppet's SSL certificate and CA. It is advisable to not rely on the default password. NOTE When changing the password value, it's necessary to run Puppet on the backend first to update the admin password.

  class { 'sensu':
    password => 'supersecret',
  }
  include sensu::backend
  include sensu::agent
  sensu_check { 'check-cpu':
    ensure        => 'present',
    command       => 'check-cpu.sh -w 75 -c 90',
    interval      => 60,
    subscriptions => ['linux'],
  }

Basic Sensu agent

The following example will manage resources necessary to configure a sensu-agent to communicate with a sensu-backend and associated to linux and apache-servers subscriptions.

  class { 'sensu':
    api_host                     => 'sensu-backend.example.com',
    agent_entity_config_password => 'supersecret',
  }
  class { 'sensu::agent':
    backends      => ['sensu-backend.example.com:8081'],
    subscriptions => ['linux', 'apache-servers'],
  }

Basic Sensu CLI

The following example will manage the resources necessary to use sensuctl.

class { 'sensu':
  api_host => 'sensu-backend.example.com',
  password => 'supersecret',
}
include sensu::cli

NOTE: The sensu::backend class calls the sensu::cli class so it is only necessary to directly call the sensu::cli class on hosts not using the sensu::backend class.

For Windows the install_source parameter must be provided:

class { 'sensu':
  api_host => 'sensu-backend.example.com',
  password => 'supersecret',
}
class { 'sensu::cli':
  install_source => 'https://s3-us-west-2.amazonaws.com/sensu.io/sensu-go/5.14.1/sensu-go_5.14.1_windows_amd64.zip',
}

API Providers

All the core resources have a provider that manages resources using the Sensu Go API. The new provider can be used by setting provider parameter on a resource to sensu_api. The default provider is still sensuctl but it's possible to change the provider when defining a resource. For example the following will create a check which can be defined on an host that's not the sensu-backend.

include ::sensu::api
sensu_check { "check-cpu-${facts['hostname']}":
  ensure        => 'present',
  command       => 'check-cpu.sh -w 75 -c 90',
  interval      => 60,
  subscriptions => ["entity:${facts['hostname']}"],
  provider      => 'sensu_api',
}

The sensu::api class is required in order to configure the credentials and URL used to communicate with the Sensu backend API.

The API URL, username and password used for the API are set in the sensu class and can be set easily with Hiera:

sensu::api_host: sensu-backend.example.com
sensu::api_port: 8080
sensu::username: admin
sensu::password: supersecret
sensu::agent_entity_config_password: supersecret

Manage Windows Agent

This module supports Windows Sensu Go agent via chocolatey beginning with version 5.12.0.

class { 'sensu':
  api_host                     => 'sensu-backend.example.com',
  agent_entity_config_password => 'supersecret',
}
class { 'sensu::agent':
  backends      => ['sensu-backend.example.com:8081'],
  subscriptions => ['windows'],
}

If you do not wish to install using chocolatey then you must define package_source as either a URL, a Puppet source or a filesystem path.

Install sensu-go-agent on Windows from URL:

class { 'sensu::agent':
  package_name   => 'Sensu Agent',
  package_source => 'https://s3-us-west-2.amazonaws.com/sensu.io/sensu-go/5.13.1/sensu-go-agent_5.13.1.5957_en-US.x64.msi',
}

Install sensu-go-agent on Windows from Puppet source:

class { 'sensu::agent':
  package_name   => 'Sensu Agent',
  package_source => 'puppet:///modules/profile/sensu/sensu-go-agent.msi',
}

If a system already has the necessary MSI present it can be installed without downloading from an URL:

class { 'sensu::agent':
  package_name   => 'Sensu Agent',
  package_source => 'C:\Temp\sensu-go-agent.msi',
}

Advanced agent

If you wish to have the agent.yml be authoritative for agent entity configs:

class { 'sensu::agent':
  agent_managed_entity  => true,
}

If you wish to change the agent password you must provide the new and old password. It is advisable to set show_diff to false to avoid exposing the agent password.

class { 'sensu':
  agent_password => 'supersecret',
}
class { 'sensu::agent':
  show_diff => false,
}

The config_hash parameter allows custom configuration for agent.yml outside the sensu::agent class parameters.

class { 'sensu::agent':
  config_hash => {
    'log-level' => 'debug',
  },
}

The following parameters in sensu::agent class are used to populate agent.yml:

  • entity_name - Passed to name key in agent.yml
  • subscriptions
  • annotations
  • labels
  • namespace
  • redact

Agent configurations can also be set via sensu::agent::config_entry. See Advanced agent - Custom config entries.

Advanced agent - Subscriptions

It is possible to define subscriptions in many locations and the values merged into agent.yml:

class { 'sensu::agent':
  subscriptions => ['base'],
}

Then in a profile class for Apache you could define the following:

sensu::agent::subscription { 'apache': }

The resulting agent.yml would contain subscriptions for both base and apache.

NOTE: Subscriptions defined using the sensu::agent class and sensu::agent::subscription are merged to produce the final subscription array.

Advanced agent - Annotations and Labels

It is possible to define annotations and labels in many locations and the values merged into agent.yml:

class { 'sensu::agent':
  labels      => { 'location' => 'uswest', 'contacts' => '[email protected]' },
  annotations => { 'cpu.warning' => '90', 'cpu.critical' => '100' },
}

Then in a profile class you can define the following:

sensu::agent::label { 'contacts': value => '[email protected]' }
sensu::agent::label { 'environment': value => 'dev' }
sensu::agent::annotation { 'cpu.warning': value => '75' }
sensu::agent::annotation { 'fatigue_check/occurrences': value => '2' }

The resulting agent.yml will contain the following:

labels:
  location: uswest
  contacts: [email protected]
  environment: dev
annotations:
  cpu.warning: '75'
  cpu.critical: '100'
  fatigue_check/occurrences: '2'

NOTE sensu::agent::annotation and sensu::agent::label take precedence over values set by the class sensu::agent

If you wish to redact a label or annotation you can use the redact parameter and the key will be added to the redact list in agent.yml:

sensu::agent::label { 'secret':
  value  => 'mysecret',
  redact => true,
}
sensu::agent::annotation { 'ec2_access_key':
  value  => 'some-key',
  redact => true,
}

Advanced agent - Disable validations

In some cases it might be desired to disable API and entity validations when agents are managing their own entity.

class { 'sensu':
  validate_api => false,
}
class { 'sensu::agent':
  agent_managed_entity => true,
  validate_entity      => false,
}

Advanced agent - Custom config entries

It is possible to define config entries for agent.yml in many locations in Puppet:

sensu::agent::config_entry { 'keepalive-interval': value => 20 }

This would add the following to agent.yml:

keepalive-interval: 20

NOTE sensu::agent::config_entry takes precendence over values defined in sensu::agent class.

Advanced SSL

By default this module uses Puppet's SSL certificates and CA. If you would prefer to use different certificates override the ssl_ca_source, ssl_cert_source and ssl_key_source parameters. The value for api_host must be valid for the provided certificate and the value used for agent's backends must also match the certificate used by the specified backend. If the certificates and keys are already installed then define the source parameters as filesystem paths.

class { 'sensu':
  ssl_ca_source => 'puppet:///modules/profile/sensu/ca.pem',
  api_host      => 'sensu-backend.example.com',
}
class { 'sensu::backend':
  ssl_cert_source => 'puppet:///modules/profile/sensu/cert.pem',
  ssl_key_source  => 'puppet:///modules/profile/sensu/key.pem',
}
class { 'sensu':
  ssl_ca_source => 'puppet:///modules/profile/sensu/ca.pem',
}
class { 'sensu::agent':
  backends      => ['sensu-backend.example.com:8081'],
  subscriptions => ['linux', 'apache-servers'],
}

To disable SSL support:

class { 'sensu':
  use_ssl => false,
}

Enterprise Support

In order to activate enterprise support the license file needs to be added:

class { 'sensu::backend':
  license_source => 'puppet:///modules/profile/sensu/license.json',
}

The types sensu_ad_auth and sensu_ldap_auth require a valid enterprise license.

Contact routing

See Sensu Go - Route alerts with event filters for details. The following is one way to configure contact routing in Puppet.

Add the sensu-go-has-contact-filter bonsai asset:

sensu_bonsai_asset { 'sensu/sensu-go-has-contact-filter':
  ensure  => 'present',
  version => '0.2.0',
}

Add the filters for the defined contacts

sensu_filter { 'contact_dev':
  ensure         => 'present',
  action         => 'allow',
  runtime_assets => ['sensu/sensu-go-has-contact-filter'],
  expressions    => ['has_contact(event, "dev")'],
}
sensu_filter { 'contact_ops':
  ensure         => 'present',
  action         => 'allow',
  runtime_assets => ['sensu/sensu-go-has-contact-filter'],
  expressions    => ['has_contact(event, "ops")'],
}

Add the handlers asset and handlers for each contact

sensu_bonsai_asset { 'sensu/sensu-email-handler':
  ensure  => 'present',
  version => '0.2.0',
}
sensu_handler { 'email_dev':
  ensure          => 'present',
  type            => 'pipe',
  command         => 'sensu-email-handler -f root@localhost -t [email protected] -s localhost -i',
  timeout         => 10,
  runtime_assets  => ['sensu/sensu-email-handler'],
  filters         => ['is_incident','not_silenced','contact_dev'],
}
sensu_handler { 'email_ops':
  ensure          => 'present',
  type            => 'pipe',
  command         => 'sensu-email-handler -f root@localhost -t [email protected] -s localhost -i',
  timeout         => 10,
  runtime_assets  => ['sensu/sensu-email-handler'],
  filters         => ['is_incident','not_silenced','contact_ops'],
}

Create a handler set to centralize handler management for emails

sensu_handler { 'email':
  ensure    => 'present',
  type      => 'set',
  handlers  => ['email_dev','email_ops'],
}

Lastly define a service that use the contact and the email handler:

sensu_check { 'check_cpu':
  ensure         => 'present',
  labels         => {
    'contacts' => 'dev, ops',
  },
  command        => 'check-cpu.rb -w 75 -c 90',
  handlers       => ['email'],
  interval       => 30,
  publish        => true,
  subscriptions  => ['linux'],
  runtime_assets => ['sensu-plugins-cpu-checks','sensu-ruby-runtime'],
}

Agents can also have contacts defined:

class { 'sensu::agent':
  labels => {
    'contacts' => 'dev, ops',
  },
}

PostgreSQL datastore support

NOTE: This features require a valid Sensu Go enterprise license.

The following example will add a PostgreSQL server and database to the sensu-backend host and configure Sensu Go to use PostgreSQL as the event datastore.

class { 'postgresql::globals':
  manage_package_repo => true,
  version             => '11',
}
class { 'postgresql::server': }
class { 'sensu::backend':
  license_source      => 'puppet:///modules/profile/sensu/license.json',
  datastore           => 'postgresql',
  postgresql_password => 'secret',
}

Refer to the puppetlabs/postgresql module documentation for details on how to manage PostgreSQL with Puppet.

The following example uses an external PostgreSQL server.

class { 'sensu::backend':
  license_source       => 'puppet:///modules/profile/sensu/license.json',
  datastore            => 'postgresql',
  postgresql_password  => 'secret',
  postgresql_host      => 'postgresql.example.com',
  manage_postgresql_db => false,
}

NOTE Set postgresql_password to false if you want the DSN to only contain a username.

Installing Plugins

Plugin management is handled by the sensu::plugins class.

Example installing plugins on agent:

  class { 'sensu::agent':
    backends      => ['sensu-backend.example.com:8081'],
    subscriptions => ['linux', 'apache-servers'],
  }
  class { 'sensu::plugins':
    plugins => ['disk-checks'],
  }

The plugins parameter can also be a Hash that sets the version:

  class { 'sensu::agent':
    backends      => ['sensu-backend.example.com:8081'],
    subscriptions => ['linux', 'apache-servers'],
  }
  class { 'sensu::plugins':
    plugins => {
      'disk-checks' => { 'version' => 'latest' },
    },
  }

Set dependencies to an empty Array to disable the sensu::plugins dependency management.

  class { 'sensu::plugins':
    dependencies => [],
  }

If gems are required and not pulled in as gem dependencies they can also be installed.

class { 'sensu::plugins':
  plugins          => ['memory-checks'],
  gem_dependencies => ['vmstat'],
}

You can uninstall plugins by passing ensure as absent.

  class { 'sensu::agent':
    backends      => ['sensu-backend.example.com:8081'],
    subscriptions => ['linux', 'apache-servers'],
  }
  class { 'sensu::plugins':
    plugins => {
      'disk-checks' => { 'ensure' => 'absent' },
    },
  }

Installing Extensions

Extension management is handled by the sensu::plugins class.

Example installing extension on backend:

  class { 'sensu':
    password => 'supersecret',
  }
  include sensu::backend
  class { 'sensu::plugins':
    extensions => ['graphite'],
  }

The extensions parameter can also be a Hash that sets the version:

  class { 'sensu':
    password => 'supersecret',
  }
  include sensu::backend
  class { 'sensu::plugins':
    extensions => {
      'graphite' => { 'version' => 'latest' },
    },
  }

You can uninstall extensions by passing ensure as absent.

  class { 'sensu':
    password => 'supersecret',
  }
  include sensu::backend
  class { 'sensu::plugins':
    extensions => {
      'graphite' => { 'ensure' => 'absent' },
    },
  }

Exported resources

One possible approach to defining checks is having agents export their checks to the sensu-backend using Exported Resources.

The following example would be defined for agents:

  @@sensu_check { 'check-cpu':
    ensure        => 'present',
    command       => 'check-cpu.sh -w 75 -c 90',
    interval      => 60,
    subscriptions => ['linux'],
  }

The backend system would collect all sensu_check resources.

  Sensu_check <<||>>

Hiera resources

All the types provided by this module can have their resources defined via Hiera. A type such as sensu_check would be defined via sensu::resources::checks.

The sensu class must be included either directly or via sensu::agent or sensu::backend.

The following example adds an asset, filter, handler and checks via Hiera:

sensu::resources::assets:
  sensu-email-handler:
    ensure: present
    url: 'https://github.com/sensu/sensu-email-handler/releases/download/0.1.0/sensu-email-handler_0.1.0_linux_amd64.tar.gz'
    sha512: '755c7a673d94997ab9613ec5969666e808f8b4a8eec1ba998ee7071606c96946ca2947de5189b24ac34a962713d156619453ff7ea43c95dae62bf0fcbe766f2e'
    filters:
      - "entity.system.os == 'linux'"
      - "entity.system.arch == 'amd64'"
sensu::resources::filters:
  hourly:
    ensure: present
    action: allow
    expressions:
      - 'event.check.occurrences == 1 || event.check.occurrences % (3600 / event.check.interval) == 0'
sensu::resources::handlers:
  email:
    ensure: present
    type: pipe
    command: "sensu-email-handler -f root@localhost -t [email protected] -s localhost -i"
    timeout: 10
    runtime_assets:
      - sensu-email-handler
    filters:
      - is_incident
      - not_silenced
      - hourly
sensu::resources::checks:
  check-cpu:
    ensure: present
    command: check-cpu.sh -w 75 -c 90
    interval: 60
    subscriptions:
      - linux
    handlers:
      - email
    publish: true
  check-disks:
    ensure: present
    command: "/opt/sensu-plugins-ruby/embedded/bin/check-disk-usage.rb -t '(xfs|ext4)'"
    subscriptions:
      - linux
    handlers:
      - email
    interval: 1800
    publish: true

Resource purging

All the types provided by this module support purging except sensu_config. This example will remove all unmanaged Sensu checks:

sensu_resources { 'sensu_check':
  purge => true,
}

To selectively purge sensu_agent_entity_config entries, you can specify the type of config to purge. If agent_entity_configs is omitted then all unmanaged sensu_agent_entity_config resources will be purged. The following example will only purge subscriptions:

sensu_resources { 'sensu_agent_entity_config':
  purge                => true,
  agent_entity_configs => ['subscriptions'],
}

NOTE: The Puppet built-in resources can also be used for purging but you must ensure that resources that support namespaces are defined using composite names in the form of $name in $namespace. See Composite Names for Namespaces for details on composite names.

Using the Puppet built-in resources would look like this:

resources { 'sensu_check':
  purge => true,
}

Sensu backend cluster

A sensu-backend cluster can be defined for fresh installs by defining the necessary config_hash values. The following examples are using Hiera and assume the sensu::backend class is included.

# data/fqdn/sensu-backend1.example.com.yaml
---
sensu::backend::config_hash:
  etcd-advertise-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-peer-urls: 'http://0.0.0.0:2380'
  etcd-initial-cluster: 'backend1=http://192.168.0.1:2380,backend2=http://192.168.0.2:2380'
  etcd-initial-advertise-peer-urls: "http://%{facts.ipaddress}:2380"
  etcd-initial-cluster-state: 'new'
  etcd-initial-cluster-token: ''
  etcd-name: 'backend1'
# data/fqdn/sensu-backend2.example.com.yaml
---
sensu::backend::config_hash:
  etcd-advertise-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-peer-urls: 'http://0.0.0.0:2380'
  etcd-initial-cluster: 'backend1=http://192.168.0.1:2380,backend2=http://192.168.0.2:2380'
  etcd-initial-advertise-peer-urls: "http://%{facts.ipaddress}:2380"
  etcd-initial-cluster-state: 'new'
  etcd-initial-cluster-token: ''
  etcd-name: 'backend2'

Adding backend members to an existing cluster

Adding new members to an existing cluster requires two steps.

First, add the member to the catalog on one of the existing cluster backends with the sensu_cluster_member type.

sensu_cluster_member { 'backend3':
  peer_urls => ['http://192.168.0.3:2380'],
}

Second, configure and start sensu-backend to interact with the existing cluster. The output from Puppet when a new sensu_cluster_member is applied will print some of the values needed.

# data/fqdn/sensu-backend3.example.com.yaml
---
sensu::backend::config_hash:
  etcd-advertise-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-client-urls: "http://%{facts.ipaddress}:2379"
  etcd-listen-peer-urls: 'http://0.0.0.0:2380'
  etcd-initial-cluster: 'backend1=http://192.168.0.1:2380,backend2=http://192.168.0.2:2380,backend3=http://192.168.0.3:2380'
  etcd-initial-advertise-peer-urls: "http://%{facts.ipaddress}:2380"
  etcd-initial-cluster-state: 'existing'
  etcd-initial-cluster-token: ''
  etcd-name: 'backend3'

The first step will not fully add the node to the cluster until the second step is performed.

Sensu backend federation

This module supports defining Etcd replicators which allows resources to be sent from one Sensu cluster to another cluster. It is necessary that Etcd be listening on an interface that can be accessed by other Sensu backends. First configure backend Etcd to listen on an interface besides localhost and also use SSL:

class { 'sensu::backend':
  config_hash => {
    'etcd-listen-client-urls'    => "https://0.0.0.0:2379",
    'etcd-advertise-client-urls' => "https://0.0.0.0:2379",
    'etcd-cert-file'             => "/etc/sensu/etcd-ssl/${facts['fqdn'].pem",
    'etcd-key-file'              => "/etc/sensu/etcd-ssl/${facts['fqdn']}-key.pem",
    'etcd-trusted-ca-file'       => "/etc/sensu/etcd-ssl/ca.pem",
    'etcd-client-cert-auth'      => true,
  },
}

Next configure the Etcd replicator on the backend you wish to push resources from. In the following example all defined Role resources will be replicated to the backend at the IP address 192.168.52.30.

sensu_etcd_replicator { 'role_replicator':
  ensure        => 'present',
  ca_cert       => '/etc/sensu/etcd-ssl/ca.pem',
  cert          => '/etc/sensu/etcd-ssl/client.pem',
  key           => '/etc/sensu/etcd-ssl/client-key.pem',
  url           => 'https://192.168.52.30:2379',
  resource_name => 'Role',
}
sensu_role { 'test':
  ensure => 'present',
  rules  => [{'verbs' => ['get','list'], 'resources' => ['checks'], 'resource_names' => ['']}],
}

This module also supports defining a federated cluster:

sensu_cluster_federation { 'us-west-2a':
  ensure   => 'present',
  api_urls => [
    'https://sensu-backend-site1.example.com:8080',
    'https://sensu-backend-site2.example.com:8080',
  ],
}

It is also possible to add a backend to an existing Sensu federated cluster. The following example adds the API URL https://sensu-backend-site3.example.com:8080 to the federated cluster named us-west-2a.

sensu_cluster_federation_member { 'https://sensu-backend-site3.example.com:8080 in us-west-2a':
  ensure => 'present',
}

The above can also be defined using the following example:

sensu_cluster_federation_member { 'https://sensu-backend-site3.example.com:8080':
  ensure  => 'present',
  cluster => 'us-west-2a',
}

Large Environment Considerations

If the backend system has a large number of resources it may be necessary to query resources using chunk size added in Sensu Go 5.8.

class { 'sensu::backend':
  sensuctl_chunk_size => 100,
}

If many thousands of resources such as sensu_check are defined there will be an execution of sensuctl namespace list for each check to validate the namespace exists if the namespace is not defined in Puppet. A similar validation is performed with sensu_api provider. To avoid this extra overhead it may be necessary to disable this validation if you are defining namespaces outside of Puppet.

NOTE: If namespace validation is disabled it's necessary to ensure a namespace is defined in Puppet in order to assign resources to that namespace.

class { 'sensu':
  validate_namespaces => false,
}

Composite Names for Namespaces

All resources that support having a namespace also support a composite name to define the namespace.

For example, the sensu_check with name check-cpu in team1 would be named check-cpu and put into the team1 namespace.

Using composite names is necessary if you wish to have multiple resources with the same name but in different namespaces.

For example to define the same check in two namespaces using the same check name:

sensu_check { 'check-cpu in default':
  ensure        => 'present',
  command       => 'check-cpu.sh -w 75 -c 90',
  interval      => 60,
  subscriptions => ['linux'],
}
sensu_check { 'check-cpu in team1':
  ensure        => 'present',
  command       => 'check-cpu.sh -w 75 -c 90',
  interval      => 60,
  subscriptions => ['linux'],
}

The example above would add the check-cpu check to both the default and team1 namespaces.

NOTE: If you use composite names for namespaces, the namespace property takes precedence.

Installing Bonsai Assets

Install a bonsai asset. The latest version will be installed but not automatically upgraded.

sensu_bonsai_asset { 'sensu/sensu-pagerduty-handler':
  ensure  => 'present',
}

Install specific version of a bonsai asset.

sensu_bonsai_asset { 'sensu/sensu-pagerduty-handler':
  ensure  => 'present',
  version => '1.2.0',
}

Install latest version of a bonsai asset. Puppet will update the Bonsai asset if a new version is released.

sensu_bonsai_asset { 'sensu/sensu-pagerduty-handler':
  ensure  => 'present',
  version => 'latest',
}

Bolt Tasks

The following Bolt tasks are provided by this Module:

sensu::backend_upgrade: Perform backend upgrade via sensu-backend upgrade command.

Example: bolt task run sensu::backend_upgrade --targets sensu_backend

sensu::agent_event: Create a Sensu Go agent event via the agent API

Example: bolt task run sensu::agent_event name=bolttest status=1 output=test --targets sensu_agent

sensu::apikey: Manage Sensu Go API keys

Example: bolt task run sensu::apikey action=create username=foobar --targets sensu_backend Example: bolt task run sensu::apikey action=list --targets sensu_backend Example: bolt task run sensu::apikey action=delete key=replace-with-uuid-key --targets sensu_backend

sensu::assets_outdated: Retreive outdated Sensu Go assets

Example: bolt task run sensu::assets_outdated --targets sensu_backend

sensu::check_execute: Execute a Sensu Go check

Example: bolt task run sensu::check_execute check=test subscription=entity:sensu_agent --targets sensu_backend

sensu::event.json: Manage Sensu Go events

Example: bolt task run sensu::event action=resolve entity=sensu_agent check=test --targets sensu_backend

Example: bolt task run sensu::event action=delete entity=sensu_agent check=test --targets sensu_backend

sensu::silenced: Manage Sensu Go silencings

Example: bolt task run sensu::silenced action=create subscription=entity:sensu_agent expire_on_resolve=true --targets sensu_backend

Example: bolt task run sensu::silenced action=delete subscription=entity:sensu_agent --targets sensu_backend

sensu::install_agent: Install Sensu Go agent (Windows and Linux)

Example: bolt task run sensu::install_agent backend=sensu_backend:8081 subscription=linux output=true --targets linux

Example: bolt task run sensu::install_agent backend=sensu_backend:8081 subscription=windows output=true --targets windows

Bolt Inventory

This module provides a plugin to populate Bolt v2 inventory targets.

In order to use the sensu inventory plugin the host executing Bolt must have sensuctl configured, see Basic Sensu CLI.

Example of configuring the Bolt inventory with two groups. The linux group pulls Sensu Go entities in the default namespace with the linux subscription. The linux-qa group is the same as linux group but instead pulling entities from the qa namespace.

version: 2
groups:
  - name: linux
    targets:
      - _plugin: sensu
        namespace: default
        subscription: linux
  - name: linux-qa
    targets:
      - _plugin: sensu
        namespace: qa
        subscription: linux

If your entities have more than one network interface it may be necessary to specify the order of interfaces to search when looking for the IP address:

version: 2
groups:
  - name: linux
    targets:
      - _plugin: sensu
        namespace: default
        subscription: linux
        interface_list:
          - eth0
          - eth1

The following rules for interface matching determine the value used for uri.

  1. If interface_list was defined then find first match
  2. If interface_list not defined and only one interface, use that as ipaddress
  3. If interface_list is not defined and more than one interface, use name

Reference

Facts

sensu_agent

The sensu_agent fact returns the Sensu agent version information by the sensu-agent binary.

facter -p sensu_agent
{
  version => "5.1.0",
  build => "b2ea9fcdb21e236e6e9a7de12225a6d90c786c57",
  built => "2018-12-18T21:31:11+0000"
}

sensu_backend

The sensu_backend fact returns the Sensu backend version information by the sensu-backend binary.

facter -p sensu_backend
{
  version => "5.1.0",
  build => "b2ea9fcdb21e236e6e9a7de12225a6d90c786c57",
  built => "2018-12-18T21:31:11+0000"
}

sensuctl

The sensuctl fact returns the sensuctl version information by the sensuctl binary.

facter -p sensuctl
{
  version => "5.1.0",
  build => "b2ea9fcdb21e236e6e9a7de12225a6d90c786c57",
  built => "2018-12-18T21:31:11+0000"
}

Examples

Examples can be found in the examples directory.

Limitations

Changing sensu::etc_dir is only supported on systems using systemd.

The type sensu_user does not at this time support ensure => absent due to a limitation with sensuctl, see sensu-go#2540.

When changing the sensu::password value, it's necessary to run Puppet on the backend first to update the admin password.

Notes regarding support

This module is built for use with Puppet versions 6 and 7 and the ruby versions associated with those releases. See .travis.yml for an exact matrix of Puppet releases and ruby versions.

This module targets the latest release of the current major Puppet version and the previous major version. Platform support will be removed when a platform is no longer supported by Puppet, Sensu or the platform maintainer has signaled that it is end of life (EOL).

Though Amazon does not announce end of life (EOL) for its releases, it does encourage you to use the latest releases. This module will support the current release and the previous release. Since AWS does not release Vagrant boxes and the intent of those platforms is to run in AWS, we will not maintain Vagrant systems for local development for Amazon Linux.

Supported Platforms

  • EL 6
  • EL 7
  • EL 8
  • Debian 9
  • Debian 10
  • Ubuntu 16.04 LTS
  • Ubuntu 18.04 LTS
  • Ubuntu 20.04 LTS
  • Amazon 2018.03
  • Amazon 2
  • Windows Server 2008 R2
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

Development

See CONTRIBUTING.md

License

See LICENSE file.

sensu-puppet's People

Contributors

alvagante avatar antonlindstrom avatar bobtfish avatar bodgit avatar bovy89 avatar cataphract avatar cdenneen avatar chrissav avatar cwjohnston avatar ghoneycutt avatar gsalisbury avatar jacobmw avatar jamtur01 avatar jaxxstorm avatar jeffmccune avatar jlambert121 avatar johnf avatar jonathanio avatar madandroid avatar phil-friderici avatar portertech avatar rhoml avatar rodjek avatar spuder avatar superseb avatar treydock avatar ttarczynski avatar wallies avatar zanloy avatar zdenekjanda avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sensu-puppet's Issues

Sensu client config notify on no change

Hello,

Everytime sensu runs it reports the following;

Info: Applying configuration version '1401284291'
Notice: /Stage[main]/Sensu::Client::Config/Sensu_client_config[search01a.log.moo.net.uk]/ensure: created
Info: Class[Sensu::Client::Config]: Scheduling refresh of Service[sensu-client]
Notice: /Stage[main]/Sensu::Client::Service/Service[sensu-client]/ensure: ensure changed 'stopped' to 'running'
Info: /Stage[main]/Sensu::Client::Service/Service[sensu-client]: Unscheduling refresh on Service[sensu-client]
Notice: Finished catalog run in 14.55 seconds

The file /etc/sensu/conf.d/client.json does not appear to change each run.

The config is simple;

{
"client": {
"name": "search01a.log.moo.net.uk",
"address": "212.2.3.4",
"subscriptions": [
"sensutest"
],
"safe_mode": true
}
}

Running puppet 3.5.1 and 3..6.1 with latest stdlib and sensu-puppet.


If I change to the forge edition the problem does not appear. So something in the git version vs forge is breaking it for me. app

Use str2bool() from stdlib

I accidentally stumbled on your Puppet files and started looking into them. There's a few places where you do the following:

if $var != true and $var != 'true' {
..
}

You can avoid that by calling out to the str2bool() function from puppetlabs-stdlib which is already a dependency according to your Modulefile. str2bool() will return the boolean if a boolean is passed in.

This in turn now allows you to simply do:

if str2bool($var) != true {
...
}

This will cover both the boolean true and the string 'true'.

Forge package contains 'hidden' OSX files

Lots of files with pattern ._FILENAME:

# find . -name "._*"
./templates/._sensu.erb
./._spec
./manifests/._client
./manifests/._package.pp
./manifests/rabbitmq/._config.pp
./manifests/._plugin.pp
./manifests/dashboard/._service.pp
./manifests/dashboard/._config.pp
./manifests/._handler.pp
./manifests/._dashboard
./manifests/._init.pp
./manifests/._filter.pp
./manifests/._redis
./manifests/._server
./manifests/server/._service.pp
./manifests/._subscription.pp
./manifests/._check.pp
./manifests/._rabbitmq
./manifests/._config.pp
./manifests/api/._service.pp
./manifests/api/._config.pp
./manifests/client/._service.pp
./manifests/client/._config.pp
./manifests/._api
./manifests/._repo
./manifests/redis/._config.pp
./manifests/repo/._apt.pp
./manifests/repo/._yum.pp
./._Rakefile
./._README.md
./lib/._puppet
./lib/puppet_x/sensu/._to_type.rb
./lib/puppet_x/._sensu
./lib/puppet/feature/._json.rb
./lib/puppet/provider/._sensu_api_config
./lib/puppet/provider/._sensu_check
./lib/puppet/provider/sensu_check_config/._json.rb
./lib/puppet/provider/._sensu_client_subscription
./lib/puppet/provider/sensu_rabbitmq_config/._json.rb
./lib/puppet/provider/sensu_check/._json.rb
./lib/puppet/provider/._sensu_filter
./lib/puppet/provider/._sensu_dashboard_config
./lib/puppet/provider/sensu_client_subscription/._json.rb
./lib/puppet/provider/sensu_dashboard_config/._json.rb
./lib/puppet/provider/._sensu_handler
./lib/puppet/provider/._sensu_rabbitmq_config
./lib/puppet/provider/._sensu_client_config
./lib/puppet/provider/._sensu_redis_config
./lib/puppet/provider/sensu_redis_config/._json.rb
./lib/puppet/provider/sensu_api_config/._json.rb
./lib/puppet/provider/._sensu_check_config
./lib/puppet/provider/sensu_client_config/._json.rb
./lib/puppet/provider/sensu_filter/._json.rb
./lib/puppet/provider/sensu_handler/._json.rb
./lib/puppet/._type
./lib/puppet/._feature
./lib/puppet/type/._sensu_check_config.rb
./lib/puppet/type/._sensu_filter.rb
./lib/puppet/type/._sensu_rabbitmq_config.rb
./lib/puppet/type/._sensu_client_config.rb
./lib/puppet/type/._sensu_dashboard_config.rb
./lib/puppet/type/._sensu_redis_config.rb
./lib/puppet/type/._sensu_handler.rb
./lib/puppet/type/._sensu_client_subscription.rb
./lib/puppet/type/._sensu_api_config.rb
./lib/puppet/type/._sensu_check.rb
./lib/puppet/._provider
./lib/._puppet_x
./._manifests
./._lib
./._Modulefile
./._templates
./._metadata.json
./spec/defines/._sensu_handler_spec.rb
./spec/defines/._sensu_filter_spec.rb
./spec/defines/._sensu_subscription_spec.rb
./spec/defines/._sensu_check_spec.rb
./spec/defines/._sensu_plugin_spec.rb
./spec/classes/._sensu_init_spec.rb
./spec/classes/._sensu_rabbitmq_spec.rb
./spec/classes/._sensu_client_spec.rb
./spec/classes/._sensu_redis_spec.rb
./spec/classes/._sensu_dashboard_spec.rb
./spec/classes/._sensu_package_spec.rb
./spec/classes/._sensu_api_spec.rb
./spec/classes/._sensu_server_spec.rb
./spec/unit/._puppet_x_sensu_totype_spec.rb
./spec/._spec_helper.rb
./spec/._fixtures
./spec/fixtures/._modules
./spec/fixtures/._manifests
./spec/._defines
./spec/._unit
./spec/._classes
./._LICENSE

# file ./lib/puppet/type/._sensu_check_config.rb
./lib/puppet/type/._sensu_check_config.rb: AppleDouble encoded Macintosh file

Items are not part of the git repo. Seems like they sneaked in during the packaging on a mac.

Adding/removing a standalone check to a node does not cause the sensu-client service to reload

  • I'm using puppet 2.7
  • The following is happening on the client and not the server
  • purge_config is set to true.

When I add sensu::check directly to a node the check gets created, but no service reload is triggered. As a result the check does not get picked up by sensu-client.

When I remove the very same sensu:check block and then force puppet to run the check definition is removed, but instead of sensu-client being reloaded puppet will try to reload sensu-server, sensu-api- and sensu-dashboard.

Intermittent catalog error

After updating to the latest version of this module (1.0.0), I am seeing the following catalog error on all nodes:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter password at /etc/puppet/environments/staging/modules/sensu/manifests/api/config.pp:30

The sensu::api key is set to false in hiera on all but our sensu server. Removing the 'sensu_api_config' block from manifests/api/config.pp allows the catalog to be compiled.

Invalid symlink

The symlink for spec/fixtures/modules/ points to /Users/james/src/sensu-puppet.
I think this is related to .fixtures.yml file that contains this:
symlinks:
sensu: "#{source_dir}"

Question about how to use the sensu::check

Hi, i am trying to setup a sensu::check with customized attribute, but the format of the json file generated does not seem to work, not sure if this is even a support feature or i am doing something wrong

sensu::check { 'check_disk':
    command     => 'PATH=$PATH:/usr/lib64/nagios/plugins:/usr/lib/nagios/plugins check_disk  -w :::check_disk.disk.warning:::% -c :::check_disk.disk.critial:::%',
    handlers    => ["default", "email"],
    interval    => 10,
    config      => {'disk' => { warning => 70,
                                critial => 90,
                              }
                   }  }

basically i want to for each node, passing in a different values for warning and critical. but the json file generated from above code looks like

cat check_disk.json
{
  "check_disk": {
    "disk": {
      "warning": "70",
      "critial": "90"
    }
  }
}

but it needs to be like following for the attribute to read correctly

cat check_disk.json
{
  "client": {
    "disk": {
      "warning": "70",
      "critial": "90"
    }
  }
}

Am i doing something wrong? Thanks

Ability to add additional client / check configuration in Check type.

Sensu Puppet types & providers need the ability to specify both client side check configuration as well as the ability to send data to the handler when events are produced.

Check configuration
This allows the Type to specify information which can be used in command token substitution for checks. Reasoning being that the check can be generic and reusable across all hosts. The variables in the check are configured on a client-by-client basis.

Example - Client Check Configuration

kafka_topics.json
{
  "kafka": {
    "topics": ["topic1", "topic2", "topic3"]
  }
}

check_kafka_topics.json
{
  "checks": {
    "kafka_topics": {
      "subscribers": [
        "kafka"
      ],
      "handlers": [
        "pagerduty",
        "sendgrid"
      ],
      "command": "/etc/sensu/plugins/check_kafka -w 30 -c 60 --topics :::kafka.topics:::",
      "interval": 60,
      "standalone": "true"
    }
  }
}

Additional Check Metadata
All JSON values configured in the check is sent to the Sensu server / handler when an event is triggered. Using this feature clients can configure overrides as well as send additional metadata to with event for use in handlers. In this example, I override the email address to send the alert to in the 'sendgrid' handler instead of the default email address. The event also contains a URL to the wiki on how to fix the issue. The puppet module should allow me to specify 'check level' additional JSON values to send to the handler so I can use it in my custom handler code..

Example - Additional check metadata sent to Sensu handlers

namenode_alive.json
{
  "checks": {
    "namenode_alive": {
      "runbook": "https://mywiki/namenode_alerts/#NameNodeprocessdownalert",
      "sendgrid": {
        "mail_to": "[email protected]"
      }
    }
  }
}

$releasever in yum only works on redhat

The use of $releasever variable only works for RedHat systems due to the fact the URL only resolves to 6 rather than 6, 6.1, 6.2, etc...

Whilst strictly speaking this is a result of the repo URL it none the less causes the module to fail.

Execution of '/usr/bin/yum -d 0 -e 0 -y install sensu' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: sensu. Please verify its path and try again
Error: /Stage[main]/Sensu::Package/Package[sensu]/ensure: change from absent to latest failed: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y install sensu' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: sensu. Please verify its path and try again

When 6 is used

curl http://repos.sensuapp.org/yum/el/6/x86_64/repodata/repomd.xml
<?xml version="1.0" encoding="UTF-8"?>
<repomd xmlns="http://linux.duke.edu/metadata/repo">
  <data type="other">
    <location href="repodata/other.xml.gz"/>
    <checksum type="sha">45162b1d49c211c7bf4c1116ad14a4a210c4a84b</checksum>
    <timestamp>1396913938</timestamp>
    <open-checksum type="sha">b248e1f50f9c54acebfb2034debcaa4e80829c03</open-checksum>
  </data>
  <data type="filelists">
    <location href="repodata/filelists.xml.gz"/>
    <checksum type="sha">fd7744ce0d284cff67a16d250be2ec87d08609ca</checksum>
    <timestamp>1396913938</timestamp>
    <open-checksum type="sha">b2fbc4853116dfadf5b597811bb2778a9d157427</open-checksum>
  </data>
  <data type="primary">
    <location href="repodata/primary.xml.gz"/>
    <checksum type="sha">8ac4bdcce4c02efd4853e58214b1cd4e4566dbb6</checksum>
    <timestamp>1396913938</timestamp>
    <open-checksum type="sha">3439e7daf37aa3f4a220c35552b20b0e1f967e77</open-checksum>
  </data>
</repomd>

When 6.4 is used

curl http://repos.sensuapp.org/yum/el/6.4/x86_64/repodata/repomd.xml
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>yum/el/6.4/x86_64/repodata/repomd.xml</Key><RequestId>14567A6662157CAE</RequestId><HostId>mOxDE9AgxjVobedrnHK5MAneDh/j2tTA6izfGm0OfYjA6NUXyz7ncbyn8frBWwhWODvRGTBLzCA=</HostId></Error>

Not sure exactly what happens but RedHat appears to use "6Server" (I guess the non numeric 'Server' is stripped out).

python -c 'import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)'  
Loaded plugins: product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
{'arch': 'ia32e',
 'basearch': 'x86_64',
 'releasever': '6Server',
 'uuid': '18475024-b0d1-489d-8119-41d4bdd60777'}

Whereas CentOS and Scientific Linux use 6.x

python -c 'import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)'                                                                                                                                                                        
Loaded plugins: priorities
{'arch': 'ia32e',
 'basearch': 'x86_64',
 'releasever': '6.5',
 'uuid': '1f7f3ca9-6b3e-43a8-9a7a-a0de7de6a5fd'}

Error: Must pass rabbitmq_password to Class[Sensu]

I am trying to provision Sensu on vagrant box built with veewee (CentOS 6.3 minimal).

With librarian-puppet I get the modules apt, redis, rabbitmq and sensu.

The relevant part in the Vagrantfile looks like

...
config.vm.host_name = "sensu-sandbox"
config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "puppet/manifests"
    puppet.manifest_file  = "main.pp"
end
...

And my main.pp looks like this:

node "sensu-sandbox" { 
  include sensu
  sensu { "localhost":
    rabbitmq_password => "sensupass",
    server => true
  }
}

The provisioning run ends with the following error message:

"Error: Must pass rabbitmq_password to Class[Sensu] at /tmp/vagrant-puppet/manifests/main.pp:3 on node sensu-sandbox"

I just don't get it ... While googling I found some pages suggesting to put the include statement at the end, but then I will end up with the following error message:

"Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type sensu at /tmp/vagrant-puppet/manifests/main.pp:6 on node sensu-sandbox"

I get the same error when leaving out the include statement like in the README.

Any ideas what the problem could be?

Exported resources are no longer needed

For checks, I suppose the use of exported resources is no longer needed since checks only need to be defined on the server now. Doesn't seem difficult to do this, leaving this issue here anyway while I try some possible fixes.

handler hash ordering causing unneeded changes

Notice: /Stage[main]/role_sensu::Server/Sensu::Handler[relay]/Sensu_handler[relay]/socket: socket changed {'port' => '2003', 'socket' => 'carbon.hostedgraphite.com'} to '{"socket"=>"carbon.hostedgraphite.com", "port"=>2003}'

I believe this is caused by the handler type taking a hash for the socket attribute. Due to the non-deterministic ordering of the hash retrieval you see frequent 'changes' where no actual change occurs. This causes the puppet enterprise dashboard to permanently list the node as recently changed.

This should be fixable by sorting the socket hash before using it within the json.

Invalid parameter socket on sensu::handler definition

I'm running sensu-puppet at version v0.7.6 with puppet v2.7.23. This is using on CentOS 6.4 running Ruby 1.8.7.

If I define a handler like so:

sensu::handler { 'default':
  command => '/bin/echo > /dev/null',
}

When I run puppet agent --test I get:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter socket at /etc/puppet/modules/sensu/manifests/handler.pp:71 on node my.node.com

Commenting out the two lines in the file that make reference to the socket parameter resolves the problem. That's fine for me as I'm not piping anything to a tcp or udp socket, but that obviously wouldn't make a very good pull request.

Config json files are empty (only if I run puppet from server)

Hi,

I've a weird issue. I'm using sensu-puppet to install and configure my sensu clients. If I run the manifest locally, everything works as I expect.

puppet apply --debug -d --modulepath=/path/to/modules site.pp

But when I run the same code from the server using:

puppet agent --test --debug

The client.json and rabbitmq.json are created but empty. All the other things are ok: The sensu package is installed, the cert files and checks files are in place.

Looking into the log messages, the main difference I can see is this missing line (when I running puppet as an agent):

/Stage[main]/Sensu::Client/Sensu_client_config[myserver.ec2.internal]/notify: subscribes to Service[sensu-client]

Any idea about what's going on here ?

Thanks in advance!

Dependency cycle when using sensu::handler in the same catalogue as sensu server

I am getting the following error from the puppet agent run on the host which is my sensu server.

        Could not apply complete catalog: Found 1 dependency cycle:
        (Anchor[sensu::end] => Class[Sensu] => Class[Sensu_config::Handler::Pagerduty] => Sensu::Handler[pagerduty] => Sensu_handler[pagerduty] => Service[sensu-server] => Class[Sensu::Server::Service] => Class[Sensu::Dashboard::Service] => Service[sensu-dashboard] => Class[Sensu::Dashboard::Service] => Anchor[sensu::end])

The following is the relevant configuration on this host:

class sensu_config::server {
...
  class { 'sensu':
    rabbitmq_user      => $rabbitmq_user,
    rabbitmq_password  => $rabbitmq_password,
    rabbitmq_vhost     => $rabbitmq_vhost,
    rabbitmq_host      => $rabbitmq_host,
    rabbitmq_port      => $rabbitmq_port,
    subscriptions      => ["${environment}","${role}"],
    server            => true,
    client            => false,
    dashboard         => true,
    api               => true,
    use_embedded_ruby => true,
    manage_services   => true,
    require => [ Class['sensu_config::server::redis'],
                 Class['sensu_config::server::rabbitmq']]
  }
class sensu_config::handler::pagerduty {
...
  sensu::handler { 'pagerduty':
    command => "${::sensu_config::handlers_path}/pagerduty.rb",
    config => {
      'api_key' => hiera('pagerduty::api_key', '12345'),
    },
    require => File["${::sensu_config::handlers_path}/pagerduty.rb"]
  }

This happens for any handler that I specify. Not specifying any handlers results in no errors.

After updating/creating a check, puppet will not refresh sensu-client reliably.

After defining a new or modifying an existing sensu::check puppet will not reliably restart sensu-client. This seems pretty random. I'll update a check within an inherited class and then watch the puppet runs on applied nodes only to see maybe half of the nodes get sensu-client restarted, while the other half nothing happens.

I have the latest sensu-puppet module updates applied and am running Puppet 2.7.23

Invalid parameter safe_mode

One my latest librarian-puppet update my catalogue failed to compile on the server with the following error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter safe_mode at /etc/puppet/modules/sensu/manifests/client.pp:32 on node ip-10-0-1-60.

When I comment out safe_mode it works again:

sensu_client_config { $::fqdn:
ensure => $ensure,
client_name => $client_name,
address => $address,
subscriptions => $subscriptions,

safe_mode => $safe_mode,

}

I'm running puppet 3.1.0 on Amazon Linux

Getting class sensu::repo working with amazon linux

A (possibly hacky) way of getting sensu-puppet to work with amazon linux without screwing up any other flavor of linux that facter says is 'Linux' might be:
sensu/manifests/repo.pp, line 23, add a case like:

'Linux': {
  if $::kernelrelease =~ /amzn(\d+)\./ {
    class { 'sensu::repo::yum': ensure => $ensure }
  }
}

client key/values?

I can't tell from the docs, but can I define arbitrary key/values at a client level with this module?

checks: removing type => metric doesn't remove it from the config json

I just had to change a bunch of services from type: metric to non metric.

  1. If you just remove the line in the DSL specifying the type => metric, I'd expect the type: metric to go away in the config file. It doesn't.
  2. Are there any other types? Is there any reason that the doc in the module doesn't specify that the option is either undef or metric?
  3. In general, i'm surprised that the json files generated for checks and handlers aren't purged before updated...

Service['sensu-client'] doesn't get refreshed when checks are purged

We do a good job notifying the service when checks are modified or added (https://github.com/sensu/sensu-puppet/blob/master/manifests/config.pp#L40)

But the /etc/sensu/conf.d/checks folder does not notify, nor does the sensu-client service subscribe to this folder.

This means when standalone checks are purged (IMHO it should purge by default), the client is not reloaded.

I've done:

    File['/etc/sensu/conf.d/checks/'] ~> Service['sensu-client']

As a quick fix in my manifests.

I am willing to PR this if you see this as a bug. (I do)

Should I just add an additional subscribe here?
https://github.com/sensu/sensu-puppet/blob/master/manifests/client/service.pp#L28

Seems like this is a pretty normal thing for happen if you are doing standalone checks and purging.

Idempotence problems with sensu_dashboard_config

When the dashboard user and password are set to '' (empty string), the sensu_dashboard_config resource displays the following:

Notice: /Stage[main]/Sensu::Dashboard::Config/Sensu_dashboard_config[sanitized.fqdn]/user: user changed '' to ''

I'm setting these to blank because I want to proxy to the dashboard using Apache and our internal SSO.

crashing check.pp and api/config.pp

I've been trying to configure sensu-puppet v1.0.0 and I found some issues regarding this two files.

check.pp

timeout             => $timeout,
aggregate           => $aggregate,
handle              => $handle,
publish             => $publish,

Error:

  • Invalid parameter timeout
  • Invalid parameter aggregate
  • Invalid parameter handle
  • Invalid parameter publish

api/config.pp

sensu::api_user
sensu::api_password

Error:

  • Invalid parameter user
  • Invalid parameter password

Although I see that the types are correct and they have the attributes correctly defined.

Disable dashboard user/password

Is there a way to disable dashboard user/password. i am trying to setup ldap for sensu dashboard, from the IRC people suggest using apache/nginx ldap settings which i did. but now i need to turn off dashboard authentication from sensu. I can do it manually by remove following 2 line completely. But the module does not allow me to do that yet.

     "dashboard": {
       "user": "admin",  #REMOVE this line completely
       "password": "secret",  #REMOVE this line completely
       "host": "10.147.197.54",
       "port": 8080
     }

I tried to set the value to undef but it didnt work either.

  class { 'sensu':
    server              => true,
    dashboard_user      => undef,
    dashboard_password  => undef,
  }

i tried to modify the provider/sensu_dashboard_config/json.rb

def password=(value)
  conf['dashboard']['password'] = value if value
end

any other suggestion? Thanks

Filter definition requires a client subscription

When defining a filter as follows:

 sensu::filter { 'keepalive_failures':
    negate        => false,
    attributes    => { }
  }

Puppet keeps failing with the error:

Error: Could not find dependent Sensu_client_subscription[keepalive_failures] for File[/etc/sensu/conf.d/filters/keepalive_failures.json]

Why does a filter definition require a sensu client subscription?

Could not evaluate: No ability to determine if sensu_clean_config exists

Sensu-puppet module throws this error on a subset of instances, unsure of the cause.

err Could not evaluate: No ability to determine if sensu_clean_config exists /Stage[main]/Sensu::Package/Sensu_clean_config[] /etc/puppet/modules/sensu/manifests/package.pp 47 2012-06-14 12:01 PDT
err Could not evaluate: No ability to determine if sensu_client_config exists /Stage[main]//Node[]/Sensu::Client[]/Sensu_client_config[] /etc/puppet/modules/sensu/manifests/client.pp 29 2012-06-14 12:01 PDT
err Could not evaluate: No ability to determine if sensu_rabbitmq_config exists /Stage[main]//Node[]/Sensu::Client[]/Sensu::Rabbitmq[client]/Sensu_rabbitmq_config[] /etc/puppet/modules/sensu/manifests/rabbitmq.pp 66 2012-06-14 12:01 PDT
err Could not evaluate: No ability to determine if sensu_check_config exists /Stage[main]//Node[]/Sensu::Check[check_disk]/Sensu_check_config[check_disk] /etc/puppet/modules/sensu/manifests/check.pp 22 2012-06-14 12:01 PDT
warning Skipping because of failed dependencies /Stage[main]//Node[]/Sensu::Client[]/Service[sensu-client] /etc/puppet/modules/sensu/manifests/client.pp 38 2012-06-14 12:01 PDT
notice Dependency Sensu_client_config[] has failures: true /Stage[main]//Node[]/Sensu::Client[]/Service[sensu-client] /etc/puppet/modules/sensu/manifests/client.pp 38 2012-06-14 12:01 PDT
notice Dependency Sensu_rabbitmq_config[] has failures: true /Stage[main]//Node[]/Sensu::Client[]/Service[sensu-client] /etc/puppet/modules/sensu/manifests/client.pp 38 2012-06-14 12:01 PDT
notice Finished catalog run in 20.37 seconds Puppet 2012-06-14 12:01 PDT

Handler for udp type not created correctly

Using sensu-puppet v0.7.5. I'm defining a UDP handler like this:

    sensu::handler {'logstash-udp':
        type => 'udp',
        config => {
            socket => {
                host => "logstash_host",
                port => 4242,
            },
        },
    }

This is the generated config; sensu-server won't start with it.

{
    "logstash-udp": {
        "socket": {
            "port": "4242",
            "host": "logstash_host"
        }
    },
    "handlers": {
        "logstash-udp": {
            "severities": [
                "ok",
                "warning",
                "critical",
                "unknown"
            ],
            "type": "udp",
            "command": null
        }
    }
}

The error is

{
    "timestamp": "2013-09-10T19:52:36.505194+0000",
    "level": "fatal",
    "message": "invalid settings",
    "reason": "handler is missing socket hash",
    "handler": {
        "severities": [
            "ok",
            "warning",
            "critical",
            "unknown"
        ],
        "type": "udp",
        "command": null,
        "name": "logstash-udp"
    }
}

This configuration does work:

{
    "handlers": {
        "logstash-udp": {
            "severities": [
                "ok",
                "warning",
                "critical",
                "unknown"
            ],
            "type": "udp",
            "command": null,
            "socket": {
                "port": 4242,
                "host": "localhost"
            }
        }
    }
}

sensu::check notifies the server even when not running the service

https://github.com/sensu/sensu-puppet/blob/master/manifests/check.pp#L119 will notify the sensu::server::service class whenever a check changes.

The sensu::server::service class will correctly set ensure and enable but when notifying the class puppet will log confusing lines:

Notice: /Stage[main]/Sensu::Server::Service/Service[sensu-server]: Triggered 'refresh' from 1 events

when in fact what it's doing is the right thing, it notices that the service is stopped and does not restart it:

Debug: Executing '/etc/init.d/sensu-api status'
Debug: Service[sensu-server](provider=upstart): Could not find sensu-server.conf in /etc/init
Debug: Service[sensu-server](provider=upstart): Could not find sensu-server.conf in /etc/init.d
Debug: Service[sensu-server](provider=upstart): Could not find sensu-server in /etc/init
Debug: Executing '/etc/init.d/sensu-server status'
Debug: Executing '/etc/init.d/sensu-server status'
Debug: /Stage[main]/Sensu::Server::Service/Service[sensu-server]: Skipping restart; service is not running
Notice: /Stage[main]/Sensu::Server::Service/Service[sensu-server]: Triggered 'refresh' from 1 events

To avoid the confusing message I think the server::service class should only be notified if $sensu::server is true

issue with running the sensu module, Invalid resource type sensu at /root/p_sensu/site.pp:4 on node

I am trying to use Puppetfile to download and install sensu server but got the following error, any help is greatly appreciated. thanks

Debug: importing '/root/p_sensu/modules/sensu/manifests/init.pp' in environment production Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type sensu at /root/p_sensu/site.pp:4 on node myvmname

The command i ran was

cd /root/p_sensu/ ; puppet apply --modulepath=/root/p_sensu/modules site.pp --ignorecache --verbose --noop --debug

i do see that the modules are in the right path

[root@chao-test8 p_sensu]# ls /root/p_sensu/modules/
apt gcc rabbitmq redis sensu stdlib wget

sensu::check is trying to escape double quotes passed in a part of the check command

I have a check command that needs double quotes around a string as part of the check. Unless I'm doing something wrong, sensu::check is trying to escape the double quotes and as a result my check definition has " when it should simply have ".

The following is an example of what's applied to a node:
$string = "'"redis":{"connected":true}'"
notify {$string:} # Added for debug purposes.
sensu::check .....
command => "PATH=$PATH:/usr/lib64/nagios/plugins check_http -H myserver.domain -p 4567 -u /info -s ${string}"

When running puppet on the client I get this:
notice: '"redis":{"connected":true}' # My debug message came out perfect.

The command line inside of my check ends up looking like this:
"command": "PATH=$PATH:/usr/lib64/nagios/plugins check_http -H myserver.domain -p 4567 -u /info -s '"redis":{"connected":true}'",

As a result the check fails because it's looking for a string that literally has " as part of it. I looked though the module, but I'm not seeing where this escaping is actually happening so I have no idea where to start for crafting a pull request.

Subscriptions don't have a require on the sensu package

It may be fixed with a recent code change, and I'll test with 1.0 from the forge, but saying:

sensu::subscription { 'webserver':}

was not always able to work, since it depended on /etc/sensu/conf.d existing. Sometimes that comes before the actual module is intialized, and Package['sensu'] hasn't been installed to create that dir.

Puppet 3.1.0 shows warning due to Puppet.features.rubygems? require in json.rb

Running the sensu puppet module on puppet 3.1.0-1puppetlabs1 and ruby 1.8.7.352-2ubuntu1.1 , puppet generates a warning message on every run on a client which includes any sensu class:

Warning: Puppet.features.rubygems? is deprecated. Require rubygems in your application's entry point if you need it.
   (at /usr/lib/ruby/vendor_ruby/puppet/util/feature.rb:17:in `add')

I appear to have resolved this by removing the first line of all the json.rb, which tests for Puppet.features.rubygems?:

require 'rubygems' if RUBY_VERSION < '1.9.0' && Puppet.features.rubygems?

Removing this doesn't appear to have any ill effects. However, I haven't tested this against other puppet/ruby combinations, so something could break on those. I'm not sure if this is the best way of solving this problem, or if there's a better way of testing for rubygems that works on all puppet versions.

SSL & rabbitmq config..?

There's no mention of SSL in the readme, or how to use the module to configure it.

Might be handy to have that in the example.

If you're not going to use SSL by default in the module, you should default to port 5672..

It might also be handy to give a pointer to set up rabbitmq with the puppetlabs-rabbitmq module. Maybe even just offer a manifest in the module that does the right things, assuming the module is installed..

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.