Instrumentation is a core component of a mature software product. It is essential for creating a new robust product. It is essential for managing a product used in production. It is essential for determining priorities for future improvements in a software product. So, what is Instrumentation?
For those of us using Microsoft SQL Server, we have likely experienced first hand what instrumentation is. When your database performance drops, what do you do? You may review some DMV queries to find out what is kind of queries are running, and taking a lot of resources. You may look at locking or blocking to find out if some slow running query is blocking the road for others. You may look at CPU utilization, memory allocation, Context switches, cache hit ratio, disk read backlog, disk write backlog, amount hundreds of different counters providing insight into the performance of the SQL Service.
Anyone having worked with SQL Server when it slows down knows how essential these tools are for finding causes for performance loss. This is made available to use because SQL Server was designed with instrumentation. The overhead for monitoring has been kept lean so that SQL Server can do the work of data storage management. It is robust enough to provide necessary monitoring points to meet a vast number of different needs.
Many web sites do a similar kind of instrumentation, tracking metrics such as the number of times a page was selected. Like SQL Server, instrumentation on web sites may be used for performance tuning. However, it may be used differently, tracking choices made by consumers, helping predict trends and business decisions. In this case, instrumentation may be even more critical to the future of you application, and maybe even your business.
What about your software? Is instrumentation a key design of your services right from the start? How do you keep the cost of monitoring low? How do you determine what to Instrument? Share your experience in our comments, or drop an Email to btaylor@sswug.org.
Cheers,
Ben