Share this:

Like this:

I am grateful to you for creating dctmpy which I am planning to heavily use in my icinga2 monitoring environment. This work you have done is commendable. Earlier I was planning to write my own custom plugins using perl, then I figured out it is not gonna be easy considering the effort required to make Db::Documentum (which Scott created) work in D6+ environments. That is when I came across your wonderful work. I have successfully tested functionalities like login, sessioncount, targets, login etc.

I believe you have recently introduced a few modes. And as the documentation in emc community about dctmpy (https://community.emc.com/people/aldago-zF7Lc/blog/2014/05/19/monitoring-documentum-with-nagios-and-dctmpy-plugin) is not up to date, could you please provide some details about different modes like jobs, indexagents, acsstatus, timeskew, xplorestatus, query, method, indexqueue, serverworkqueue, countquery and how to use them. I will be especially interested in query and countquery. If this means I can run any query in docbase and compare the output against the thresholds we supply, that will be awesome.

At first, I strongly recommend to not consider Alvaro’s post as a guide to action, not because it’s wrong, but because configuring nagios *.cfg files is the same as writing sendmail.cf without m4 – my preference is to use opsview.

Before describing capabilities of dctmpy I think it worth to define what needs to be monitored and why, otherwise monitoring objectives are not clear – for example, I have tried to understand what ReveilleSoftware really does and after checking some presentations and youtube clips I got understanding that ReveilleSoftware just draw bars and pies :). So, dctmpy seems to be the only reliable monitoring solution for Documentum, others, if exist, are either based on DFC, which requires some extra setup or hacks, or other Documentum services, which makes them dependent on underlying service.

Docbroker service

Typical Docbroker issues are:

Docbroker is down – somebody forgot to start it or Docbroker failed or there are connectivity issues or attacker stopped docbroker

Content Server is not registered on Docbroker – misconfiguration on CS side or connectivity issues

DoS is caused by slow client or network problems, yes, it’s weird, but client or server with network issues could affect all Documentum infrastructure, so, it is always a good idea to use different docbrokers for different services

I belive all this situations are covered by nagios_check_docbroker, some example:

query – executes select statement and checks whether the count of returned rows is inside of specified threshold ranges (for checks described previously threshold ranges were trivial (i.e. “less than”), but for this check, I believe, you may want to specify more complex conditions like “count of returned rows must be greater than specified threshold”, see nagios-plugin documentation for threshold formats), additionally output might be formatted be specifying –format argument, example:

method – technically it is the same as “query” mode, but accepts only “execute do_method” queries and additionally checks value of launch_failed result attribute, I believe such approach to check health of JMS is more reliable than “jmscheck” mode (see below), example:

countquery – technically it is the same as “query” mode, but this mode assumes that query returns only single row with single attribute (actually it just picks up the first row and the first attribute in row), example:

workqueue – checks the total number of non-completed auto-activities for whole repository, actually it checks whether the configured number of workflow agents is sufficient or not, in some cases growth of workflow queue may indicate some issues either with workflow agent or with JMS, example:

indexqueue – checks indexagent queue size, it’s worth to combine this check with “indexagents” check, because, again, due to weird implementation of indexaget it may report “running” status, but does not process queue, example:

Because arguments host, port, docbaseid, username, password are mandatory it makes hard to create flexible setup in nagios (for example opsview allows to set only four arguments for template), so these arguments might be collapsed into the single one (host) using following convention (see previous examples):

For suppose, If we create a new xCP 2.2 Project “Project-1” and adopt a custom type say some_type and and then we can proceed and deploy this application. That is fine but in future if we want to create new xCP project “Project2” and the same custom type is required i.e some_type, we cannot adopt the type some_type in “Project2” because the type is already adopted in “Project1” so xCP designer doesnt’ allow by design.

So i’m thinking of creating a project say “BaseTypesProject” and then at first adopt all the custom types and when in future if we want to create new xCP project and wanted the same custom types, we will refer the “BaseTypesProject” as dependency project so that we can get all the types.

But for some strange reasons it looks like there is no way to make a Project as dependency project in xCP 2.2. Wondering what is the best way to solve this issue

I do believe that you may temporary “unadopt” adopted types on DEV ENV and import them into another project, check this topic on ECN.

What is the purpose of these security checks? Here I remembered my previous post about security where EMC employees were trying to perform some weird activity and found out that some proofs of concept described in that post “does not work anymore” (here I use double quotes because by tradition nothing was fixed at all – the purpose of this blog is just to give some thoughts about Documentum, if you blindly apply everything that is written here without further research you are bloody idiot):

on the third hand, vulnerabilities described in New set of Documentum vulnerabilities were “remediated” (note double qoutes) within 19 days, but instead of publishing clear information EMC announced POODLE-related bullshit. Interesting thing here is that EMC broke their SDLC policy: previously EMC support assured me that if I want to get some fix within official patchset (not hotfix) this procedure usually takes about two months – at the middle of the first month EMC performs feature freeze, after a month they perform code freeze and at the end of a second month EMC releases patchset. It seems that somebody decided to earn some extra KPI points for doing nothing.