cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Could we monitor Progress OpenEdge DB using DCRUM??

shashi_krishna_
Inactive

Hi,

Could we do Progress OpenEdge Database monitoring using DCRUM? I had a look into documentation but find no clue, if anybody had monitored/monitoring the same could you please pass some piece of information or any references.

Thanks in Advance.

Regards..

Shashi

2 REPLIES 2

matthew_eisengr
Inactive

Shashi,

I don't believe we have an analyser for this as we would for say MSSQL or DB2; however, there are two approaches you can take depending on your monitoring requirement.

1) Define it as a software service using the generic with trans analyser which will give you basic TCP connectivity and volume stats (error, bytes transferred, etc.) and the operation times will based on the tcp session time instead of actual protocol timing. You'll also be limited in the sense that you'll not be able to see transactions as such.

2) Slightly more involved, but as long as the protocol is request/response protocol you could look into the Universal decode and write your own logic around the protocol. This would then give you protocol specific timings, transactions, and error codes.

Hope that helps!

Krzysztof_Ziemi
Dynatrace Pro
Dynatrace Pro

Matt is absolutely right. Postgress protocols are proprietary and we have no intention or plan to reverse-engineer them. For the same reason the approach 2) which Matt outlines, although theoretically possible, would most probably bring results below expectations.

One possible approach - very focused, so requiring good qualification - is to build an UD script that searches for presence of specific strings in requests and responses and counts/reports those, but does not attempt to measure transaction times. With such information one can detect e.g. presence of specific request strings or presence of error messages reported back to the user - assuming these are visible as plain, searchable strings. This way gauge of the specific app availability measurement can be devised, or a "canary" which detects specific (and well-defined in advance) usage scenarios.But this is probably as far as we can go, if this makes sense.

Best reagrds