Dashboard Initialization

Cloudsoft AMP ships with a powerful Application Dashboard which can be used to show key attributes of hybrid applications in real time. This includes overall health, cost, incidents, and multiple aspects of compliance and resilience. Many of these are included out-of-the-box, and many more are available as part of AMP Compliance Packs, and all are designed to permit customization to work well in demanding, bespoke environments. This documentation will show you how.

Overview

The central idea of the Application Dashboard is that information can be published on any entity as a sensor of type DashboardInfo (or any subtype of DashboardSensorValueAggregable or a Set thereof).
The Cloudsoft AMP framework will then automatically combine these, using the management hierarchy to roll these up and display a summary of all such sensors for each application. The management hierarchy can then be expaned to see this information for different parts of the application.

AMP policies can automate the collection of these, across any or all entities and environments; many of the out-of-the-box policies do this already. For example the ElectPrimary policy will publish dashboard.primaries, reporting, at any node where it is applied, which child is currently the primary.

A summary of infrastructure resources consumed (locations) and cost estimate is collected for all applications, enabled out-of-the-box:

In addition, Cloudsoft AMP Compliance Packs ship with AMP and can be configured to provide Dashboard sensors addressing common areas including security, resilience, and data privacy.

Compliance Packs Quick Start

Compliance Packs automate common security and governance requirements, both running by AMP and reading from external systems. As a quick-start example, this section will show how to:

• Run malware and OS vulnerability detection on all managed VMs
• Collect security scan results from third-party systems, including for non-VM cloud services and resources

This example will use the leading open-source vulnerability tool lynis for the first point, and will connect to AWS Config compliance checks for the second; more importantly, it will show how these actions can be customized to support all on-box and off-box requirements.

On-box Compliance Checks: Lynis Vulnerability Detection

Specifying that a command or script should be periodically run by AMP on a server under management, and its output used to populate a sensor, is as simple as adding the following on an entity’s blueprint:

brooklyn.initializers:
- type: ssh-command-sensor
  brooklyn.config:
    name: dashboard.security.lynis
    targetType: compliance-check
    # command OR commandUrl
    commandUrl: classpath://io/cloudsoft/amp/compliance/lynis/lynis-result-sensor.sh
    period: 5m

This will upload and run lynis-result-sensor.sh every 5 minutes, and take the output from that script converted from YAML or JSON to the indicated sensor targetType – in this case a compliance-check corresponding to ComplianceCheck. The script is straightforward; it just runs lynis (installing it if necessary), and then outputs YAML containing a summary, an id, a when_created date, and the boolean pass value. Cloudsoft AMP creates the sensor and propogates/aggregates it to the root element and presents it on the dashboard.

Conventions

• Initializers can be run against all newly deployed applications by setting brooklyn.deployment.initializers to a comma-separated list of initializer classes or registered types; these can be used to add policies to root nodes or to all nodes, and by default in AMP include the standard dashboard aggregation logic and collection of dashboard location data

• For many dashboard sensors, the dashboard.priority configuration key on an entity or policy can be used to indicate a priority for information arising from that node. The priority indicates which information is selected for display when aggregating multiple information (higher is preferred). In many cases, this can be overridden for a specific sensor (e.g. dashboard.sample) by using the configuration key dashboard.sample.priority.

Tips

Creating Dashboard Sensors from Other Sensors

The template-transformer-enricher can be used to create dashboard sensors from other sensors, using a freemarker templated map. For example the following creates an “Address” sensor titled “Regional URL” pointing at the main.uri sensor on an entity. This allows that URL to be visible in the dashboard:

  - type: template-transformer-enricher
    brooklyn.config:
      target: dashboard.address
      sensorType: list<dashboard-info>
      triggers: [ main.uri ]
      template:
      - id: ${entity.id}.sensor.main.uri
        summary: "Regional URL"
        notes: ${attribute['main.uri']}
        priority: 50
        links:
          address: ${attribute['main.uri']}