• /
  • EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Containerized private minion (CPM) configuration

Importante

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:

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 within docker 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:

  1. Create a directory containing a package.json, following the npm official guidelines, in the directory's root. Anything contained in the dependencies 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.

  2. Once you create the custom modules directory and the package.json you can apply it to your CPM for Docker and Kubernetes.

  3. 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.

Cuidado

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:

  1. Create a directory.

  2. 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:

  1. 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

Cuidado

User-defined environment variables are not sanitized from logs. For sensitive information, consider using the secure credentials feature.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.