A short-cut on putting a Wire Data solution into actionIn our day-to-day practice as relation therapists for cloud services, applications and networks we have learned that putting a Wire Data solution into action is experienced as a challenging, complex task. Most of the time the concerns are related to not having visibility on the complete application chain.
Fortunately, the low hanging fruit when starting with end-to-end performance monitoring is about rationalizing and prioritizing user complaints. Meaning complete visibility on the application chain is not required to get started.
This is because in today's hybrid, software defined infrastructures the by far largest grey area is the combination of security zones and related, different types of WAN connections (Wide Area Network); including the local internet ones and the security layers on top of that.
This allows us to simplify and standardize the solution deployment with 3 easy steps:
- Setting up the data collection part for the front-end
- Modelling the incoming Wire Data
- Validate the configuration and the initial results
1. Is it the end-user device, the network, a cloud service or an application?
2. And if a combination of these, to what extend each and where to start improving things?
Combined, this helps your IT organization in preventing time-consuming conversations about which party (or parties!) to involve when improvements are required like yesterday.
Step 1 - Setting up the data collection partSince this is a Wire Data setup we need access to packets through port mirroring (also known as span ports) and taps (combined with aggregators).
Port mirroring is something that is configured on a network device and is about copying packets to a specific port on that network device.
A tap is about connecting a device in-line between 2 network devices. This device then copies all incoming data to one of the 2 outgoing ports.
As a rule of thumb we recommend the following:
- Taps are used for collecting data between 2 network devices like for example routers, switches, load balancers and firewalls.
- Port-spanning/port-mirroring is used for data collection about the hosts connected to a network device and hosts running on a hypervisor.
Typical use cases for port mirroring are monitoring the user experience in offices as well as monitoring the performance between to or more virtual machines.
More information on the pro's and con's about taps and port-spanning/port-mirroring is found here and here.
Once this stage is completed, the monitoring solution is connected and the data collection starts; moving forward to modelling the incoming Wire Data.
Step 2 - Modelling Wire DataModelling Wire Data is all about translating the raw data into easy-to-understand dashboards and reports. Assigning data to groups representing applications, locations and hosts already covers 80% of the configuration work for improving problem resolution times. This is because:
- Each location group represents a certain group of end-user devices.
- Each host group represents a certain group of systems related to a security zone in a data center.
- Each application group represents a certain group of systems and/or cloud services belonging to a certain application chain.
The remaining 20% is related to making a jump start on the plan-do-check-act cycle for embedding this improved troubleshooting workflow in your current processes.
We recommend starting with 3 reports as common ground for making his happen:
- A daily report covering day- and night-time (i.e. from 7 AM to 7 PM and from 7 PM to 7 AM).
- A weekly report covering from Monday to Monday; both at 7 AM.
- A monthly report covering 1st day of the month to 1st day of the month; again, both at 7 AM.
The combination of 3 group types and 3 reports allow your teams to make significant improvements on reducing problem resolution times.
Step 3 - Validate the configuration and the initial resultsOnce the Wire Data is modeled, we run a quick health-check of the monitoring system to make sure everything is working as expected:
- The utilization of the data capture interfaces.
- The amount of packet drops (if any).
- The CPU, memory and disk utilization of the monitoring solution.
Where to go from hereThis completes our best practice about a jump start on end-to-end performance monitoring. Unless agreed otherwise, the approach outlined in the previous 3 steps is the core of our offerings called Health-check and Visibility-as-a-Service.
Use this form to get your copy of the report examples and a one-pager guiding you in the interpretation. Please note that depending on your browser and its settings a new window is opened.
If you need more technical details on how we do this then we recommend having a look at part 1 from of a case studie about a Health-check on Citrix/SAP.