Application Development Teamwork: 7 Reasons to Develop App Footprints

Picture this: Someone in your office decided to buy a new app. Maybe they told you about it ahead of time, maybe not. While you may rightfully assume this is a responsibility of an application development team, app monitoring often falls to sysadmins or network admins. Either way, if you develop an informal application footprint, you can save yourself headaches later. The seven tips below can get you started in developing a footprint for the application. They'll make you a smarter user of your network monitoring tool if the app ever strays into rogue territory.

The folks at AppFirst offered customers seemingly simple advice when they directed them to "Know Your Application." But how simple is it, given today's state of application development standards, to "get a true application footprint?"

App monitoring is a multifaceted undertaking. Regardless of application development practices where you work, tools can be used to monitor your apps. This class of tool can specifically help narrow causes down to network issues or perhaps component dependencies.

No matter how elegant the tool (unless the application mix is highly homogenous), it can be challenging to tease out which app is causing which sort of problem — and when. An alternative approach is to create informal application profiles that allow the helpdesk to make sense of voluminous logs such as the Windows event log.

Creating Informal Application Footprint Catalogs

Here are seven straightforward suggestions for creating an application profile when a new application comes online:

1. Examine the application developer's documentation to understand which logs it creates or updates. There may be new ones for you to monitor.
2. Examine universal logs, such as the Windows Event log, to observe the logging behavior of the application (Shocker: It may be different from that advertised by the developer).
3. Once the application is fully deployed, monitor its behavior under low-user load (offpeak hours?) vs. high user load. Understand which kinds of resources it tends to hammer when it gets hungry.
4. Identify any critical processes associated with the application. For example, if there's some sort of "post" or "purge" process that kicks off an important process, make sure it's logged. If there are no built-in rollback and restart capabilities for those critical processes, make contingency plans (after a brief cry).
5. Identify key users, including phone numbers, email addresses and distribution lists for notification processes. Especially during the honeymoon process, the group whose budget took a hit for acquiring the application will be keen to make sure it runs smoothly.
6. Make social-media contacts with the vendor, and with the vendor community (such as on Reddit). If developed in-house, try to mend fences with the application group that built it.
7. If you have a CMDB or IT Asset Management tool, ensure there's a usable listing for the new application and that the essential details are right. Here's how the open-source tool Puppet suggests integrating CMDB data.

The Yeti and the Rational IT Admin

The sound of footsteps to cue an evildoer is such a classic movie cliché, and a 1951 photograph of footprints in the snow taken during a Mount Everest climb was thought by some to be proof for the existence of the Yeti. Next time you're poring over reports from your IT asset manager, event logs and process snapshots to sort out the cause of a performance anomaly, you might want to keep this background in mind.

Instead, refer to your convenient catalog of application footprints before proposing the Yeti as probable cause of a suspected hack or hiccup.