IT Troubleshooter | Harper Mann | May 2006

MORE ENTRIES

May 2006

May 22, 2006 | Comments: (0)

What do the "type-ahead" features on many mobile devices and the "auto formatting" feature in Microsoft Word have in common? They're both infuriating when you're in a hurry to complete a message or doc, and the thing is urging you in a direction you don't want or need to go. For all the intelligence they build into software, humans still tend to know exactly what they want before the machine does, and sometimes the "AI" stuff can be more annoying than productive.

I think the enterprise IT equivalent to these types of consumer AI snafus is when false positives trigger unwanted alerts or events.

We're all familiar with the email spam filtering problem. If you put the filters on strong enough to keep the spam off, you're also invariably going to block some valid messages.

Then you have the content monitoring systems, where keeping proprietary company info from being divulged electronically is the impetus ... and intelligent agents block certain emails from being transmitted. False positives with these types of systems are extremely disruptive to business productivity. Btw: here's an interesting Computerworld article about content monitoring systems.

The new class of intrusion detection systems, meanwhile, are getting more sophisticated at blocking unauthorized users and putting them into honey pots -- where they get locked out. But as the mousetraps get better, it becomes tougher to enable the people on the "white list" to consistently have the access they need, and the configuration complexities are increasing. This recent Network World article talks about common false positives specific to Wi-Fi intrusion monitoring.

And with the big network and systems monitoring tools, the annoyances typically manifest themselves in the form of "false negative" alerts rolling in for events that are not important -- where the help desk gets pinged with too many irrelevant or insignificant alerts, you have noise that may block out the REAL problems or situations that need attention.

The bottom line across all intelligent agents and alerting systems is that they're only as good as the human touch on the back end that's fine-tuning them. Each require constant input -- alerting the system to new resources in an environment; correcting false-positives or false-negatives as they happen so the system can 'learn;' etc. So while organizations are sold on the autonomic / automated functionality of these systems, each typically require a significant tax in the form of human labor for babying them along and teaching them about the desired result.

Posted by Harper Mann on May 22, 2006 12:15 PM

May 18, 2006 | Comments: (0)

Open Source Giving Customers More Leverage Against Management Vendors

Last week the Financial Times weighed in on the fundamental flaws in software licensing models, and the fact that open source and other innovation is giving customers some leverage to end the abuse.

One related trend that I'm seeing -- for the monitoring and management products -- is that customers are also sick of commercial iron tools that put the burden of complex engineering and integration work on the customer. As many of the big systems software vendors have grown and added to their product lines via acquisitions, they add robust, fancy agents to their product lines that may provide some additional functionality ... but increase the complexity of installation / configuration / ongoing management for the customers, and tend to be used by only a small fraction of customers.

There was a very good article from Nicholas Hoover at Informationweek that explained the related growing pains for CA Unicenter ... and the article gave a great snapshot of the new pressures that customers are placing on their systems monitoring / management tools.

Posted by Harper Mann on May 18, 2006 05:45 PM

May 17, 2006 | Comments: (0)

Tracking Application Performance Getting Trickier ...

At the recent Interop event, I was really amazed by how many exhibitors are hawking application performance solutions. Literally, you can't walk more than 50 feet in any direction on the exhibit floor without seeing some booth personnel dressed like a pit crew member, waving a checkered flag and yelling into a megaphone about application speed, reliability, uptime, etc.

Now what's interesting to me is the way that development trends these days are going to change the game with respect to how application performance is monitored and managed, and how infrequently I heard these new trends being discussed in these vendors' pitches.

Consider a few of today's hot application development trends, and how they are likely to impact that way that app performance is monitored in the future:

AJAX -- Ann Bednarz at Network World had an interesting write-up yesterday where she canvassed a number of folks about the practical considerations for implementing AJAX. One of the points made near the end is that because of the predictive nature of AJAX and how it fetches extra data in anticipation of demand - AJAX apps tend to put extra drag on the network. AJAX is one of the really hot application development approaches today (especially for web applications), so we're likely to hear more increasing discussion about the performance issues associated with deploying rich AJAX applications.
MASH-UPS -- With XML and Web services, we're seeing many more corporate developers today that are writing applications that call a bunch of applications on the back-end. The mash-up craze so far has been pretty consumer-focused, but it's starting to creep into enterprise application development discussions as well. So the implication is that as more applications start to communicate with more databases and security systems, the sheer number of subcomponents that one must consider when evaluating application performance goes up considerably.

SOA -- InfoWorld has given a ton of discussion to service-oriented architectures, and while there are a wide range of opinions about how wholeheartedly SOA is being deployed by customers today -- there's no question that monolithic apps are being replaced by services. As Nemertes analyst Andreas Antonopoulos pointed out at Interop, however, with the flexibility of SOAs also come some new management issues. If instead of one 4-tier web app for CRM or ERP you are now running a collection of 100,000+ web services that create a composite application -- how do you manage these with the big, top-down management apps that so many customers use today?

While at Interop, I also enjoyed NetworkPhysics' "It's not the Network" t shirts -- which point to the fact that whenever something goes wrong for the user, the poor network guy is typically the first one that gets blamed when the finger pointing begins. But with the explosion of subcomponents (and connections between these components) in the typical IT environment today, chances are that the fingerpointing is going to continue to get more and more complex as we move ahead.

The classic, network-centric approach to monitoring applications is to leverage sentries to look at packets going by on the network to determine a specific application's latency and performance stats. This approach originated with RMON (remote network monitoring management information base) in RFC 1757 in the IETF, and it requires a good characterization of the architecture of your system, and understanding the relationship between the given application's connections to servers, databases, authentication systems, provisioning systems, and any other touch points that have I/O and could potentially be a bottleneck.

Developers often also run "synthetic transactions," where you drive the GUI through an associated user activity, and monitor the execution of the task and note any problems before the application goes live. My experience has been that roughly between 1/3 and 1/2 of enterprises run synthetic transactions for integration testing before deploying new applications. But typically they aren't run too often once the app is in production, because they can affect network performance (and they're often brittle, if you change one minor variable in your network, you can break the test).

Posted by Harper Mann on May 17, 2006 02:31 PM

May 12, 2006 | Comments: (0)

IT trouble often starts with inconsistency in process

A few years ago, I attended an ITIL (IT Infrastructure Library) training session at a major financial services company with >$3-billion annual IT spend. Each of the line of business IT managers being trained had about 100 people working under them, and each had multimillion-dollar IT budgets.

So at that time, one of the first steps of ITIL training was to ask these folks what the process was for some common scenarios. For example, if they needed a new exchange server for their group -- who did they order it from, who installed it internally, and how long would the whole process take, start-to-finish?

And what we found was that all nine of them had different answers ... there was a complete lack of consistency across the processes.

The point of ITIL is to get your IT organized in such a way that you're as streamlined as a McDonald's burger assembly line. When someone needs something, that's a service that you provide to them. Getting an Exchange server up and running, for example, should be a very well-baked service, with very exact costs known.

ITIL also draws an important distinction between "incidents" and "problems." Time and again, IT groups work to fix incidents rather than problems -- for example, tinkering away at an FTP server (that no one is using internally), when an Exchange server is down (a 'service' that might be worth more than $50k to that type of business).

The ITIL principals suggest that the proper way to run an IT organization is like a service provider, and large enterprises today are increasingly charging individual business units for IT services. These so-called "operational level agreements" are getting more common every day.

Posted by Harper Mann on May 12, 2006 01:08 PM

May 10, 2006 | Comments: (0)

Systems and Network Dashboards Need to Get with the 'Blink' Principle

In Malcolm Gladwell's most recent book -- "Blink: The Power of Thinking Without Thinking" -- he explains the power of the first moments of human perception, and how often more information is gleaned in those initial moments than in the subsequent thought and analysis that follows.

Coincidentally, I picked up "Blink" at the same time that I also happened to be reading "Information Dashboard Design -- The Effective Visual Communication of Data." This book -- authored by Stephen Few -- highlights a number of ways that dashboards fall short in their implicit goal of presenting a lot of information to the user in a way that's intuitive and digestible. For example, there may be inadequate context on the data ... or there may be excessive detail ... or there may be useless decoration on a display that's simply distracting. Few, is an admirer of Tufte, who developed many interesting graphics and web design principles that remain popular today.

I think there are principles in both books that are often lost on the folks that design systems and network monitoring / management dashboards. The main point of a dashboard shouldn't be to show CPU utilization on disk #12 in the server room, or other minutia on low-level hardware information. The business guys don't care. What they care about is -- is this network up or down? Is this application performing fast or slow?

And particularly with the emergence of commodity hardware sprawl, where we have 8,000 Linux boxes in a datacenter -- how much do you care about one going down, when you can easily just plug in a new one and replace it?

So the point is that while the low level information is important to the IT guys in the trenches, IT dashboards have a long way to go in terms of putting the information up-front, and providing the type of first-glance indicators that make these tools useful to the business audience. With most dashboards, the tools themselves continue to relegate us to chasing rabbits down a hole, thinking about bits and bytes, while the critical information is lost in quantity. Dashboards should be about the bigger picture surfaced with enough context to guide what needs to be done now.

Here are a few additional URLs to dashboard design principles / discussions from Stephen Few that I stumbled upon that you might find useful for further reading, if the topic interests you:

http://www.perceptualedge.com/about.htm
http://www.b-eye-network.com/blogs/few/
http://www.perceptualedge.com/examples.htm#

Posted by Harper Mann on May 10, 2006 04:58 PM

May 02, 2006 | Comments: (0)

Cacti Brings Great Reporting Functionality to Open Source Monitoring

A few weeks ago, I pointed out RRDTool, a powerful open source technology for storing and graphing network monitoring data.

Collecting data is all well and good, but you also have to have good reporting -- which is why there's so much excitement today around another great open source tool called Cacti.

According to the project founders: "Cacti is a complete network graphing solution designed to harness the power of RRDTool's data storage and graphing functionality. Cacti provides a fast poller, advanced graph templating, multiple data acquisition methods, and user management features out of the box. All of this is wrapped in an intuitive, easy to use interface that makes sense for LAN-sized installations up to complex networks with hundreds of devices."

Rumors on the Cacti project forum have it that in the docket are some additional plug-ins that will enable automated email notifications about network performance, as well as new "thresholding" capapbilities that trigger alarms and notifications. The other exciting thing about Cacti is its ability to scale to big environments. Because it batches its operations, and because the polling happens locally -- you get high performance monitoring / reporting for distributed environments.

One of the criticisms of open source network monitoring solutions to date (compared to their proprietary counterparts, such as Openview, CA Unicenter, etc.) -- has been that the reporting is not up to snuff. With Cacti, the reporting functionality in open source-based network monitoring has taken a giant leap forward.

Posted by Harper Mann on May 2, 2006 04:38 PM

May 01, 2006 | Comments: (0)

Network Weathermap -- A Free Monitoring Tool You Should be Using

I'm down here all week at the Interop event, where conference sessions are already underway, and the exhibition floor opens up tomorrow.

One of the really cool new open source tools that's on display this year is called Network Weathermap.

According to the Network Weatherap web site: "Network Weathermap is a perl tool that displays in a visual way the utilization of the network links of your network. The required data are acquired from graphs created by the MRTG package and are displayed as two ways colored arrows on a map representing the logical topology of the network. The resulted image is presented in a web page using extra DHTML and JavaScript code for web-over pop-ups, based on the OverLib JavaScript library."

At Interop, I installed Network Weathermap to monitor the InteropNet -- the event network that delivers wireless, VoIP, and high speed internet access throughout the huge exhibition center here at Mandalay Bay.

If you go to this link, you can check it out. I'll apologize in advance -- there are so many layers of security on top of the InteropNet that this particular link will be down periodically throughout the week (it works perfectly here on the local subnet).

What you're looking at is a core topology for the network that shows the connection to the Internet and the firewalls and the main core routers inside. At the bottom of the page is a clickable link that shows the nodes in the NOC that are doing the monitoring, as well as some performance stats on them. There's also a subnet map that you get when you click on show floor and the PEDs -- and you can get detailed analysis of the interface that are on all of the routers and equipment.

If you were to set up this sort of visio map of a big enterprise network with an Openview or similar, it would cost you a ton of money. I think one of the themes that's really going to surface at this year's event is that there are some VERY compelling open source monitoring tools out there that can be easily plugged in, and that can perform under the rigors of just about any environment.

I'll be reporting back on some other cool open source monitoring tools throughout the week, here from the show.

Posted by Harper Mann on May 1, 2006 01:56 PM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert