Complex DataPoint.

Hi Stuart and Mike,

I want to commend you both for your proactive responses to the issues on this forum and express my gratitude for the solutions you have offered.

I used the expression that Mike recommended, and it was effective.

Thank you, and keep up the excellent work.

Thank you for your valuable feedback/comments.

Let me walk you through the entire scenario,

Data I am polling through the data source's collection method ( PERFMON) For SQL server Analysis service memory metrics

Below are the data points I have created. 

Now Upon This I have created one complex datapoint for the condition
(if 'Memory Usage KB is greater or equal to 'Memory Limit Hard KB, then trigger alert)

By using Infix expression I achieved this. 
if(gt(MemoryUsageKB,MemoryLimitHardKB)1,0)

But instead of returning 0 (since this is false ) it's returning 1 (as true) 

(((

The expression if(gt(MemoryUsageKB,MemoryLimitHardKB),1,0) should return 0 when MemoryUsageKB (3298832) is less than MemoryLimitHardKB (132120162). Given the values you provided, let's break it down:

Comparison: gt(MemoryUsageKB,MemoryLimitHardKB) translates to gt(3298832, 132120162).
Evaluation: Since 3298832 is not greater than 132120162, gt returns false.
Result: The if statement should return 0 because the condition is false. which is not)))

I have been told to use Groovy to achieve this calculation since the infix expression is failing to do so.
So, I need to retrieve the values of normal data points in a groovy complex data point to calculate big values. 

Do you mean that the normal datapoint MemoryUsageKB is returning a string to LM that looks like "1.23456789E13"? Or is LM getting the large number and displaying it in scientific notation on the raw data tab?

To know what is actually being returned, do a poll now and scroll down to the bottom of the poll now dialog box. It'll show you the entire blob of text returned through stdout to LM. That will show you if the returned value is actually a string containing a number in scientific notation or not.

If it's the latter (suspected), Mike_Moniz's comment about it just being LM displaying it that way in the raw data tab is the thing to notice. If the collection task returns a super large number, that super large number is stored in the database. When the raw data tab displays it, LM converts it to scientific notatation at runtime. The underlying value is still just an integer (probably a double due to the size). In that case, you can just use a regular complex datapoint converting the value to bytes by multiplying by 1024 or convert to GB by dividing by 1024/1024. 

If it's the former and the task itself is returning a string, not a number, is this not a scripted collection task? If it's scripted, obviously it would be better to convert it before outputting it so that the normal datapoint has it in the units you want. If it's not scripted, you will have found the first actual use case I've ever seen for a groovy based complex datapoint. I don't think output is an array, it's usually the entire blob of text as output by the collection task. So you'd first have to parse the output to get the normal datapoints and their values. Then you'd need to make the conversion from sci-notation to an integer, then you'd need to return that value using a return statement.

I personally haven't used groovy complex datapoints but looking at the documentation at https://www.logicmonitor.com/support/logicmodules/datasources/datapoints/complex-datapoints#groovy it looks like the normal datapoints are in an "output" array so I assume you can use something like this:

memoryUsageKB = output["MemoryUsageKB"]

I'm not sure if you even need to add "long" or "double" to the beginning of that line though. Note that the scientific notation is just how the raw tab is presenting large numbers, other parts of LM doesn't do that. It's actually not stored in scientific notation in the backend. I personally would just keep it as a int/long (without decimals) when doing the math, even if you need to convert it to the bytes first.