#Monitoring

Hi,

When we write unit test cases for cache object script code using %UnitTest.TestCase, what is the best way to write code to identify code coverage?

So, let say my unit test case hit all 10 lines of code of a method for a given class. So, unit test coverage should be 100% for that. But, using line-by-line coverage [(%Monitor.System.LineByLine] getting wrong percentage, because it also includes code comment/documentation as part of code. So, practically we can not ever achieve 100% of code coverage by using this API.

I am looking for a database management tool I would have expected to find something like on the SMP website

Aim

show current database usage (ie size allocation) by database then table etc and allow continued drill down,

show information as a table, so can then sort by size to find the biggest item easily

also show it graphically

And then have ability to track and trend growth in size over time

identify a normal growth pattern

alert if variation (higher or lower) from normal based on recent trend

First post! In order to somewhat redeem myself for an unnecessary call to support, I've decided to post some classes that I've written to monitor certain metrics inside our Ensemble Live instance (yeah, Kyle, you WERE laughing at me, but it's okay). What the classes do is to run queries and code to get database sizes, status of the mirror, counts of rows in tables such as EnsLib.HL7.Message and Ens.MessageHeader. The data is collected and written to tables and then an email is sent out daily upon completion. I've found this quite useful in keeping an eye on what's going on. It's help

Presenter: Barry Cooper
Task: Enable users to perform analytics within an application and take actions based on those analytics
Approach: Provide examples of embedding DeepSee within applications

Analytics is more than just using data to provide insight. Analytics is about taking action on that insight. See examples of how you can embed DeepSee in your applications, allowing you to take action.

Content related to this session, including slides, video and additional learning content can be found here.

Presenter: Kerry Kirkham
Task: Prevent application-to-application interface problems from escalating
Approach: Give examples of using alerts to get the right person working on a problem as soon as possible

Problems with application-to-application interfaces are inevitable but in most cases they can be fixed with little disruption as long as the right person gets to know about it as soon as possible. But delays in attention cause problems to escalate, pressure mounts and business suffers. This session looks at how monitoring and alerting can be set up to recognize problems and get the right person working on the problem in the shortest possible time so that small problems don’t turn into major issues.

Solution: Using alerts to minimize interface problems

Content related to this session, including slides, video and additional learning content can be found here.