Billing Probe issue - empty report

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

Billing probe is not working properly and providing blank output report, could you please help me to fix this issue asap as I need to provide data to auditor and its getting escalated due to this blank report.

Environment

• Release: UIM 9.0.2
• Component: UIM - USAGE_METERING/BILLING

Cause

• billing probe no longer used in UIM 9.0.2

Resolution

In UIM v9.02, the billing probe is deprecated and no longer used so we deactivated it and used the latest version of the usage_metering probe. We did the following:

1. Deactivated the billing probe
2. Deactivated the usage_metering probe
3. Renamed the usage_metering directory to old_usage_metering
4. Deleted the usage_metering probe
5. Downloaded and deployed the usage_metering probe v9.25 GA
6. Increased usage_metering probe java memory min and max to 2048/4096 via Raw Configure
7. Increased nim_request_wait_time to 300
8. Ran usage_metering scan
9. Successfully ran usage_metering billing calculation

Additional Information

References:

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/ca-unified-infrastructure-management-probes/GA/alphabetical-probe-articles/billing/billing-im-configuration.html 

Please also refer to the KB Article:
https://knowledge.broadcom.com/external/article?articleId=116690

Here is the actual query run by the usage_metering probe:

Jul 12 13:13:53:607 INFO  [device_usage_scan_thread, com.nimsoft.query.jdbc.QueryExecutor] Executing query with access id sqlserverRetrieveDeviceData query is 

select distinct cs_id,name,dns_name,probe_name,origin,ip,robot,dedicated
 from (select distinct
 c.cs_id, c.name,c.dns_name, q.probe as probe_name,q.origin,c.ip,q.robot,c.dedicated from
CM_COMPUTER_SYSTEM c
inner join
 CM_DEVICE d on c.cs_id = d.cs_id and d.dev_id not in (Select dev_id from CM_DEVICE_ATTRIBUTE where dev_attr_key like '%UMB_Ignore' and dev_attr_value='true')
inner join CM_CONFIGURATION_ITEM ci
on
 d.dev_id = ci.dev_id
inner join CM_CONFIGURATION_ITEM_METRIC met
 on
 ci.ci_id = met.ci_id
inner join S_QOS_DATA q
 on met.ci_metric_id =
q.ci_metric_id
inner join S_QOS_SNAPSHOT ss
 on q.table_id = ss.table_id
where ss.sampletime > dateadd(hour,-24,GETDATE())
union
 select distinct
 c.cs_id, c.name,c.dns_name,na.prid as probe_name,na.origin,c.ip,na.robot,c.dedicated from
 CM_COMPUTER_SYSTEM c
inner join CM_DEVICE d
 on c.cs_id = d.cs_id
inner
 join nas_alarms na
 on d.dev_id=na.dev_id and d.dev_id not in (Select dev_id from CM_DEVICE_ATTRIBUTE where dev_attr_key like '%UMB_Ignore' and dev_attr_value='true') where na.time_arrival >
dateadd(hour,-24,GETDATE())) as temp

-- which gets all inventory of QOS and active alarms and inserts this information into the into the UM_DEVICE_DATA table in the local usage metering H2 database. (usage_metering.h2.db).

For example:
Jul 12 13:13:53:737 INFO  [device_usage_scan_thread, com.nimsoft.query.jdbc.QueryExecutor] Executing query with access id selectDeviceData query is Select id,cs_id,name,probe_name,origin,ip,robot,create_date,fqdn from um_device_data where create_date between '2019-07-01' and '2019-07-31'  and cs_id='1' and probe_name='hub' and robot='xxxxxxx-L21401'

-- based on the UIM environment's inventory data, the UM probe then continues processing and selects hubs/robots and their associated probes, and counts them, again based on what is currently being ACTIVELY collected in terms of QOS and alarms.

If you'll notice, its not scanning the number of cdm probes for instance for usage data, its scanning based on the data that is currently being collected as per the entries in the S_QOS_SNAPSHOT table AND all within the last 24 hours from when the scan was run.

If the scan is run daily, which it is by default, that means it could change on a daily basis , e.g., if you/your customer's change the monitoring, disable/enable monitoring for a given probe, on a given date/day, then for example, any reports that span a month may yield unexpected results but they are still accurate.

Keep in mind that even if you disabled a probe mid-day, you still have some current data for that given 24-hr period which is what the query is based off of.

In contrast, if for example you have 5 instances of cdm, but your daily report shows only 4, it could very well be due to the fact that you disabled cdm QOS data collection a day ago.

To clarify, the old usage_metering probe version counted the probes, but the new version relies on the currency of the data collection and active alarms for the count of the probe instances.

The probe runs the same queries each day at the same time and scans daily.

You can run a monthly report All Origins but keep in mind that if the customer on their own, or the MSP disabled some collection, then the count results may have changed. usage metering is based on actual usage and the storage of QOS but if your also alarming, then it would still be included in the report (if your not collecting QOS). As long as the alarm(s) are active during the time in which the UM scan is run, then it will still be reflected within the report.

Again, usage metering is based on currently collected QOS data, as well as current (active) alarms. Therefore, in reverse, if you/your customer is not currently collecting QOS data or alarms are not currently active, then the report results will change accordingly.

In the past, the old billing probe yielded hourly, daily, monthly (more granular), reports.

In the current usage_etering probe, the "Start at" drop down selection for the date, indicates the time at which the scan is started, that is all.
========================================================================================