How to improve your AWS EC2 memory monitoring. Since AWS CloudWatch does not have access to your OS, some monitoring metrics may be missing,...
You are here
Extending Puppet into your Monitoring Environment
Puppet Labs helps companies automate their infrastructure deployments with ease and efficiency. Puppet provides a declarative consistency across server, virtual machine and container builds. The sort of consistency that Puppet offers is the same sort of consistency you need when monitoring hundreds or thousands of compute instances.
Opsview has introduced the Opsview Puppet Module, which automatically registers compute instances for monitoring within Opsview Monitor. It facilitates the creation, synchronization and update of the monitored system in the Opsview configuration using Opsview’s REST API.
Puppet is a powerful configuration management and automation framework, but to integrate systems like Opsview, it often requires many hours of scripting trial and error to get it working. So it’s with great pride that Opsview has released a module for its customers to easily integrate with Puppet. Note that we also have similar integration modules available for Ansible and Chef. The Opsview Puppet Module includes declaration for all the core Opsview operations. This includes Host groups, Hosts, Users/Roles , Service Checks and even Business Service Monitoring (Application Dependency Monitoring and Availability).
Let’s demonstrate how to automate a host deployment with Opsview Monitor and the Opsview Puppet Module.
As a preface, we assume the following have been completed:
- Puppet Master is currently setup and deployed.
- Opsview Master is running on version 5.x.
- REST API user account has configure hosts and reloads access.
- Opsview Puppet Module has been installed from Puppet Forge.
We’ll begin by first configuring the Opsview Puppet Module to talk to the Opsview Master Server via the Opsview REST API. This enables Puppet to communicate with the Opsview Monitor server.
Fig 1: File to be changed to add in settings - /etc/puppet/opsview.conf
Fig 2: File edited with Opsview Master URL and username/password for Web UI User
To test this, we execute puppet resources –types to show all of the Opsview Components available to configure:
Fig 3: Opsview Puppet Module Resource Types
To view these, we execute puppet resource opsview_host to list all the hosts that the Opsview Monitor server is currently monitoring.
Fig 4: Command puppet resource opsview_host
Fig 5: Example.pp is a Puppet manifest file that includes new host information which will be added to Opsview Monitor
For our purposes, we edit example.pp which is a Puppet Manfifest file that defines the host properties of a host that Opsview is not currently monitoring. Note, the name of this host is example-host and was not seen when we ran puppet resources opsview_host.
Not shown in this demo, but another advanced feature of Opsview is BSM, our Business Service Monitoring capability. It ties applications and their service dependencies into an overall business service, like databases, apps and web servers that all work together to offer a single business service. These services could also be automatically generated by puppet using the puppet resource opsview_bsmservice and puppet resource opsview_bsmcomponent commands in the Puppet Manifest file.
Now we'll apply the configuration: puppet apply /etc/puppet/modules/opsview-puppet/examples/example.pp
Hopefully you’re using some sort of configuration management or automation in your monitoring environment already. If you aren’t, contact us for more information on how automating your monitoring environment ensures no systems go unmonitored.
Below is a video that demonstrates the integration discussed here.
More like this
Learn how to monitor network traffic with Juniper EX switch monitoring using sFlow collector and Opsview.
A guide on how to monitor Juniper EX switches using SNMP and Opsview.