Showing posts with label data. Show all posts
Showing posts with label data. Show all posts

Friday, 17 June 2016

Types of Data required (6 of 17) Capacity Management, Telling the Story

Today we'll be looking at the types of data required.
Technical data – in ITIL terms our data should be coming from business, service and resource levels. This data is then fed in to our CMIS and allows us to see what is happening in two ways: 

•        Current – how everything is performing now

•        History – the more historical data we have on our systems and applications the more accurate our trending and modeling will be.

Business metrics – what is happening in the business will dictate the resources needed to support it. 

•        Current – what is happening now in the business

•        Forecast – what is planned for the future, in terms of growth, new services, increased user numbers etc

Key Performance Indicators – we need some idea of how we can measure our performance going forward.

Threshold levels – we need to know what thresholds we are going to be planning towards to enable us to put them on reports and see when/if they are going to be breached.

Capacity Management

 The diagram below shows 360°Capacity Management. A combination of our capacity management software athene® and SharePath allows you to bring resource, application, application transaction response times, service, business data and KPI’s to your CMIS. This allows you to build the most accurate picture of your environment as you can.

For more details of athene® and SharePath visit our website.
http://www.metron-athene.com/products/index.html  

On Monday I'll be running through a selection of the types of presentations that you can use. 
Charles Johnson
Principal Consultant

Monday, 11 April 2016

Data -Top 5 Key Capacity Management Concerns for UNIX/Linux (6 of 12)

To produce and analyze the recommended performance reports we need to capture and store performance data.  This process is normally performed by installing an agent responsible for running UNIX/Linux system tools such as SAR, VMSTAT and IOSTAT to capture information or running (potentially intrusive) kernel commands. 

As with any data capture whether it is local or remote you’d expect to incur some overhead.  Typically agents should incur no more than 1% CPU usage when capturing data, however as mentioned some agents may incur more.

In addition when capturing data, can you rely on what it is reporting?  Remember this is software and software can contain bugs.  But you say ”we have to rely on what the operating system gives us”,  and this is true to some extent.  From my experience there are several tools to provide this information within the UNIX operating system – some are accurate and some are not. 
For example:  Does your Linux system have the sysstat package installed and is it an accurate and reliable version?  Or in Solaris Containers are the Resident Set Size (RSS) values being incorrectly reported due to a double counting of memory pages?  An example of this is shown below.

Zone Memory Reporting




This report is an interesting one.  It shows the amount of RSS memory per zone against the Total Memory Capacity of the underlying server (Red). 
Because RSS values are double counted the sum of RSS for each zone far exceeds the actual Physical Memory Capacity.

I'll be looking at Linux differences next, in the meantime don't forget to register for our 'Unix & Linux Capacity Management' webinar http://www.metron-athene.com/services/webinars/index.html

Jamie Baker
Principal Consultant