Monitoring Tridion Publishing with Tridion Application Monitoring

SDL Tridion introduced Application Monitoring as part of the SDL Tridion R5.3 GA release. This functionality enables Administrators to monitor certain aspects of the environment to ensure optimal uptime of essential processes. Tridion Application Monitoring can be extended to enable Administrators to monitor even more than what is delivered out of the box.

Why monitor publishing?

Publishing is critical to an organization's ability to respond to changes in their online presence to ensure minimal time to market. Thus, it is important that the workload of the publisher is monitored for performance and load. In this case we will look at one part of the publishing, the length of the queue.

Backlogged Queue

In the unlikely event of a failure the publishing queue is likely to become backlogged with publishing requests; in this case the total number of items waiting will continuously rise. However, it can also occur that allot of items have been submitted to the queue either by mistake or as part of a republish process. In that case an Administrator might want to take action by either removing items or simply monitoring the queue. In order to be able to take action, there needs to be a notification mechanism. 


Application Monitoring allows Administrators to extend the features of its monitoring; one such way  is to add a HTTP Service Health Monitor. Basically this calls a URL and processes the response for a known string. This string does not have to say much just it has to be what Application Monitoring is expecting. If the response does not return the expected result, an error is raised. That error can be trapped using SNMP and after that System Administrators can be notified. 


In this example we decide to raise an alarm when the number of items in the queue exceeds 100. To do this we need to check, through the Tridion API, what the current count on the queue is and then respond accordingly. When everything is fine the page will return "Monitoring TestPage". When the queue is too long we want it to say something else, in this case the state. For example: "Error, number of items in the queue exceeds limit. Queue is now at: 4000000 of a max of 100 items".

The code

Using the COM Interop for .NET this can easily be done from a .NET application. As we are using a webpage to display this result it should be an ASP.NET page, but it could equally be written in any language.  For this example we will cover the basics of what an Administrator can do. For the complete example, see the download . 

We start by importing the namespaces of the COM Interop as well as the XML handler:

<%@ Import namespace="TDS" %>
<%@ Import namespace="System.Xml" %>

Next we create a new TDSE object of Tridion, XML Document and Node List:

TDSE tdse = new TDSE();
XmlDocument itemsXmlDoc = new XmlDocument();
XmlNodeList itemNodes;


Next we set the user we want to use for accessing Tridion, in this case the REMOTE_USER and initialize TDSE. 

tdse.Impersonate(Request.ServerVariables["REMOTE_USER"]);
tdse.Initialize();


From that we are authorized to Tridion and can then get a ManagementInfo object which will enable us to look into the queue of Tridion: 

ManagementInfo managementInfo = tdse.GetManagementInfo();
ListRowFilter filter = tdse.CreateListRowFilter();
filter.SetCondition("InfoType", queue);

List row filters (above) enable us to filter the results, in the case the variable queue specifies a string which is the queue we want to look at. Using the filter we can call GetListPublishTransactions and load the resulting string as XML: 

String itemsXml = managementInfo.GetListPublishTransactions(filter);
itemsXmlDoc.LoadXml(itemsXml);


Once we have done that, we can select the elements that represent the publish tasks and display our text: 

itemNodes = itemsXmlDoc.SelectNodes("tcm:ListPublishTransactions/tcm:Item", namespaceManager);
int itemsCount = itemNodes.Count;
if (itemsCount > maxItems) {
    %>Error, number of items in the queue exceeds limit. Queue is now at: <%=itemsCount%> of a max of <%=maxItems%> items.<%
} else { 
    %>Monitoring TestPage<%
}

After we have created and tested our page we need to add it to Application Monitoring so it monitors this page for changes.  

Configuring Application Monitoring

Application Monitoring is configured through the configuration file cd_monitor_conf.xml which is located in the directory %TRIDION_HOME%\bin. To monitor a queue we need to add the following to the ServiceHealthMonitors section:  

<HttpServiceHealthMonitor ServiceType="Publishing Queue Length - WaitingForPublish" ServiceInstance="local" PollInterval="5m" TimeoutInterval="30s">
<Request URL="http://localhost/MonitoringView/Monitors/publishqueue.aspx?queue=1&amp;max=100"/>
<Response SuccessPattern="Monitoring TestPage"/>
<Authentication Scheme="NTLM" Host="host" Domain="myhost" Username="administrator" Password="tridion"/>
</HttpServiceHealthMonitor>
 

This element tells Application Monitoring to periodically monitor the URL specified for the specified text. Of particular interest are the ServiceType (the name of the service to change) and the PollInterval. The PollInterval specifies the amount of time between checks of the status of this queue. It should be short enough to react to any change in state but long enough not to overload the server. 


Our URL can also be configured. The URL has two parameters, queue and max. Queue is the string (actually an integer but this is a URL so it is actually a string) that identified the queue being monitored and is specified as follows: 

  • 0 = Scheduled for Publish
  • 1 = Waiting for Publish
  • 2 = In Progress
  • 3 = Scheduled for Deployment
  • 4 = Waiting for Deployment
  • 5 = Failed
  • 6 = Success         

The max value simply indicates what the maximum number of items to allow in the queue before the alarm is raised. 
Once configured, we restart the Tridion Monitoring Service and check the URL of the Application Monitoring webservice:  http://localhost/monitoring/TridionMonitoringAgent.asmx. If executed this from the localhost, we will have the option to invoke the webservice and get a XML response back. In this response we can check our new monitor is responding correctly. 

Using this Monitor

There are two basic ways to use this new monitor together with the standard monitors: 

  • Write a application to read the Application Monitoring Webservice
  • Setup a monitoring application that can catch SNMP traps        

In the case of the latter, all the monitors including the one we have setup will send SNMP traps when the state changes. This allows us to integrate this monitor into any existing infrastructure management processes.

More information

Find out more information on Application Monitoring by checking the R5.3 documentation or visiting the SDL Tridion Forums or SDL Tridion's Community World.

 

About the Author
Julian Wraith
Principal Consultant

Julian Wraith is a Technical Account Manager with SDL Tridion and has worked with the company for 8 years. He specializes in infrastructure related matters and is a Certified Consultant. Next to helping customers with their WCM needs, Julian is instrumental in many of the Knowledge Sharing activities at SDL Tridion. In the past, Julian has arranged the quarterly knowledge sharing between customers, partners, certified consultants and SDL Tridion. He was also a SDL Tridion MVP in 2010 and is the recipient of a SDL Tridion Community Builder Award for 2011. You can follow him on Twitter and via his personal blog.

SDL CMT division

Related Downloads