Observability and monitoring are the tools that watch live software, the servers it runs on and the network that connects them, and find out why something has gone wrong. A server is a powerful computer in a data centre that runs programs for many users over a network. Monitoring is the older word. It means checking numbers that are known in advance, such as whether a server is switched on. Observability is the newer word. It means recording so much about the software that engineers can answer questions that nobody thought of in advance. The page on observability explains the idea in general.
Here is a typical night. It is 3 a.m. at a medicine delivery company in Hyderabad. A customer orders insulin, and the app shows "Something went wrong". In ten minutes, 400 orders fail in the same way. The app is in production, the live version that real customers use. So nobody can switch it off to look inside. An alert, an automatic warning message, rings on the phone of the engineer on call. Being on call means that it is her turn to respond to problems, even at night. She has to answer one question fast: is the fault in the code, in the servers, or in the network?
This scene has two layers, one for each place where a fault can be.
The first layer is application performance monitoring (APM). It watches the app itself and the machines under it. As the app runs, its code records three kinds of data: numbers measured over time, called metrics; lines of text, called logs; and the path of each request through the software, called traces. An observability platform collects all three, so that one failed order can be followed through every program it touched. Infrastructure monitoring watches the servers, disks and network devices under the app. Business observability counts failures in business steps, such as "payment debited but order not confirmed". The newest product is the AI SRE, an AI agent that reads the alert and the data before the engineer does.
The second layer is network monitoring and testing. It watches the cables, radio links and routers that carry the data. Network test equipment measures fibre and radio before they go live. Network TAPs and packet brokers copy the traffic, so that other tools can study it. Network AIOps turns hundreds of alarms into one likely cause. A telecom operator also uses telecom service assurance to check how well its network serves its subscribers.
One rule holds the whole scene together. These tools observe; they do not change anything. They record, copy, measure and analyse. They do not carry the customers' traffic, and they do not block it. Blocking is the job of security products such as a firewall.
How does the night end? The traces show that every failed order waited 30 seconds at the payment step. The infrastructure graphs show that the payment service's own database server is healthy. The network data shows that the link to the payment gateway began to lose data after a router setting was changed at 2:40 a.m. The network team undoes the change, and orders start working again by 3:25 a.m. Without these tools, the engineer would have had to guess.