To achieve a real understanding of software for the purpose of managing and changing we need a deeper level of observation that is as close as possible to what it is software actually does. Software does not log. Developers write logs calls to create an echo chamber.
A proposal for a different approach to application performance monitoring that is far more efficient, effective, extensible and eventual than traditional legacy approaches based on metrics and event logging. Instead of seeing logging and metrics as primary data sources for monitoring solutions we should instead see them as a form of human inquiry over some software execution behavior that is happening or has happened. With this is mind it becomes clear that logging and metrics do not serve as a complete, contextual and comprehensive representation of software execution behavior.
Imagine writing a method invocation interceptor class that is called within a process when a method is invoked by a thread. This is something that has been possible for sometime using various frameworks, such as Spring and JEE/CDI, and AOP technologies, such as AspectJ. Now imagine that same interceptor class is able to intercept method invocations across multiple Java runtimes and threads and not actually be present within each of the runtimes without a single line of code change - a mirrored runtime down to the thread and call stack as well as some environment state. Now lets go even further and imagine the very same interception class being able to receive the same call backs within the same mirrored threads from a past recording, that can be repeatedly run. Again no changes though the space and time aspects of the entire environment has changed.
Today it is common to replicate data across machine boundaries but what of execution behavior? Whilst remote procedure call (RPC) middleware has allowed us to move execution across process and machine boundaries, at a very coarse granularity, these calls do not necessarily represent the replication of inherent software behavior, but merely a form of service delegation. The type of mirroring I am referring to here is the simulated playback, online or offline, of a softwares execution behavior in which a thread performs a local function or procedure call that is near simultaneously mirrored in one or more "paired" runtimes.