Skip to main content

Continuous Monitoring of Applications

Continuous Monitoring is a powerful feature of Lifecycle that regularly checks applications for new violations. The primary use case of this feature is to maintain visibility on applications that have been released or deployed and are not in the build stage.

You can configure this feature to alert specific individuals/groups and schedule to run at specific times.

Turning On Continuous Monitoring

Turning on Continuous Monitoring is a two-step process. Failure to complete step two will result in notifications not being sent after policy evaluation.

Note

Continuous Monitoring uses the same inheritance hierarchy as policy i.e., Root Organization at the top, followed by the Organization, and finally the Application. Depending on your IQ Server configuration, it may seem like some settings cannot be changed. In this scenario, move one level up on the hierarchy.

Note

The Edit IQ elements permission is required for the organization/application for which Continuous Monitoring is configured.

Step One: Turning on Continuous Monitoring at the Organization or Application Level

  1. On the left sidebar, click Orgs and Policies.

  2. Select the organization or application you want to monitor.

  3. Click the Continuous Monitoring button or scroll down to the Continuous Monitoring section.

    100139847.png
  4. You should see the option Do Not Monitor or Inherit from [Parent] (Do not monitor). Click the chevron.

    100139848.png
  5. Select a stage to monitor, from the list and then click Update.

    100139849.png

Step Two: Configuring Notifications at Policy Level

Configure notifications for Continuous Monitoring at the policy level to identify who should receive an email message when new policy violations are triggered.

  1. On the left sidebar, click Orgs and Policies.

  2. Select the organization or application you want to monitor.

  3. Click on an existing policy. If the policy is grayed out, that means that policy is being inherited from the organization or root organization and can't be altered at this level. Move one step up the hierarchy and click on the policy. If it's still grayed out, move another step up the hierarchy.

  4. Click the Notifications button or scroll to the Notifications section.

    100139850.png
  5. Select the recipient type. You can mix and match multiple recipients across all three types.

    1. If the recipient type is Emails, specify the exact email address.

    2. If the recipient type is Role, select the role. All users assigned this role will receive a notification email.

    3. If the recipient type is Webhook, select an existing Webhook from the list. See IQ Server Webhooks to learn more.

  6. For each notification recipient, check the Continuous Monitoring box.

Turning off Continuous Monitoring

To turn off Continuous Monitoring:

  1. On the left sidebar, click Orgs and Policies .

  2. Select the organization or application you want to turn off Continous Monitoring for.

  3. Click the Continuous Monitoring button or scroll down to the Continuous Monitoring section.

  4. Click the chevron.

  5. Select Do Not Monitor or Inherit from [Parent] (Do not monitor) and then click Update.

Scheduling Continuous Monitoring

By default, Continuous Monitoring starts at 12:00 midnight, based on the time of the machine hosting the IQ Server. You can change the start time for Continuous Monitoring as follows:

For IQ Server Release 142 and later

Via the Configuration REST API.

For IQ Server Release 141 and prior

Via IQ Server’s config.yml file as follows:

# Hour of the day(0-23) to schedule Policy Monitoring execution. The default is midnight.
policyMonitoringHour: 0

By default, the config.yml file is located in the same directory as your nexus-iq-server-[version].jar file.

Manually Triggering Continuous Monitoring

You can manually start Continuous Monitoring by issuing the following command to the IQ Server's administrative port.

$ curl -X POST http://localhost:8071/tasks/triggerPolicyMonitor

This command is not recommended for most situations. Instead, edit the config.yml file as described in the section above.