Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

How to Use Command Line Tools to Administer APM

After you've installed the Address Pool Manager (APM) application, you can perform the following administration functions.

Address Pool Manager gives you two command line options for perform administrator tasks. You can either use the APM utility script (apm) or the Kubernetes Command Line tool to administer APM.

Access APM Utility Commands

Use the APM utility commands to perform administration functions.

You can use the APM utility script (apm) to administer the application and to access the CLI that you use to configure the address management functions. The Juniper APM installation places the utility script in /var/local/apm and creates a symbolic link to the script in /usr/local/bin/apm.

You can use the apm utility script (which uses the Kubernetes command line tool and Helm commands ) to do the following:

  • Create and delete objects.
  • Provide log access.
  • Conduct interactive sessions with pod containers.
  • Display the status of the APM objects.

Using the apm utility script simplifies many of your administrative duties. The script performs the tasks you need to manage APM, while masking the complexity of the kubectl command.

Table 1 lists the commands that you can invoke with the apm utility script and describes the action that occurs. Many of the individual commands have options that you can specify.

Table 1: APM Utility Script Commands
Name Action

sudo -E apm clean --context [context-name | multi-cluster-context-name] --docker --release software-release --dry-run --uninstall --cluster-repos

Clean up unneeded releases and Docker cache. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • log [error, warning, info, debug]—Adjusts the log level.

  • no-color—Prints messages without colors.

  • docker—Only cleans the local Docker cache, all other files remain.

  • release software-release—Specify a release to clean or clean all possible releases.

  • dry-run—Identifies releases and docker images for removal and prints them to console. This command does not actually clean any releases or the Docker cache.

  • uninstall—Uninstalls all APM materials from the disk. The command does not affect the running application.

  • cluster-repos—Clean the cluster repository of the clusters that have been removed.

apm cli --context [context-name | multi-cluster-context-name] [-p|--pipe]

Gives you access to the CLI that you can use to configure APM features.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • pipe—Allows you to pipe input into the command.

apm contexts [-o|--output json]

Displays the available contexts for control with APM.

This command offers the following options:

  • contexts—Lists the available contexts.

  • output json—Allows you to request the output in JSON format.

sudo -E apm db --context [context-name | multi-cluster-context-name] --workload-context workload-context-name

Provides access to the Redis database CLI. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The workload context name for which you want to attach to the shell of a particular subsystem. This option is only used for multiple geography setups.

apm db-info --context [context-name | multi-cluster-context-name] --workload-context workload-context-name

 Displays current state of APM’s database microservice including the current version, stateful set pods, and their roles.
Note: For a multiple geographically located setup, the apm db-info displays the redis roles for workload clusters.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The workload context name for which you want to display database information. This option is only used for multiple geography setups.

sudo -E apm db-switchover --context [context-name | multi-cluster-context-name] --workload-context workload-context-name

 Forces the primary database pod to switchover to an eligible backup database pod. To run this command, you need sudo privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The workload context name for which you want to attach to the shell of a particular subsystem. This option is only used for multiple geography setups.

Note:

db-switchover is a service disrupting event and you only use it with the upgrade procedure.

apm ip --context [context-name | multi-cluster-context-name] [-o| --output json --detail]

Displays the IP addresses of every service with an external IP address.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • output json—Allows you to request the output in JSON format.

  • detail—Displays detailed IP information.

Single geographically located setup use:sudo -E apm link --context context-name --version software-release --log info --no-color --from-running

Multiple geographically located setup use:

sudo -E apm link --context multi-cluster-context-name --version software-release --from-running --log info --no-color --workload-contexts workload-1-context-name workload-2-context-name

Links a cluster to a specific software version. To run this command, you need sudo root privileges.

This command offers the following options:

  • version software-release—Specify the software release to link to the cluster specific repository.

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-contexts workload-1-context-name workload-2-context-name—The two workload context names. Used with a multiple geographically located setup only. Enter the name of the context.

  • l, log [error, warning, info, debug]—Adjusts the log level.

  • no-color—Prints messages without colors.

  • from-running—Attempts to match the software releases of the running Address Pool Manager.

    The from-running option is used to recover the version and user settings from a running application deployment. This can help you recover a failed jump host or for synchronizing a network of jump hosts.
apm logs --logset logset-type --services services-names --context [context-name | multi-cluster-context-name] --workload-context workload-context-name --log info --follow --previous --nocolor

Displays logs for APM microservices. If you run the command without the services option, logs for the addrman, entman, and provman microservices are displayed.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The workload context name for which you want to attach to the shell of a particular subsystem. This option is only used for multiple geography setups.

  • logset logset-type—Used to indicate what type of microservice for which you want the logs displayed. This command has the following options:

    • apm

      —To display the addrman, entman, and provman microservices logs. If the logset option is not configured, the apmoption is the default operation and you can only see the logs for the above microservices.

    • apm-infra

      —To display the configserver, dbsync, mgmt and redis instances microservices logs.

  • services services-names—List the specific microservices for which you want the logs displayed. Logs are displayed chronologically.

  • l, log [error, warning, info, debug]—Adjusts the output log level.

  • nocolor—Disables colorized output.

  • f, follow—To follow the logs for all microservices.

  • p, previous—To view logs from previous container instances.

apm multi-cluster dbsync-stats --context multi-cluster-context-name

Displays the status of the database synchronization between the workload clusters.

This command offers the following option:

  • context multi-cluster-context-name —The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

Note:

This command is only supported in a multiple geographically located setup.

apm multi-cluster status --context multi-cluster-context-name

Displays the status of the workload clusters from the application’s perspective.

This command offers the following option:

  • context multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

Note:

This command is only supported in a multiple geographically located setup.

sudo -E apm multi-cluster switchover --context multi-cluster-context-name --workload-context workload-context-name --force --role [active | dormant]

Initiates a switchover to the other workload cluster. The APM microservices are rescheduled on the other workload cluster. To run this command, you need sudo root privileges.

This command offers the following option:

  • context multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • force—Ignores errors related to the deactivation of the active workload cluster.

    For example, in the event that the active workload cluster is down and you want to make the dormant cluster active, the switchover command will result in an error. The force argument ignores the error and makes the dormant cluster the active cluster.

    Note: Since the active cluster could not be accessed to safely transition it to a dormant state, activating the backup cluster runs the risk of creating an active-active scenario.

    If you want to manually set the role of a cluster (such as in a scenario where both workload clusters have become dormant), you can run the switchover command with the following options to accomplish this.

  • role—Enter either active or dormant. Designates the role of the workload cluster.

  • workload-context workload-context-name—The name of the workload context whose role you want to set.

This command is only supported in a multiple geography setup.

sudo -E apm rename-context --context [context-name | multi-cluster-context-name] --new-name new-name

 Renames a context. The command does not affect the APM that is currently running on the cluster. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • new-name new-name—The new name of the Kubernetes context. Enter a new name.

sudo -E apm restart --context [context-name | multi-cluster-context-name] --workload-context workload-context-name --force --wait microservice-name

 Restart one or more specified services. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The name of the workload context on which the microservice instance should be restarted. This option is only used for multiple geography setups.

  • force—Forcibly restart the micro-service without validating that it can be safely restarted.

  • wait—Wait for the new pod to fully come up.

  • microservice-name—Enter the microservice name to restart.

sudo -E apm rollout --context [context-name | multi-cluster-context-name] --workload-context workload-context-name [--service service name --version software-release]

 Upgrade or start an APM service. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The workload context name to roll out. This option is only used for multiple geography setups and is only used during the upgrade process.

  • sevice service name—The microservice name to roll out. Enter the microservice's name. This command only applies to when you are upgrading APM.

  • version software-release—The software release to roll out. Enter the software release number. This command only applies to when you are upgrading APM.
sudo -E apm save-config -- context [context-name | multi-cluster-context-name]

Archives the current working configuration of APM so that the configuration is preserved when an apm stop and apm rollout event sequence occurs. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

sudo -E apm setup --context [context-name | multi-cluster-context-name] --help --log info --no color --bbecloudsetup --update --ssh ip-address:port-number --secrets --verbose --config file-name --template file-name --mandatory --optional

Set up the APM application as part of the installation process. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • h, help—Shows the help message and exit.

  • l, log [error, warning, info, debug]—Adjusts the log level.

  • no-color—Prints messages without colors.

  • bbecloudsetup—Fills in operational parameters that align with a bbecloudsetup created cluster so that you do not have to interact with APM during the setup process (see the BBE Cloudsetup Installation Guide for cluster installation instructions).

    Note:

    Only use either the bbecloudsetup option or the template file-name option. Do not use both options.

  • update—You will only be prompted for missing values during setup.

  • ssh ip-address:port-number—(Used for a single geography setup only) Enter the cluster's virtual IP address or an IP address of a cluster node and a port number on which the APM management microservice is listening for SSH (when enabled in the configuration). The IP address can also be a DNS name.

    Note: To set up CLI access through SSH in a multiple geography deployment, you must use a template file (use the template option in the setup command). This enables you to configure the two workload cluster addresses.

  • secrets—Updates the keys, certificates, and secrets used by APM.

  • verbose—Provides a detailed description before each prompted question.

  • config file-name—The initial configuration file that you want APM to use at startup.

  • template file-name—A YAML formatted file that contains a subset of the configuration file that is created during setup. The values that are entered in the template file are used automatically by the setup process. When you use the template option, you are not required to manually enter the information contained in the template file during the setup process. You should only use the template option when using Red Hat OpenShift Container Platform to create the cluster or when creating a multiple geographical cluster. Table 3 describes the information that you need to enter into the template configuration file.

    Note:

    Only use either the bbecloudsetup option or the template file-name option. Do not use both options.

  • mandatory—Only asks required questions during setup.

  • optional—Only asks questions that are not required during setup.

sudo -E apm shell --context [context-name | multi-cluster-context-name] --workload-context workload-context-name [-p|--pipe] microservice-name

 Connects you to a running microservice. To run this command, you need sudo root privileges.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • workload-context workload-context-name—The name of the workload context on which the microservice you want to connect to is present.

  • microservice-name—The name of the microservice that you want to connect to.

  • pipe—Allows you to pipe input into the command.

apm status --context [context-name | multi-cluster-context-name] [-o|--output json] --terse --detail

 Display the current status of the APM services.

This command offers the following options:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • output—Allows you to request the output in JSON format.

  • terse—Displays a summarized output of the health of the system.

  • detail—Displays information for each pod.

sudo -E apm stop --context [context-name | multi-cluster-context-name] --now

 Stops all APM services. To run this command, you need sudo root privileges.

This command offers the following option:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

  • now—Stops APM immediately, instead of waiting for the two minute delay.
apm storage --context [context-name | multi-cluster-context-name]

Provides the status of the storage drivers for APM.

This command offers the following option:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.
sudo -E apm unlink --context [context-name | multi-cluster-context-name]

Unlink components associated with the context. To run this command, you need sudo root privileges.

This command offers the following option:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.
apm version --context [context-name | multi-cluster-context-name] --detail

Displays the version of every running microservice in the APM instance as well as the APM utility. It also lists all available APM software releases on the system.

This command offers the following option:

  • context—Enter either of the following:

    • context-name—The Kubernetes context name of the cluster for a single cluster setup.

    • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

    • detail—To display detailed information.

Use the following general syntax to issue a command:

  • For a short option:

  • For a long option:

To target a command at a particular cluster context, use the context option.

To display a list of available commands with a brief description, use either the h or help option:

To display the options for a specific command:

To specify the no-color option to disable colored text output (used to distinguish logs from different microservices):

Upgrade APM to a New Version Using the APM installation Utility

Use this procedure to upgrade to a new version of APM which is installed on a similar cluster deployment (single geography or multiple geography). This procedure assumes APM is running on your system.

Note: You cannot upgrade between a single geography and a multiple geography deployment.

Use this procedure to upgrade to a new version of APM which is installed on a cluster that was created by the BBE Cloudsetup utility or by Red Hat OpenShift Container Platform Console. This procedure assumes APM is running on your system.

  1. Download the APM software package from the Juniper Networks software download page to the jump host.

    APM is available as a compressed tarball image (.tgz). The filename includes the release number as part of the name. The release number has the format: <Major>.<Minor>.<Maintenance>

    • major is the main release number of the product.
    • minor is the minor release number of the product.
    • maintenance is the revision number.
  2. Unpack the APM tarball (.tgz) file on the jump host by entering:
  3. Run the loader script after you unpack the tarball.
  4. Link to the cluster by using the link command. The link command associates the loaded APM software package to the cluster in preparation for the setup. The commands that you enter for a single geography or multiple geography deployment are different. Run the following command that is appropriate for your deployment:

    • Single geography:

    • Multiple geography:

    • context—Enter one of the following:

      • context-name—The Kubernetes context name of the cluster for a single cluster setup.

      • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

    • apm-version—The APM software version.

    • workload-1-context-name workload-2-context-name—The two workload context names.

  5. If you are upgrading APM on a Red Hat OpenShift Container Platform cluster, log in with the OpenShift CLI and then proceed to the next step.
    If you are installing APM on a BBE Cloudsetup created cluster, proceed to the next step.
  6. You must authenticate with each cluster's container registry in order to push the APM container images. For a single geography deployment. you authenticate with the single cluster's container registry. For a multiple geography deployment, you authenticate with the container registries of the management, and both workload clusters. How you authenticate to the registry varies depending on if you are installing APM on a BBE Cloudsetup created cluster or on an Red Hat OpenShift Container Platform cluster (see the respective documentation for details).
  7. Run the setup command to complete the setup of any additional environment values. The commands that you enter for a single geography or multiple geography deployment are different. Run the following command that is appropriate for your deployment:

    • Single geography:

    • Multiple geography:

    • context—Enter one of the following:

      • context-name—The Kubernetes context name of the cluster for a single cluster setup.

      • multi-cluster-context-name—The context name for a multiple geography setup. The multi-cluster-context-name is a user-defined string applied to the link command that serves as a common reference for the two workload clusters.

    • update are the prompts for only missing values (primarily used after loading a new software release).

  8. Display the running database to see which pod is the primary pod and to determine whether to upgrade the persistent state database. The commands that you enter for a single geography or multiple geography deployment are different. Run the following command that is appropriate for your deployment:

    • Single geography:

    • Multiple geography:

  9. Display the database version in the new package:
    Note:

    For example, the database version 6.2.16-debian-12-r3 is later than what is running (6.2.14), so you need to upgrade the database.
  10. Initiate a database switchover if the jnpr-apm-redis-0 is not the primary database. The commands that you enter for a single geography or multiple geography deployment are different. Run the following command that is appropriate for your deployment:

    • Single geography:

    • Multiple geography:

  11. Upgrade the microservices using the rollout command. Enter the commands in the following order for your deployment (single or multiple geography):
    Note:

    If the redis microservice version is not changing, you do not need to run the rollout command to upgrade it.

    • Single geography:

    • Multiple geography

      Note: You are required to run the following commands on both workload contexts. After completing these commands on the dormant context, perform an apm multi-cluster switchover (see Table 1). When you perform the switchover, you are switching the current active workload context to the dormant context, and vice versa. Then, perform these commands on the now dormant context.
  12. Verify that all microservices are running the new version of software:

Start or Stop APM Services Using the APM Utility

Use the apm utility script to start or stop all APM services. The services start in order of dependency. Essential services (db and mgmt) start first, followed by the other services. The services stop in reverse order of dependency.

  • To start all APM services:

    Note:

    APM starts from it's initial settings when you execute the apm setup command. Any persistent state is lost when the apm stop command is executed. The current configuration can be saved using the apm save-config command. The saved configuration is the configuration that is used the next time APM is started.

  • To stop all APM services:

Setup Secrets Using the APM Utility

You can setup secrets during setup or run the sudo -E apm setup --context context-name --secrets to setup secrets or update them.

Note:

If you enter a value for the secret name, you will not be asked for the key or certification files.

Display Database Information Using the APM Utility

The apm db-info command displays current state of APM’s database microservice including the current version, stateful set pods, and their roles.

Single Geographically Located Setup

Multiple Geographically Located Setup

Note: When using the apm db-info command, the workload-context workload-context-name argument is optional.

Check the Status of APM Services Using the APM Utility

Use the apm status utility script to check the status of each APM service (functional component) listed in Table 2. The status shows whether a service is running, has exited, or has not started. It also displays the service name on the Kubernetes pod. You can compare uptime for the services to quickly see whether any service has been restarted.

Note: You use the apm status utility script to check the status of each APM service for a multiple geography setup.
Table 2: Services Displayed with the Status Command

Microservice

Pod Prefix

addrman—Address manager.

jnpr-apm-addrman

dbSync—Database synchronization.

jnpr-apm-dbSync

entman—Entity manager.

jnpr-apm-entman

mgmt—CLI management.

jnpr-apm-mgmt

apm-operator—Coordinates switchovers and collects system health information.

jnpr-apm-operator

provman—Provisioning manager.

jnpr-apm-provman

redis (Remote Dictionary Server)—consists of a set of pods which provide the persistent database.

jnpr-apm-redis

To check the status:

  1. Display the service status.
  2. (Optional) Render the version information in JavaScript Object Notation (JSON) format, which is useful for scripting interfaces.

For example:

Display APM IP Addresses Using the APM Utility

Use the apm ip utility script to display the Kubernetes objects that are necessary for the orchestration of the APM pods. For example:

Display Logging Using the APM Utility

Use the apm logs utility script to display the logs of events that occur while APM is running. You can also use the BBE Event Collection and Visualization utility to display file-based logs collected and stored since the time APM is started. BBE Event Collection and Visualization is a cloud-based centralized utility that provides a way to capture APM logs that span the life cycle of APM microservices. You link to the BBE Event Collection and Visualization logging utility when you set up APM. See the Broadband Edge Event Collection and Visualization Installation Guide.

Display APM Logging

BBE Event Collection and Visualization is a cloud-based centralized utility that provides a way to capture APM logs that span the life-cycle of APM microservices. If BBE Event Collection and Visualization is running, during the APM setup you can point BBE Event Collection and Visualization to perform the logging. BBE Event Collection and Visualization has a web-based interface to OpenSearch’s capabilities for advanced searching, aggregation, viewing, and data analysis of collected syslog events.

Use the apm logs utility script to display the logs of events that occur while APM is running. The event logs include events such as those shown in the following non-exhaustive list:

  • Pool-domain registration events

  • Address allocation failures

  • Network entity connection failures

  • Startup messages

  • Network entity resynchronization events

  • Pool and partition utilization threshold and depletion warnings

By default, APM sends logs to the standard output (stdout) of the service. The output displays the circular buffer of all services or of a specified service. You can also enable logging to follow the log output of the running services. Following the log output creates an open session that continuously streams the logs to stdout.

The APM logging functions mask the underlying complexities of the kubectl log command that is collecting the log information. You can still use the kubectl log command, but that is outside the scope of this documentation.

Note:

You can use third-party applications to capture and redirect the stdout stream for the container. Refer to your third-party documentation for assistance. You can also configure Docker with different logging drivers to redirect stdout. Refer to your Docker documentation for assistance.

To display APM logs for all services:

Best Practice:

Use the apm logs [--context contextName] [--workload-context workload-context-name]] --services option only when you are troubleshooting under the guidance of a Juniper Networks support representative.

To follow the logs for all services, specify the follow option (-f):

To view logs from previous instances of the containers in a Kubernetes pod, specify the previous container option (-p):

You can use standard Ubuntu conventions to redirect the logs to a file or to the terminal and to a file. Refer to the Ubuntu documentation for more information, but you can use the following examples as a starting point:

  • Redirect all logs to only a file.

  • Redirect all logs to both the screen and to a file.

Best Practice:

Use the --services option only for troubleshooting under the guidance of a Juniper Networks support representative.

You can specify any of the following severity levels, in order of increasing severity:

Table 3: Severity Level
Severity Level Description
debug Detailed information that is typically of interest only when you are trying to diagnose a problem. These logs are often very frequent.
info Events or non-error conditions of interest. Logs at this level provide confirmation that everything is working as expected. These logs are generally not very frequent.
warning Indicates that something unexpected happened or that some problem might occur in the near future. A simple example of the latter is the disk space low warning that indicates that you might run out of disk space soon. In either case, the software is still working as expected, but you might want to monitor it more closely. These logs are generally not very frequent.
error Indicates that a more serious problem has prevented the software from performing some function, but the software has handled the problem as gracefully as possible to continue functioning.
critical A serious error that indicates that the program itself might be unable to continue running.

You can use the --logset option to display logs either for only APM services or for only prebuilt services. If you do not use this option, then only the APM services logs are displayed.

To display logs for only APM services:

To display logs for prebuilt services:

Prebuilt services are services borrowed from other sources to provide infrastructure functions for APM. These sources include mgmt, redis, and redis-sentinel. For example, redis provides database and messaging services, mgmt provides configuration and CLI services, and so on.

Determine the APM Version Using the APM Utility

Use the apm version [--context context-name] [-o|--output json] [--detail] [--compare software-version] utility script to determine the version number of the installed APM release.

To display the release version:

To compare the specified software release versions against the current deployed release for the specified context:

Use the -j option to render the version information in JavaScript Object Notation (JSON) format.

Uninstall and Remove APM Using the APM Utility

Use the apm utility script to uninstall the APM configuration. The uninstall command reverts the actions you performed when setting up APM. Use this command to return APM to the state it was in immediately after you installed the application but before you did any setup configuration.

To uninstall APM:

After you uninstall APM, we recommend that you use the Debian uninstall procedure to remove the entire package.

For the apm clean command options, see the following:

  • -h or --help—Show the help message and exit.

  • --log or -l [error | warn | info | debug]—Adjust the log level of the utility scrip.

  • --no-color—Print messages without colors.

  • --docker—Clean the local docker cache.

  • --release release-number—The release to clean (defaults to unused releases).

  • --dry-run—List releases or containers that will be removed.

  • --uninstall—Uninstall all software releases and remove APM from the system.

  • --cluster-repos—Clean the cluster repository for the clusters that have been removed.

How to Access APM Configuration and Operational Commands Using the APM Utility

Access the APM CLI Using the APM Utility

To access the CLI prompt, enter the following apm utility script command:

Enter a question mark to see the available top-level CLI commands. This list of commands is a subset of the Junos OS top-level commands.

For an overview of Junos OS CLI basics, see Day One: Exploring the Junos CLI. For more detailed information, see the CLI User Guide.

Access and Use CLI Configuration Statements Using the APM Utility

  1. Use the APM utility command apm cli to access the top-level CLI prompt.
  2. Access configuration mode to configure APM and the information that APM uses to configure a managed router.
  3. Enter CLI statements to configure the APM-managed BNGs, pool domains, pools, and system attributes.
  4. Save and activate the configuration. This command succeeds only when there are no configuration syntax errors.
  5. (Optional) Exit configuration mode and return to the top-level CLI prompt.

Access and Use CLI Operational Commands Using the APM Utility

To monitor APM, view APM configuration and statistics, or run certain operations manually:

  1. Use the APM utility command apm cli to access the top-level CLI prompt.
  2. Enter specific commands.

    • Use show commands to display statistics and the relationships between partitions, BNGs, pool domains, and pools.

    • Use request commands to manually initiate certain APM operations.