Hallett_German

TIM Deployment Failures and the Rebirth of a Documentation Classic

Blog Post created by Hallett_German Employee on Jun 19, 2016

Introduction
Some of the best documentation that I have ever created was out of strong motivation to improve dramatically a situation. The TIM Readiness Guide or as it is officially known as TIM Network Connection Readiness Guide -- Setting Up and Validating a TIM Network Connection for all CEM/APM Versions was no exception.

 

Dooming a TIM deployment.

Along the way, there are a series of things that can be done ensuring a TIM was ready to monitor traffic before a successful Services engagement. Those that did so generally ran into no monitoring issues. Not being completed meant that the engagement was highly likely to have difficulties hindering completion. This is one area you should not wait typically until the engagement starts.

 

Typical failure points were:

1) Tim being placed in the wrong place. So it was not seeing any traffic, traffic from the wrong subnets, or seeing one-way traffic. This also could be impacted by load balancers, firewalls, and reverse proxies.

 

2) Connection between switch and TIM misconfigured or not optimal. So the unneeded protocol traffic was sent to the TIM was sending more data than the TIM could handle (resulting in dropped packets, or traffic sent was of different speeds (resulting in high out of order packets.).

 

3) TIM installation not approved by a client's security group.

 

4) Private keys not obtained or deployed successfully.

 

5) Application groups giving incorrect information on which IP addresses to monitor. Or it was not decided in time which applications to be monitored at all.

 

The interesting thing is that many of these were avoidable with proper planning. Proactive sites successfully performing the required tasks generally meant that Services would have a smooth engagement.

 

Not completing this meant the engagement could be delayed or never completed. In those rare cases that this was discovered after the fact, the Services person could be sent home until the environment was ready.

 

The TIM Readiness Guide
Out of the desire of wanting all engagements to be successful,, I created the TIM Readiness Guide.


It basically takes you through a series of questions and steps to verify that your TIM is truly ready to monitor traffic. I tried to also make it easy to do and verifiable.

 

Over the years, this Guide was expanded to include APM 9.x, more on SSL, TIM networking tools, MTP, the APM Field Pack, and more. It has saved countless deployments from starting off on the wrong foot.

 

It also was provided as part of a starter kit that included a site application monitoring questionnaire, a readiness checklist and deployment schedule. A high-level document on TIM setup was also sent to CA project managers.

 

The TIM Success Guide

Tired of travelling each week, I moved over to APM Support. And I learned all about the TIM over again from a different perspective. I started to see how an equivalent effort was needed to keep the TIM healthy after deployment. Proactive administration meant not seeing sluggish performance, crashes, dropped packets, delays to reporting or no reporting at all.

 

So that's when I decided to do a rewrite of the TIM Readiness Guide to talk about the major things (many that are simple) to detect an unhealthy TIM and how to rectify it. The new name is the TIM Success Guide. I expect part one (Overview) to be out shortly. Early reviewers have found it helpful.


The TIM continues to be an undocumented and underdocumented area of APM. I am trying to rectify this by writing an onslaught of KBs, Tech Tips, and blogs. I don't plan to stop anytime soon.

 

Thank you to those that had shared this journey and provided me feedback on how to improve these documents.

Outcomes