Monitoring Platform Symphony.

Sitting at my desk, I was approached and asked this question.

Do you guys support Platform Symphony?

An interesting question, really we “support” most anything, Logscape has the base functionality for most tasks, and product “apps” just build upon that functionality, the app provides the workspaces, data types and sources, as well as the tools that Logscape will use to find the data you want. But at the end of the day it’s still Logscape, just it’s running a groovy script to fetch your metrics.

So what is the process that goes into making a Logscape App?

Step 1) Locate the Application metrics

The first step in the creation of any Logscape app is to locate where the application you’re interested in, outputs metrics to, in the case of Platform Symphony, these metrics are easy to obtain, as they can be outputted directly into a SQL Server database, from there it’s just a matter of connecting to the database, and extracting the metrics you’re interested in.

2) Extracting the metrics

Once the metrics have been located, the next question faced is how to get these into Logscape, in the scenario with Platform Symphony, it was as simple as querying the SQL database, and writing the results to file. For this task a simple groovy script was created.

import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.SQLException;
import groovy.sql.Sql;
import groovy.sql.GroovyResultSetExtension;

def validate(defaultProperties,properties){
	for(def prop:defaultProperties){
		if (properties.containsKey(prop) == false){
			throw new Exception(" $prop is required property ")

def properties=[:] 
def defaultProperties = ["host","port","usr","pass","query"]

for (def input:args){
	def toks=input.split(":")
	def k=toks[0]
	def v=toks[1]
	properties[k] = v

	println "USAGE: groovy symphony_SQL.groovy host:[VALUE] port:[VALUE] usr:[VALUE] pass:[VALUE] query:[VALUE]"

def propertyMissing(String name) {}

pout = pout == null ? System.out : pout
perr = perr == null ? System.err : perr

def stdOut = pout
def stdErr = perr

def host = properties.getAt("host")
def port = properties.getAt("port")
def query = properties.getAt("query")
def username = properties.getAt("usr")
def password = properties.getAt("pass")

def sql = Sql.newInstance("jdbc:sqlserver://$host:$port", "$username", "Blah!Blah!Blah!")

sql.eachRow(query){ row -> 
	GroovyResultSetExtension resultSet = new GroovyResultSetExtension(row)
	ts = row.getAt('TIME_STAMP')
	aString = "$ts" + resultSet.toString().replace("["," ").replace("]","") + "\n"
	pout << aString

This groovy script is used to extract any metrics we want from our Project Symphony database, it’s simply called from the apps bundle file, which specifies how often to call the script, as well as the arguments to pass to it.

3) Make the bundle, deploy the app, create the datasource

Now that we’ve located, and found a way to extract our metrics, we need to write the bundle file. The bundle file is responsible for managing “services” within your app, the bundle file for our small example simply calls our groovy script, passing it arguments, in deployment an override file could be used to set the host, port, username and password.

The fully cleaned bundle can be viewed on pastebin¬†here¬†(It’s not that interesting, honest)

Due to the groovy scripts dependency on the SQL server driver, the jar is included in the app inside the “lib” folder, this folder is automatically loaded into the classpath at run-time by Logscape. With the Lib folder now containing the required driver and the bundle file properly set up, the app can be zipped and deployed into Logscape, once deployed the services defined within the bundle will start, and any data retrieved, wrote to file. But we still can’t see it. We can’t see the data inside Logscape because a datasource hasn’t been set up for our app yet, this needs to be created, and will later be exported along with the the workspaces to an XML format which will be included in the final release of the app so that the datasources and workspaces are automatically loaded when the app is deployed.

4) Build the workspaces

The app is now deployed into our environment, and is gathering data from the Platform Symphony database, that data is visible to searches inside Logscape, it’s time to make the workspaces.

Approaching the creation of the workspaces, it wasn’t really clear as to what the data would allow us to display, while we had a high level view of what we wanted to build into the workspaces, we still needed to take a data-driven approach to their creation.

We wanted to provide an overall view of the Project Symphony installation as the landing page for the app, while also making use of (LINK_HERE) 2.5.1’s Linking update to drill deeper into the data that was available. As such, we came up with this as the homepage for the app.



Alot of our data was synthetic, or generated only by the symping app, but this provides a general overview. From here it is possible to drill down into each app, opening a new workspace, and filtering it to only display metrics relating to the app you’re interested in, from there you can drill down even further to retrieve session metrics.

5) Packaging and release

Once the workspaces and datasources have been completed, they need to be exported and included in the apps distributable zip, they are exported in an XML format which will automatically be loaded by Logscape when the app is deployed in an environment.

Why not subscribe to our mailing list?