Introduction
We assume that you already have an idea about the PuppetDb above. If not, then let us summarize it for you.
Puppet is a software configuration management and deployment tool that is open source. It is most commonly used on Linux and Windows to pull strings simultaneously on multiple application servers.
So in this article, you will learn about the Puppet Troubleshooting guide and understand its internals.
So let's begin!!
Troubleshooting and support
PDB Architectural Overview
In the PDB, data passes via four parts. It is transferred from the terminus to a filesystem queue, which is later retrieved by the program, entered into the database, and stored there. The endpoint, the queue management program and the database often reside on three different machines.
Terminus
The terminus resides on the Puppet Server and redirects agent data to PDB in the form of "commands". PDB has four commands, as described in the command's documentation.
Message Queue
Currently, all commands transmitted from the terminal to PDB are delayed to a filesystem queue for processing at a later time, when they will be added to the database in roughly the same order as they were received.
Deferred messages were formerly saved in ActiveMQ, which combined them in vardir/opaque mq's binary files. Now that PDB uses stockpile to store messages, which saves each message as a regular file inside vardir/stockpile/cmd/q, it is possible to manually remove queue commands when PDB is not in use. However, it is unlikely to be essential.
The message names are made to provide some information about their content. For ex:
stockpile/cmd/q/167-1478013718598_facts_5_somehost.json
Contains a version 5 "replace facts" instruction received for certname "somehost" at 1478013718598 milliseconds after the epoch (1970-01-01 UTC). The command files are plain text JSON representations of the incoming commands, as implied by the.json extension, and the 167 is a stockpile sequence number.
This setup can quickly examine the queue using standard filesystem commands. For instance, something similar to this.
find cmd/q | grep -cE '^cmd/q/[0-9]+-[0-9]+_facts_'should provide a count of "replace facts" commands in the queue, and something like this:
find cmd/q -printf "%s %p\n" | sort -n | tailshould list the largest commands in the queue.
Note that filesystem constraints may require changing the certname. At the moment, doing so entails changing the characters "","/", ":", and 0 to "-" and trimming the certname so that the UTF-8 encoding never goes over around 255 characters. An underscore and a hash of the complete certname will come after a truncated certname. For instance:
stockpile/cmd/q/167-1478013718598_facts_5_LONGNAME_HASH.jsonAs a result, PDB anticipates that the vardir filesystem will be able to accommodate all of your certnames, UTF-8 encoded, as filenames, with the obvious exception of any characters that, as previously noted, are transformed to dashes.
Although the actual queue message filename lengths will depend on your certnames, PDB expects the vardir filesystem to support filenames up to a maximum of 255 bytes. Filesystems like ext4 and xfs need to function properly.
You could also see some files in the queue with names that start with "tmp-" in addition to the message files. You can disregard these because they are merely temporary files generated during message transmission. They ought to be highly brief under normal conditions, but if they were to build up (likely a sign of another issue), PDB would try to clean them up when it restarted.
Command processing
The configuration-specified number of threads and PDB process the queue simultaneously. Different commands are handled according to their type:
- store report: These commands are inexpensive, mainly inserting a row in the reports table.
- replace catalog: When a replace catalogue command is requested, PDB will first see if the node's database already contains a more recent catalogue for that node. If so, the catalogue is thrown away and nothing is done. If not, PDB will do a diff between the catalogue that is currently in use and the catalogue that is stored in the database, inserting only the resources and edges that have changed.
- replace facts: As key-value relationships between "paths" and "values," PDB stores facts. Value refers to the leaf value itself, and "path" refers to a particular path leading from a tree's root (such as a structured fact) to a leaf value. Every fact is conceptually stored as a tree. to demonstrate the point.
"foo" => "bar"is stored as
"foo" => "bar"while the fact
"foo" => {"a" => "bar", "b" => "baz"}is stored as
"foo#~a" => "bar"
"foo#~b" => "baz"For the array case, the fact
"foo" => ["bar", "baz"]is stored as
"foo#~0" => "bar"
"foo#~1" => "baz"For larger structures, the same guidelines apply recursively. PDB will check the fact at hand against the pathways and values in the database when it receives a replace facts command. It will add any new paths/values that are necessary and remove any invalidated pairings.
deactivate node: The deactivate node command is unlikely to be the cause of performance problems because it merely updates a field in the certnames table.
Database
PostgreSQL is used by PDB. The easiest method to become comfortable with the schema is to create an ERD diagram from your database and conduct your own research using the psql interactive terminal on an active instance. For this, DB Visualizer is a fantastic tool. Additionally, the PDB team is accessible to address any queries on the freenode channels #puppet and #puppet-dev as well as on the mailing list.
26+ registered 
