Cetrus Blog

Reading log files means getting coarse data

Posted by Erik Hoogerhuis on Jan 27, 2016 7:35:42 PM

Data reporting requires accurate data. While the data may be accurate, the granularity or degree of precision of the data impacts what the data can be used for. In addition, the timing for when data becomes available can restrict the data’s usefulness.

We’ll talk about the impact of data availability timing in our next post. For this post, we’ll look at coarse grained data – specifically data from license log servers. Let’s assume that a license server records every time a license is released and when that license is returned. The data available for reporting is the duration the license was checked out. At any point in time, the log can be queried to show how many licenses have been checked out.

To get more value from the data, additional context needs to be provided. This is where data coarseness becomes limiting. For example: If you were to capture a month’s worth of data, you could see when licenses were checked out, and perform calculations to understand the average duration for license check-out, see duration by license type, trending for peak utilization, etc. – all very useful information.  What you can’t see is whether the license was being used or not, and if it was being used, when, for how long, etc., while it was checked out.

Managers tasked with understanding actual license usage need more granular and precise information than available from log files. They need to know whether the license was being used while it was checked out. They need to know what the actual peak utilization was, which might be significantly different from license check-out peak utilization reporting.

We’ve heard many stories from customers about engineers who check out a license when they first get in, launch a file, and then park the application. The license server will show the application as active. Monitoring at the desktop allows organizations to understand the true nature of usage. For instance, desktop monitoring would identify that the license has been parked and for how long, so that administrators could take corrective action, or peak utilization and usage trending could identify these kinds of behaviors.

For those companies that need to track usage for reimbursement, chargeback or resource utilization, having data that is significantly inaccurate or which can be fairly easily bypassed can have significant impact. This includes improper over- or under-billing, or misaligned resources. No monitoring system is perfect, but there is no excuse for having such poor data.

One of the biggest on-going struggles with license usage is understanding and being able to reduce the difference between what the organization is licensed for, let’s say, 100 concurrent sessions, and what it is actually using. Reporting from the license server might show that peak utilization of the licenses is 95 users. In this case, the organization is over-licensed by 5%. If the goal is to never have a License Denied Message going out, then the next questions center around how often the 95% peak utilization happens, how much time the licenses are used at peak level, and what does the underlying usage look like vs usage spikes. 

If the best picture an organization can get is 30-minute accuracy (some license servers have options files that release licenses if they haven’t shown usage for 30 minutes), then the organization doesn’t have a very granular view of usage, especially if users are “locking down” licenses. We think more granular data is a requirement for adequate license usage reporting.

If you want to see what actual usage looks like, give Process Meter a try. Send us an email at com, and we’ll set up an account for you.

Topics: Insider