Important
As of August 26, 2024, you can no longer create new monitors using legacy runtimes on public or private locations.
On October 22, 2024, we will end of life the containerized private minion (CPM) and the legacy synthetics runtime versions it supports. Please review our recommended migration steps to avoid degradation of your private location monitors.
This doc guides you through configuring your containerized private minion (CPM).
You can do the following to customize your CPMs:
- Use environment-variables to configure your containerized private minion.
- Set up custom modules for scripted API or scripted browser monitors.
- Preserve launch data with permanent data storage.
You may not modify any CPM files and New Relic is not liable for any modifications you make.
Configuration using environment variables
Environmental variables allow you to fine-tune the CPM configuration to meet your specific environmental and functional needs.
Guidelines for mounting volumes
All directories and files must be assigned group ownership as 3729
with read/write permissions. This ensures that the Runner, which uses uid: 1000
and gid: 3729
, has access to all the mounted volumes. However, the Minion can run as root (uid: 0
) or with any uid
between the range of [2000, 4000]
, inclusive. For more information, see running as non-root in Kubernetes or Docker.
Docker
- Directories are mounted onto a container as volumes by specifying a
-v
argument withindocker run
- For example,
docker run ... -v /path/to/src:/path/to/dest:rw
Kubernetes
- It is possible to add a directory onto a persistent volume (PV) by using
kubectl cp
. However, alternative approaches are supported as long as the file permissions are set appropriately. - For example,
kubectl cp /path/to/src <POD_NAME>:/path/to/dest
will add a directory onto each PV in the specified pod - Each PV must have a separate copy of the directories. For example, a cluster with n Minion replicas must have n PVs, each with their own copy of directories
- The directories and files must be added before the Minion boot-up, otherwise, the Minion must be restarted to detect the updates
Custom node modules
Custom node modules are exclusive to the CPM. They allow you to provide an arbitrary set of node modules, and make them available for scripted monitors in synthetic monitoring.
To set up the modules:
Create a directory containing a
package.json
, following the npm official guidelines, in the directory's root. Anything contained in thedependencies
field will be installed by the CPM at start and made available when running monitors on that private minion.Optionally, you can override the root level
package.json
with a Node.js version-specific directory. This allows a script to be updated per monitor runtime if a Node.js version of a runtime is no longer compatible with your dependencies. See an example of this below.Once you create the custom modules directory and the
package.json
you can apply it to your CPM for Docker and Kubernetes.Look at the CPM logs for
"... Initialization of Custom Modules ..."
to see if the modules were installed properly, or if there were any errors. The npm installation logs will be shown.
Now you can add "require('async');"
into the script of monitors you send to this private location.
Change package.json
for custom modules
You can also use Node.js modules along with local and hosted modules. To change the custom modules used by your CPM, modify package.json
and reboot the CPM. It will detect the change in configuration during the reboot, and then clean up and re-install.
Caution
Local modules: While your package.json
can include any local module, these modules must reside inside the tree under your custom module directory. If stored outside the tree, the initialization process will fail and you will see an error message in the docker logs after launching CPM.
Permanent data storage
CPM is a stateless application and does not preserve information from prior requests or sessions by default. However, you can preserve data between launches by enabling permanent data storage. For example, you can permanently set how the minion identifies itself (for example, Minion_ID
), and use it to associate that data with the exact minion that produced it.
To set permanent data storage on Docker:
Create a directory.
Launch the CPM, mounting the directory at
/var/lib/newrelic/synthetics
.Example:
bash$docker run ... -v /example-permanent-dir:/var/lib/newrelic/synthetics:rw ...
To set permanent data storage on Kubernetes:
Launch the CPM, setting a value for the
persistence.permanentData
configuration value either in the command line or in a YAML file during installation. The value should specify the subpath on your Minion's Persistent Volume where you want the data to be saved.Example:
bash$helm install ... --set persistence.permanentData=PERMANENT_DATA_SUBPATH ...
User-defined environment variables for scripted monitors
Containerized private minions let you configure environment variables for use in scripted monitors. These variables are hosted locally on the CPM and can be accessed via $env.USER_DEFINED_VARIABLES
. There are two ways to set user-defined variables: by mounting a JSON file or by supplying an environment variable to the CPM on launch. If both are provided, the CPM will use values provided from the environment only.
Accessing user-defined environment variables from scripts
To reference a configured user-defined environment variable, use the reserved $env.USER_DEFINED_VARIABLES
followed by the name of a given variable with dot notation.
For example, $env.USER_DEFINED_VARIABLES.MY_VARIABLE
Caution
User-defined environment variables are not sanitized from logs. For sensitive information, consider using the secure credentials feature.