System Management and Monitoring

                               System and Application Monitoring Features

 

Top 10 things I learned regarding systems management/ monitoring:

 

Everyone has their own idea of what the monitoring tools should be. The consultant must not make it personal and remind the customer that you are both there to implement what the organization decided was the best in breed. Take notes of any complaints to address later.

 

Always interview several roles of users of the monitoring system to determine requirements; the owner (will tell you what sort of reporting, alerting, views etc they need for monitoring), the operator (will tell you what they need to be able to trouble shoot a problem), the users (what sort of general problems to they already observe like performance) and the application owners (what do they do now to know that they have a problem with their application). Note that these requirements may conflict and you may need to have a meeting to decide on the final approach.

 

Make sure you have done this before and have access of the physical hardware and software for the time you need. Make sure if the customer is not always with you, someone is listed as the project leader that you can call if you need something.

 

Have an agreed upon schedule and list of participants needed from the system and/or application group and when you need them.

 

Always listen to and keep the customer and other stakeholders informed during deployment (or testing of deployment).

 

Do a staged approach of monitoring; that is basic monitoring first (like ping the server, see if the services are available, do a basic synthetic transaction). Then add on features until complete.

 

Have daily meetings where you list issues and what their resolution will be. Review schedule and issues each day. Write down the results of all of these meetings

 

Have the user run through an agreed upon test of the system for acceptance and record all issues.

 

Hold a “lessons learned” meeting to see what went well, what could be improved on and what left over issues need resolving and what the plan for that is.

 

Have the customer “sign-off” on the system acceptance.

 

Things That Must Be In Place for a Solid Systems Management and

           Monitoring Solution:

 

Ease of use.

 

Training and detailed documentation should be available.

 

Failover and redundancy should be available.

 

Auditable data for any compliance issues with alarming, notification and logging.

 

A Web UI with network topology graphs and synthetic transactions should be available.

 

The system should be scalable and reliable.

 

The system should have a configurable, graphical view of major counters to display in dashboard or “my page” type of view.

 

Printable reports that can be exported to excel and emailed to staff.

 

Group and role definitions should be available with security access levels so you can assign access to certain roles (can/can’t change data) and group like “operators”.

 

The product should provide log scraping, disk space monitoring, CPU monitoring, memory statistics, and some performance counters.

 

Things that Should NEVER Exist in a quality Systems Management and

           Monitoring Solution:

General user required configuration. The operator should be able to get a user set up so they can just use the system with the supplied UID and password.

 

Obvious use of multiple products, except in the case of data feeds from an element manager such as Cisco networks or something.

 

Multiple logins required to do different functions.

 

There should not be a lack of the ability for I18N and L10N for international markets for any large company use.

 

There shouldn’t be any backdoor ability that allows data to be corrupted.

 

A lack of change control procedures and role/group definitions. Also, the customer should have an online component that identifies who makes a change, what it used to be, and when it was made.  This change log should be backed up in a historical database and archived for any amount of time.

 

The lack of a secure database is unacceptable.

 

 

No ability to customize to meet customer needs; although the rule should be to not have a lot of customization or the user will get out of sync with new releases.

           

   No way to turn on some debugging feature to gather extra data.

 

   Poor documentation is worse than no documentation.