Server Metrics in Puppet

Configuring Puppet Server👩‍💻

Puppet Server uses Puppet's configuration files, which include many settings in Puppet.conf.But Puppet Server handles some puppet.conf settings differently. We must know these differences. The puppet server automatically loads the Puppet.conf settings in the configuration of the files' server and main section. Puppet Server uses the values in the server section but is not present; it uses the values in the main section.

Puppet Server distinct the following puppet.conf settings:

Configuration Files

Configuration files and settings of Puppet Server are mainly in the conf.d directory. The conf.d directory by default is present at /etc/puppetlabs/pupperserver/conf.d. The format of these configuration files is HOCON, Which is similar to the basic structure of JSON but is readable.

When we start, the Puppet server reads .conf files present in the conf.d directory. To implement these changes, we are required to restart the Puppet Server. The settings and files in conf.d directory contains are :

🚩global.conf: This file stores global configuration settings for Puppet Server.

Example:

global: {
    logging-config: /etc/puppetlabs/puppetserver/logback.xml
}

🚩web-routes.conf: This file arranges the Puppet Server web-router-service; this service fixes the mount points for the web application of Puppet Server.

Example:

# Composing the mount points for the web apps.
web-router-service: {
    # These two should not be modified, as we know that the Puppet 4 agent expects them to
    # be mounted at these particular paths.
    "puppetlabs.services.ca.certificate-authority-service/certificate-authority-service": "/puppet-ca"
    "puppetlabs.services.master.master-service/master-service": "/puppet"


    # This manages the mount point for the Puppet administration API.
    "puppetlabs.services.puppet-admin.puppet-admin-service/puppet-admin-service": "/puppet-admin-api"


    # This manages the mount point for the status API
    "puppetlabs.trapperkeeper.services.status.status-service/status-service": "/status"


    # This manages the mount point for the metrics API
    "puppetlabs.trapperkeeper.services.metrics.metrics-service/metrics-webservice": "/metrics"
}

🚩auth.conf: This file stores the rules for authorizing access to HTTP API endpoints of Puppet Server. 

Example:

authorization: {
    version: 1
    rules: [
        {
            match-request: {
                path: "^/new_path/([^/]+)$"
                type: regex
                method: get
            }
            allow: [ n1, n2, n3, {extensions:{ext_shortname1: val1, ext_shortname2: val2}} ]
            sort-order: 1
            name: "user-specific new_path"
        },
        {
            match-request: {
                path: "/second_path"
                type: path
            }
            allow-unauthenticated: true
            sort-order: 2
            name: "second_path"
        },
    ]
}

🚩ca.conf: This file design setting is for the Certificate Authority(CA) service of Puppet Server.

Using and extending Puppet Server🙇‍♀️

Subcommands

We are given multiple CLI commands to help explore and debug the Puppet Server. Many commands are similar to the ones we have used in Ruby environments like ruby, gem, and irb. Subcommands Provided to us are given below:

✍️gem: This subcommand Installs and manages gems accessible only to the Puppet server and isolated from Ruby(system). 

Example:

$ puppetserver gem install pry --no-ri --no-rdoc

✍️ca: available actions in ca subcommands are:

• generates: this generates a new certificate signed by the ca
   
• import: this imports the certs, CRLs, and CA's key.
   
• clean: to obtain certificates, these clean files from the CA
   
• revoke: this revokes the particularly given certificates
   
• setup: create an intermediate and root signing CA for Puppet Server
   
• purge: From CA CRL, this command removes all the duplicate entries.
   
• migrate: This command migrates the current content of the CA directory to /etc/puppetlabs/puppetserver/ca. 
   
• List: this command make lists of all the request for certificates

Example:

puppetserver ca <action> [options]

✍️irb: Similar to the ruby subcommand, irb helps experiment in an interactive environment with any of the installed gems and the Puppet.

$ puppetserver irb
irb(main):001:0> require 'puppet'
=> true
irb(main):002:0> puts Puppet[:certificatename]
centos6-64.localdomain
=> nil

✍️ruby: this subcommand runs codes in the JRuby interpreter of Puppet Server. This is useful when we experiment with gems installed through the puppetserver gem.

Example:

$ puppetserver ruby -e "require 'puppet'; puts Puppet[:certificatename]"

Monitoring Puppet Server metrics📝

Puppet Server metrics trace multiple advanced performance and health metrics; this whole takes advantage of the metrics API. We can trace server metrics using the following:

• HTTP client metrics
   
• Customizable, Grafana instances, and networked Graphite
   
• Metrics API endpoints

To anticipate Puppet Server metrics, we can:

• Use the module named puppet-operational-dashboards.
   
• Export this to a Graphite installation. The module named grafanadash helps us to set up a Graphite instance, visualize the output with Grafana and configure Puppet Server for exporting to it.
   
• The module named puppet-operational-dashboards is suggested for FOSS users, as it is an easier way to visualize and save Puppet Server metrics. 

Note: A Graphite setup is deeply modified and can report most Puppet Server metrics on demand. 

HTTP Client Metrics🔥

HTTP client metrics in the Puppet server allow users to measure how long it takes for the puppet server to make requests and respond to other services, like PuppetDB.

Configuring

• HTTP client metrics by default are enabled, but they can also be disabled by setting metrics-enabled to false in the section http-client of puperserver.conf.
   
• All these metrics depend on the server-id settings in the metrics section of puppetserver.conf.
   
• This defaults to localhost. Localhost can gather metrics and modify these settings to something unique to ignore name collisions in metrics while exporting to an external tool like Graphite.
   
• All the data is available through the status API endpoint at https://<SERVER HOSTNAME>:8140/status/v1/services/master?level=debug.
   
• The puppet server inputs a keyword http-clientt-metrics in the map.
   
• If the Puppet server has not given any requests yet or metrics are not enabled, this array will be empty, like "http-client-metrics" :[ ].

Example metrics output

"http-client-metrics": [
  {
    "aggregate": 407,
    "count": 1,
    "mean": 407,
    "mymetric-id": [
      "mydb",
      "facts",
      "find"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.facts.find.full-response"
  },
  {
    "aggregate": 66,
    "count": 1,
    "mean": 66,
    "mymetric-id": [
      "mydb",
      "command",
      "replace_facts"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.command.replace_facts.full-response"
  },
  {
    "aggregate": 60,
    "count": 2,
    "mean": 30,
    "mymetric-id": [
      "mydb",
      "resource",
      "Search"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.resource.search.full-response"
  },
  {
    "aggregate": 53,
    "count": 1,
    "mean": 53,
    "mymetric-id": [
      "mydb",
      "query"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.query.full-response"
  },
  {
    "aggregate": 22,
    "count": 1,
    "mean": 22,
    "mymetric-id": [
      "mydb",
      "command",
      "store_report"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.command.store_report.full-response"
  },
  {
    "aggregate": 16,
    "count": 1,
    "mean": 16,
    "mymetric-id": [
      "mydb",
      "command",
      "replace_catalog"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.mydb.command.replace_catalog.full-response"
  },
  {
    "aggregate": 2,
    "count": 1,
    "mean": 2,
    "mymetric-id": [
      "puppet",
      "report",
      "http"
    ],
    "metric-name": "puppetlabs.localhost.http-client.experimental.with-mymetric-id.puppet.report.http.full-response"
  }
],

Frequently Asked Questions

What is a Puppet?

It is a tool that helps manage and automate the configuration of servers.

What is Puppet code?

Puppet code is an easy way to programmatically describe what configurations should be in place on the operating systems & applications that you want to manage.

What is the Puppet platform?

Puppet is made up of several packages. These packages include "puppetdb", "puppetserver", and "puppet-agent" — which includes "Hiera" and "Facter". Together these are called the Puppet platform.

What is DevOps?

DevOps is a collection of cultural ideas, operational procedures, and technical resources that rapidly enhance an organization's ability to deliver products and services.

What language is Puppet built on?

Puppet is built using Ruby's domain-specific language.

Conclusion

In this blog, we explored the server metrics in Puppet and learned about Puppet servers. We further discussed using and extending the puppet server and monitoring puppet server metrics.

We hope this blog has helped you enhance your knowledge of Server metrics in Puppet and if you want to learn more, check out our articles here.

You can refer to other similar articles as well.

• Developer Information in Puppet
   
• Configuration Management 
   
• Life Cycle of Puppet run
   
• Overview of Custom Facts in Puppet
  
  Check out this problem - Find Duplicate In Array
   

Refer to our guided paths on Coding Ninjas Studio to learn more about DSA, Competitive Programming, JavaScript, System Design, etc. Enroll in our courses and refer to the mock test and problems available. Also, look at the interview experiences for placement preparations. 

Happy Learning Ninja! 🥷