I just got back from Data Centre Dynamics London, and I have tons of posts and observations from the conference I need to write up. One of the things I figured out watching OSIsoft’s Martin Otterson and Iberdola’s Miguel Chavero present on
Command & Control
Connecting the Dots in Data Centre Automation (DCA): Controlling the building and integrating IT systems
Martin Otterson - OSIsoft
Miguel Chavero – Iberdrola
is few people are driven almost to an obsession to monitor systems. As all of you know monitoring a data center is no easy task. Even though the group of people came to the session to hear Martin and Miguel discuss data center monitoring it was amazing how few people had monitoring in place. I think I am hanging out with too many people who take for granted using PUE as one of their tools to measure data center efficiency.
One guy who stuck around to ask questions was from http://www.syska.com/, but otherwise it seemed like users want the monitoring, but it is too hard to add instrumentation/monitoring after the fact. Could you imagine how hard it would be to add the equivalent of the Prius hybrid monitoring system after the fact. Isn’t it more cost effective to have monitoring built in as part of construction? Of course yes. This is what Google and Microsoft do, but why don’t others make monitoring part of their RFP?
I had previously mentioned the auto monitoring device scan gauge in a post, and decided to buy one as neither of my cars have a MPG gauge. After 3 weeks of using the device it gave me better information about my cars that typically only the mechanics get to.
I needed to take my car into local Washington State Emissions test site for an emissions test. I was standing in the safety area waiting, and the technician was taking a long time, then I realized he was having a hard time finding the OBD connector.
On-Board Diagnostics, or OBD, in an automotive context, is a generic term referring to a vehicle's self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since the introduction in the early 1980s of on-board vehicle computers, which made OBD possible. Early instances of OBD would simply illuminate a malfunction indicator light, or MIL, if a problem was detected—but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized fast digital communications port to provide realtime data in addition to a standardized series of diagnostic trouble codes, or DTCs, which allow one to rapidly identify and remedy malfunctions within the vehicle.
I told him he needed to unplug the scan gauge and then he could plug in his test equipment. He asked what it was and what it did. He said, “it’s too bad more people don’t have devices like this.” He’s seen people drive for 18 months with engine codes blinking and they don’t get their car fixed as they don’t know what the blinking light means, and their car will have a higher probability of failing the emissions test. At the end of the test, he continues “you pass of course, as you know everything is working.”
I used a similar device to figure out the evaporative fuel system had caused the check engine light to go on in my wife’s car. Talked to our car mechanic, and he suggested trying to tighten the fuel cap. Ridiculously simple to fix with the right tool.
Just like a car has built in instrumentation, data centers need to have built in instrumentation. Slowly more and more people are starting to get this, and the good thing is some of my friends are getting permissions from customers to tell their stories.