Key Takeaways
|
|
Contemporary monitoring
With the advent of byte code instrumentation (BCI) in 2008, application performance management took a giant leap in what is known as "inside-out monitoring," that is, monitoring from inside the application. Before that, application monitoring was largely limited to tracking CPU, memory, disk, and process availability. BCI offered new opportunities in terms of how applications could be monitored and what could be monitored from an application performance perspective. Use of BCI was pioneered by Wily Technology, which was acquired by CA/Broadcom. Wily included BCI as part of the Java language in JSR 199. This worked well for monitoring monolithic applications.
Starting in 2010, with cloud and microservices becoming popular, applications became significantly more complex. A single request could go through numerous services (including authentication, authorization, third-party, and so on). At the same time, there was a new paradigm for deploying applications: Teams began to deploy more frequently in a dynamic infrastructure, with the ability to scale up and down on demand.
With these changes, the traditional monitoring approach using BCI proved to be insufficient. Simply turning up more metrics only added to the noise. The volume, variety, and velocity of incoming data, popularly known as the “three Vs,” required a new approach.
What is observability?
Observability has been an IT buzzword for more than five years. According to Wikipedia, “Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. In control theory, the observability and controllability of a linear system are mathematical duals.”
Traditional monitoring helps teams answer questions for situations when they know there is a problem, that is, a known-known problem. This includes questions like “What is the CPU utilization of my process?” or “What is the latency of my request?” However, modern applications with complex request fulfillment paths touching numerous services and systems can have multiple points of failures and unknowns. Do we have the right data/tools to ask the right questions? Is the system observable enough to answer questions like “How is my system doing overall?” and “Why is it not working?” Observability allows teams to answer these types of questions and helps them interpret the data.
Three pillars of observability
There are three primary aspects of observability:
- Logs: Logs have been around forever and produce interesting events that can assist in troubleshooting. The challenge with logs is volume and context. Scoping to ensure context is provided is the key to making sense of logs.
- Metrics: Typically, metrics are time-series data that allows users to set alerting. Generally, metrics answer the "what" question. Per the Google SRE guide, latency, traffic, errors, and saturation are the four golden signals.
- Traces: Traces show end-to-end request tracking. This helps reveal key information related to latencies and errors as a request crosses various system boundaries and can accurately pinpoint the class and method that are causing the issue.
Observability made easy with AIOps from Broadcom
AIOps and observability technologies from Broadcom provide full stack monitoring and observability of application, infrastructure, and network data. This solution can pull data from Broadcom monitoring solutions as well as third-party tools and open-source technologies. The solution can correlate different entities from these data sources and show metrics, logs, and traces in context and in a single pane of glass. This helps reveal some of the known problems and provides enough information to investigate the unknowns.

Srikant Noorani
Srikant Noorani, Client Services Architect focusing on AIOps and Observability, has over 20 years experience working on complex technical challenges. A hands-on architect with a passion for guiding enterprises in their digital transformation journey, Srikant has worked on the largest APM deployments plus DevOps,...
Other resources you might be interested in
Nobody Cares About Your MTTR
This post outlines why IT metrics like MTTR are irrelevant to business leaders, and it emphasizes that IT teams need network observability to bridge this gap.
Tag(ging)—You’re It: How to Leverage AppNeta Monitoring Data for Maximum Insights
Find out about tagging capabilities in AppNeta. Get strategies for making the most of tagging and see how it can be a game-changer for your operations teams.
Rally Office Hours: October 2, 2025
The Rally Model Context Protocol (MCP) Server acts as a standardized interface for AI models and developer tools. Learn about this exciting new feature then follow the weekly Q&A session with Rally...
Why 1% Packet Loss Is the New 100% Outage
In an era of real-time apps and multiple clouds, the old rules about 'acceptable' network errors no longer apply. See why you need end-to-end observability.
Rally Office Hours: September 25, 2025
Rally Office Hours delivers an essential product tip: Learn to transition from Legacy Custom Pages to powerful Custom Views. Plus, Q&A insights.
Defining the Network Engineer of Tomorrow
Read this post and see why the most important investment isn't in new hardware, but in transforming your team from device managers to service delivery experts.
Harnessing AppNeta’s Browser- and HTTP-based Workflows to Track User Experience
AppNeta’s browser- and HTTP-based workflows let you see what users actually experience. Preempt issues before they become headaches for your end users.
“Rego U” Recap: Why SPM Is Still Hot
Rego Consulting’s Annual Conference underscored why strategic portfolio management (SPM) is still essential. Leverage SPM to bridge strategy and execution.
What's New in AutoSys 24.1: Built for the Modern Automation Landscape
See how AutoSys 24.1 is designed to streamline your daily tasks, accelerate troubleshooting, and simplify how you integrate with the latest technologies.