Documentum Monitoring – platform logs’ centralization using Logfaces – Part 3

This is the last post of a series that aims at presenting a proposal for a cheap but yet (I think) robust solution for the centralization of Documentum platforms’ logs, and which can be of great help for someone who would like to implement a non-intrusive but yet very powerful real-time monitoring system.

Part-2 of this posts’ series was presenting the steps to go for in order to instrument the Webtop and JMS components. This post will give the steps to instrument the following components: Content Server, Docbroker, xPlore and CTS (Content Transformation Services).

Documentum Monitoring – platform logs’ centralization using Logfaces – Part 2

In a previous post, I presented the very big lines of a proposal for a simple but yet (hopefully) powerful centralization of logs on a Documentum platform I’ve been now using for more than one year. If you haven’t read this first port, I’d recommend reading it.

This second part aims at giving you a practical preview – a taste – of the solution in short time. In short, the aim is to have your Documentum environment instrumented and real-time monitored in 30 minutes!

A tool to export Documentum (custom) object model as a graph

One of Documentum’s strengths is its strong object orientation and the possibility to define custom object types (the so-called doctypes) which inherit both attributes and behaviors from their ancestor type.

There are many cases when exporting a portion or the complete types’ hierarchy of a given repository in a readable format is really useful:

Documentum Monitoring – platform logs’ centralization using Logfaces – Part 1

During the last years, I’ve been frequently working on Documentum platform end-user application performance monitoring and Documentum monitoring in general. This work resulted in the implementation of a monitoring platform based on two solutions:

1. a system for running script-based platform sanity checks, running active interface monitoring, DQL query monitoring, etc… I will give details about this “back-end” monitoring system in a future post.
2. a system based on the centralization of logs produced by the major components of the platform