How to Monitor Application Performance: Set It Up Step by Step

Application performance monitoring means watching how fast and how reliably an application serves its users, and finding out why when either slips. Done well, it lets a team see a slow journey before users report it. This guide on how to monitor application performance is for IT heads and IT managers in India or the GCC. Their business applications run across several teams or suppliers. It sets out an application monitoring setup in ten steps, with an owner and a “done when” for each, and it shows no product screens. For the target state, see the application observability use case. If you first want to know where the hours go when a fix runs late, read that piece and then come back here.

How to Monitor Application Performance: The Build Order at a Glance

The table gives the whole order. Steps 1 and 2 happen on paper, before anyone installs an agent or changes a line of code.

How to Monitor Application Performance, Steps 1 and 2: Journeys and Targets

Before any tool goes in, the team has to agree which journeys matter to the business. It also has to agree what counts as good enough for each one. Settling both is the planning half of how to monitor application performance, and this part of the setup needs the business in the room.

Step 1: List the Key User Journeys and Name an Owner for Each

Start with a few journeys that users and the business feel straight away, such as login, search, checkout or a payment confirmation. A retailer in India might pick checkout during a festive sale, while a GCC bank might pick customer login on its Arabic and English portals. Keep the list short at first; you can add journeys once the first ones work.

For each journey, write down the services and databases it touches. Add the outside services too, such as a payment gateway, an SMS provider or a supplier that runs part of the stack. That list becomes the map for Steps 3 and 4. In addition, it shows where a supplier’s layer sits, because that layer may need its own agreement on what data the supplier shares.

Then name two owners per journey. The business owner says what “working” means for users. The technical owner answers when the journey breaks. In Signisys’s working view, a journey with only a technical owner tends to end up with targets nobody in the business has agreed to.

Step 2: Set a Speed and an Error Target for Each Journey

Each journey needs one speed target and one error target, and both should start from the user’s side. The Site Reliability Engineering book has a chapter on Service Level Objectives. It advises starting from what users care about, ahead of what is easy to measure. It also advises keeping such targets as few as possible.

A speed target reads the slow end of the spread as well as the middle. An average can look healthy while a share of users waits far longer, for example customers on a weaker mobile connection in a smaller town. The same book shows speed read at several points of the spread for one system. Which points to use depends on the journey: this guide gives no recommended percentile or number.

An error target counts the requests that fail from the user’s side, such as a failed login or a payment page that times out. Set both targets from your own traffic. To do that, look at a few weeks of real use, including a busy period, and agree the figures with the business owner.

Other readings, such as how full a server is, support these targets but do not replace them. The downtime post linked in Step 5 covers those signals.

How to Monitor Application Performance, Steps 3 and 4: Traces and Logs

Once targets are agreed, the team needs to see inside each journey. Traces show where a request spends its time, while logs show what each part said along the way. This is the part of an application monitoring setup where development teams carry the load.

Step 3: Follow Each Request From End to End

Add hooks where a request enters and leaves each service and around the key transactions inside it. Add them around every call to an outside service too. Together these show which hop added the delay when a journey slows down.

Next, make sure one request carries one ID across every service. The W3C’s Trace Context Recommendation defines standard web headers and a value format that pass this identity from one service to the next. When every team’s services read and forward the same header, one request can be followed from the user’s click to the database and back.

Start with one journey from Step 1 and leave the other endpoints for later. Get its trace complete, check it with the journey’s technical owner, and then move to the next. As a result, the team learns the method on a small scope, and the data volume grows only as each journey earns its place.

Step 4: Collect Logs in One Searchable Place, in One Format

All services should write logs in one structured format, with agreed field names and one time format. They then send those logs to one place where the team can search them. OWASP’s Logging Cheat Sheet asks for logging that is consistent within an application and across an organization’s applications. It also lists synchronizing time across all servers and devices as a practice. In Signisys’s working view, unsynchronized clocks make events from different machines hard to put in order.

In practice, this application monitoring setup step goes faster when the request ID from Step 3 is one of the agreed fields. Then a trace and its log lines can be found together.

Set a retention period that suits your firm and any rules your sector follows. Similarly, if a rule in India or a GCC country says where certain data must stay, check it before choosing where the logs live. Finally, keep passwords, tokens and personal data out of the logs from day one.

How to Monitor Application Performance, Steps 5 to 7: Alerts and Releases

With targets, traces and logs in place, attention turns to people. Someone has to hear about a problem and know what to do first. In how to monitor application performance, these three steps decide who that person is and what they see.

Step 5: Alert on What Users Feel

Tie each alert to a Step 2 target, so an alert fires when users are feeling slowness or errors on a journey. An alert on a server reading alone, such as memory use, can fire while users notice nothing, or stay silent while a journey fails.

Build the thresholds from your own targets and traffic, and treat any shipped default as a rough first guess. Some journeys have a busy hour, for instance on payroll day or during a Ramadan evening sale. Check that the alert still makes sense then, as well as at a quiet hour.

Server readings still have a place as supporting signals behind the alert. For a fuller account of latency, traffic, errors and saturation, see the four signals behind downtime warnings.

Step 6: Route Each Alert to a Named Owner With a Runbook

Every alert should go to one owning team and call for an action. In Signisys’s working view, a page that asks for no action should not wake anyone.

Give each alert a short runbook. It lists the first checks and the likely causes. It also says how to roll back a recent change and whom to call if the first responder is stuck. Keep it next to the alert, where the responder sees it at 2 a.m.

Also give each owning team one channel for its alerts. A shared inbox for every team means each one assumes another has picked the alert up. Where a supplier runs a layer, agree in writing how their alerts reach your team and how yours reach them.

Step 7: Mark Every Release on the Graphs

Put a marker on the graphs for every release and every configuration change. Then, when a journey slows down, the team can see at once whether a change landed just before it.

The owner is whoever ships the change. In a team that uses DevOps pipelines, the pipeline can add the marker as part of each deployment. Where releases go out by hand, add the marker to the release checklist. Include supplier changes too, such as a new version of a payment page, when the supplier tells you about them.

How to Monitor Application Performance, Steps 8 to 10: Test, Tune and Hand Over

Finally, the application monitoring setup has to hold up under test and outlast the build team. Until someone tests it, nobody knows whether an alert will reach its owner. These last three steps of how to monitor application performance check it, cut the noise and pass it on.

Step 8: Test the Monitoring Before Users Find the Gap

Run scripted journeys that log in, search or check out on a schedule, from more than one location. For example, a firm with users in Mumbai, Bengaluru and Dubai can run one script from each city, and a slower region then stands out. Add timing from real users’ screens as well, because a scripted check from a data center does not show what a customer on a phone sees.

Then break one thing on purpose in a test environment and follow it through:

If any of these fails, fix it before go-live.

Step 9: Tune Noisy Alerts After Go-Live

After go-live, review each alert and ask whether it led to an action. We recommend a simple measure: the share of alerts that led to an action.

For each alert that led to nothing, choose one of three moves. Remove it, merge it with a related alert, or route it to a team that can act on it. Alerts that did lead to action may still need a better runbook or a clearer threshold.

Set a review rhythm that suits your firm, and also review after each major incident and each big release. Among application monitoring best practices, this one can slip easily once the project team moves on. For that reason, name an owner for the review in the handover.

Step 10: Pass the Setup to the Team That Runs Applications Day to Day

The setup is finished when the team that runs the applications day to day takes over their monitoring in writing. It comes with a handover pack of six items.

• the journey list with both owners for each journey;
• the speed and error targets, with the date each was agreed;
• the alert list, with each alert’s owner and runbook;
• the dashboards and who reads each one;
• how a new application or journey joins monitoring;
• the date of the next alert review.

Walk the running team through one alert from start to finish before they sign. Meanwhile, the build team stays reachable for an agreed period, so questions have somewhere to go. Later, the running team can test the result against ten checks scored from dated evidence.

Four Application Monitoring Setup Mistakes That Undo the Build Order

Each of these mistakes undoes part of the order above, and each is easier to avoid at the start than to unwind later.

Where This Setup Guide Stops

Its scope ends at the build order for monitoring. The reasons fixes run slow are covered in the problem piece linked at the top. Availability design, failover and recovery targets belong to the guide to improving application availability. Cloud resource readings belong to the checklist for cloud resource readings. The choice of tools is outside this guide. Whether to stop at alerts on chosen readings or go further is weighed in a comparison of watched readings and questions asked after the event. Observability is how well a team can work out what is happening inside a system from what it sends out, and the observability glossary entry explains the term in more depth.

If the applications span several suppliers, or the team has no time to run the monitoring setup alongside daily work, outside help can shorten it.

Signisys provides DevOps automation services and works on modernizing applications with observability built in, so weigh this guide as a vendor’s view.

For help with an application monitoring setup, or for a second look at a supplier’s plan against these ten steps, a consultation is a good first step.

How to Monitor Application Performance FAQ: Setup Questions