By the time an engineer opens an alert, the application may have recovered. The response-time spike has passed, leaving the team to establish when it began and which requests were affected.
JENNIFER Dashboard Replay lets engineers revisit a historical monitoring view. Reviewing the period before and after the alert can help them reconstruct the sequence and choose transactions for closer inspection.
Choose a starting point
Replay is available from supported dashboards and incident-analysis screens, including EVENT analysis, notifications and X-View Transaction Analysis. It first appeared in JENNIFER Server 5.6.4.5.
Choose an event or transaction that represents the problem, then write down the question you want to answer. Was this error the start of the incident, for example, or had the application already been slowing down? An explicit question helps when several charts show changes at once.
Work through the timeline
Playback controls let you play, pause, rewind, fast-forward and adjust speed.
Replay provides a draggable timeline, playback rates up to four times normal speed and event markers colored by severity. Use the faster playback to review a longer interval, then return to a change that needs attention.
For an incident review, the following sequence can help:
- Find the last interval that appears normal.
- Move forward to the first relevant change.
- Note what changed and what stayed steady.
- Inspect affected transactions before deciding why the change occurred.
- Continue through recovery to see whether the symptoms ended together.
This is a suggested investigation method. Keeping observations separate from explanations makes it easier to identify unresolved questions and assign them to someone for further work.
Inspect the transactions behind the change
Consider a PostgreSQL deadlock. Response times rise around an event. The engineer selects the affected region in X-View and opens transaction analysis, where the database error provides further evidence. Replay can also start from an error transaction to examine the preceding monitoring context.
The dashboard helps establish the sequence and scope; the transaction shows what a particular request encountered. A response-time spike by itself does not explain the cause. Keep the time window, affected application and representative transaction in the incident record, along with any open questions, so another engineer can retrace the investigation.
Check dashboard support and retention
The initial supported dashboards included system administration, resources, database views, users and multi-domain monitoring. Replay also depends on retained data. An EVENT’s replay button may disappear after the database retention period expires. Replay export to Talk was added in Server 5.6.4.24.
Server 5.6.5.5 expanded support to Application Insights, Application Insights for multiple domains and Memory dashboards. Check your installed version when choosing the views for a review.
Before the next incident, try replaying a recent problem the team already understands. Confirm that the required period is still available and that people can reach the relevant views. Following a familiar symptom through to its transaction details is a useful way to check whether the team is ready to use replay during an investigation.