title: Monitoring and Managing Applications title_in_menu: Monitoring and Managing Applications layout: website-normal menu_parent: index.md children:

  • { section: Applications }
  • { section: Entities }
  • { section: Sensors }
  • { section: Effectors }
  • { section: Activities }

So far we have gone through Apache Brooklyn's ability to deploy an application blueprint to a location, but this just the beginning. Next we will outline how to manage the application that has been deployed.

Applications

Having created the application, we can find a summary of all deployed applications using: {% highlight bash %} $ br application
{% endhighlight %}

application can be shortened to the alias app, for example: {% highlight bash %} $ br app
{% endhighlight %}

A full list of abbreviations such as this can be found in the CLI reference guide{:target=“_blank”}.

In the above example the Id hTPAF19s and the Name Tomcat are shown. You can use either of these handles to monitor and control the application. The Id shown for your application will be different to this but the name should be the same, note that if you are running multiple applications the Name may not be unique.

Things we might want to do

Entities

An Entity is Apache Brooklyn's representation of a software package or service which it can control or interact with. All of the entities Apache Brooklyn can use are listed in the Brooklyn Catalog.

To list the entities of the application you can use the entity or ent command:

{% highlight bash %} $ br application Tomcat entity {% endhighlight %}

This shows one entity is available: tomcatServer. Note that this is the name we gave the entity in the YAML in Launching from a Blueprint on the previous page.

You can get summary information for this entity by providing its name (or ID).

{% highlight bash %} $ br application Tomcat entity tomcatServer {% endhighlight %}

Also you can see the configuration of this entity with the config command.

{% highlight bash %} $ br application Tomcat entity tomcatServer config {% endhighlight %}

Sensors

Sensors are properties which show the state of an entity and provide a real-time picture of an entity within an application.

You can view the sensors available on the application using:

{% highlight bash %} $ br application Tomcat sensor {% endhighlight %}

To explore sensors on a specific entity use the sensor command with an entity specified:

{% highlight bash %} $ br application Tomcat entity tomcatServer sensor {% endhighlight %}

To display the value of a selected sensor, give the command the sensor name as an argument

{% highlight bash %} $ br application Tomcat entity tomcatServer sensor webapp.url
{% endhighlight %}

Effectors

Effectors are a means by which you can manipulate the entities in an application. You can list the available effectors for your application using:

{% highlight bash %} $ br application Tomcat effector {% endhighlight %}

For example, to stop an application, use the stop effector. This will cleanly shutdown all components in the application and return any cloud machines that were being used. Note that the three “lifecycle” related effectors, start, stop, and restart, are common to all applications and software process entities in Brooklyn.

You can list the effectors for a specific entity using the command:

{% highlight bash %} $ br application Tomcat entity tomcatServer effector {% endhighlight %}

To view the details for a specific effector, append it's name to the command:

{% highlight bash %} $ br application Tomcat entity tomcatServer effector deploy {% endhighlight %}

These effectors can also be invoked by appending invoke to this command. Some effectors require parameters for their invocation. For example, if we look at the details for deploy above we can see it requires a url and targetName.

These parameters can be supplied using --param parm=value or just -P parm=value.

The commands below deploy the Apache Tomcat hello world example{:target=“_blank”} to our Tomcat Server. In these commands, a variable is created for the root URL using the appropriate sensor and the index page html is displayed.

{% highlight bash %} $ br application Tomcat entity tomcatServer effector deploy invoke -P url=https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war -P targetName=sample $ webapp=$(br application Tomcat entity tomcatServer sensor webapp.url | tr -d ‘"’) $ curl $webapp/sample/ {% endhighlight %} Sample “Hello, World” Application ...

Note that at present a tr command is required in the second line below to strip quotation characters from the returned sensor value.

Activities

Activities are the actions an application or entity takes within Apache Brooklyn. The activity command allows us to list out these activities.

To view a list of all activities associated with an entity enter:

{% highlight bash %} $ br application Tomcat entity tomcatServer activity {% endhighlight %}

To view the details of an individual activity, add its ID to the command. In our case this is jwwcJWmF

{% highlight bash %} $ br application Tomcat entity tomcatServer activity jwwcJWmF {% endhighlight %}

Things we might want to do

            </div>
        </div>
    </div>
    <div class="panel panel-default">
        <div class="panel-heading">
            <h4 class="panel-title">
                <a data-toggle="collapse" data-parent="#accordionB" href="#collapseThreeB">Diagnose a failure</a>
            </h4>
        </div>
        <div id="collapseThreeB" class="panel-collapse collapse">
            <div class="panel-body">

java.lang.IllegalStateException: Software process entity TomcatServerImpl{id=qZeyoITy} did not pass is-running check within the required 5m limit (5m elapsed) at org.apache.brooklyn.entity.software.base.SoftwareProcessImpl.waitForEntityStart(SoftwareProcessImpl.java:586) at org.apache.brooklyn.entity.software.base.SoftwareProcessImpl.postDriverStart(SoftwareProcessImpl.java:260) at org.apache.brooklyn.entity.software.base.SoftwareProcessDriverLifecycleEffectorTasks.postStartCustom(SoftwareProcessDriverLifecycleEffectorTasks.java:169) at org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$PostStartTask.run(MachineLifecycleEffectorTasks.java:570) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:342) at org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:468) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)" 

            </div>
        </div>
    </div>
</div>

{::comment}

Scopes in CLI commands

Many commands require a “scope” expression to indicate the target on which they operate. The scope expressions are as follows (values in brackets are aliases for the scope):

  • application APP-ID (app, a)
    Selects an application, e.g. “br application myapp”
  • entity ENT-ID (ent, e)
    Selects an entity within an application scope, e.g. br application myapp entity myserver
  • effector EFF-ID (eff, f)
    Selects an effector of an entity or application, e.g. br a myapp e myserver eff xyz
  • config CONF-KEY (conf, con, c)
    Selects a configuration key of an entity e.g. br a myapp e myserver config jmx.agent.mode
  • activity ACT-ID (act, v)
    Selects an activity of an entity e.g. br a myapp e myserver act iHG7sq1

For example {% highlight bash %} $ br application Tomcat entity tomcatServer config {% endhighlight %} runs the config command with application scope of Tomcat and entity scope of tomcatServer.

{:/comment}

Next

We will look next at a slightly more complex example, which will illustrate the capabilities of Brooklyn's policies mechanism, and how to configure dependencies between application entities.