title: Monitoring and Managing Applications title_in_menu: Monitoring and Managing Applications layout: website-normal menu_parent: index.md children:
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.
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.
Using the name Tomcat we can get the application details:
{% highlight bash %} $ br app Tomcat {% endhighlight %}
We can explore the management hierarchy of all applications, which will show us the entities they are composed of. {% highlight bash %} $ br tree {% endhighlight %}
You can view the blueprint for the application again: {% highlight bash %} $ br app tomcat spec {% endhighlight %}
You can view the config of the application: {% highlight bash %} $ br app tomcat config {% endhighlight %}
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 app Tomcat entity {% endhighlight %}
You can get summary information for an entity by providing its name (or ID).
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r {% endhighlight %}
Also you can see the config of the entity with the config command.
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r config {% endhighlight %}
If an entity name is annoyingly long to type, the entity can be renamed:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r rename server {% endhighlight %}
Sensors are properties which reflect the state of an entity and provide a real-time picture of an entity in an application.
To view the sensors on the application itself, use the command below:
{% highlight bash %} $ br app Tomcat sensor {% endhighlight %}
To explore all sensors available on an entity use the sensor command with an entity scope. Note, again, the name of the application or entity can be used or the ID:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r sensor {% endhighlight %}
To study selected sensors, give the command the sensor name as an argument
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r sensor webapp.url
{% endhighlight %}
Effectors are the means by which you can manipulate the entities in an application. For an application you can list them with
{% highlight bash %} $ br app Tomcat effector {% endhighlight %}
For an entity supply the entity scope:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r effector {% endhighlight %}
To view just one effector's documentation, supply its name to the show command:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r effector deploy {% endhighlight %}
These effectors can be invoked using the command invoke, supplying the application and entity id of the entity to invoke the effector on.
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. Do the invocation by supplying the effector name in the scope, and using the command invoke.
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r eff stop invoke {% endhighlight %}
Note that the three “lifecycle” related effectors, start, stop, and restart, are common to all software process entities in Brooklyn. They are so commonly used that they have their own aliases. The above could also have been done by:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r stop {% endhighlight %}
Some effectors require parameters for their invocation, as in the example of deploy above.
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r effector deploy {% endhighlight %}
Now the effector can be invoked by supplying the parameters using --param parm=value or just -P parm=value.
In the example below, a sample Tomcat war file is deployed, a variable is created for the root URL using the appropriate sensor, and the index page is fetched. Note that at present a tr command is required in the second line below to strip quotation characters from the returned sensor value.
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r effector deploy invoke -P url=https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war -P targetName=sample $ webapp=$(br app Tomcat ent TomcatServer:Wx7r sensor webapp.url | tr -d ‘"’) $ curl $webapp/sample/ {% endhighlight %}
The activity command allows us to investigate the activities of an entity.
To view a list of all activities associated with an entity simply use
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r activity {% endhighlight %}
To view the details of an individual activity provide its ID:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r activity jwwcJWmF {% endhighlight %}
If an activity has failed, the “DetailedStatus” value will show information about the failure, as an aid to diagnosis.
Adding the --children or -c parameter will show the activity's child activities, to allow the hierarchical structure of the activities to be investigated:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r activity -c jwwcJWmF {% endhighlight %}
If an activity has associated input and output streams, these may be viewed by providing the activity scope and using the commands, env, stdin, stdout, and stderr. For example, for the “initializing on-box base dir” activity from the result of the earlier example,
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r act KLTxDkoa stdout BASE_DIR_RESULT:/home/vagrant/brooklyn-managed-processes:BASE_DIR_RESULT {% endhighlight %}
To monitor progress on an application as it deploys, for example, one could use a shell loop:
{% highlight bash %} $ while br app Tomcat ent TomcatServer:Wx7r activity | grep ‘In progress’ ; do sleep 1; echo ; date; done {% endhighlight %} This loop will exit when the application has deployed successfully or has failed. If it fails then the ‘stderr’ command may provide information about what happened in any activities that have associated streams:
{% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r act KLTxDkoa stderr {% endhighlight %}
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)entity ENT-ID (ent, e)br app myapp ent myservereffector EFF-ID (eff, f)br a myapp e myserver eff xyzconfig CONF-KEY (conf, con, c)br a myapp e myserver config jmx.agent.modeactivity ACT-ID (act, v)br a myapp e myserver act iHG7sq1For example {% highlight bash %} $ br app Tomcat ent TomcatServer:Wx7r config {% endhighlight %} runs the config command with application scope of Tomcat and entity scope of TomcatServer:Wx7r.
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.