Spring Insight is a technology developed alongside VMware's popular Spring application development framework which gives developers visibility into application runtime performance and behavior. This includes seeing the SQL executed for any page request, verifying transactions are working properly, finding pages which are executing slowly and troubleshooting.
To achieve the level of detail and functionality, the original design for Spring Insight called for an agent to be installed at each monitored server. The agent performed both collection and analysis functions on the server directly. In the upcoming release of Spring Insight, due later in 2012, the collection and analysis mechanisms will be split, leaving collection with the agent and the analysis being sent to an analysis application that performs the analysis and generates the same data as before including endpoints, metrics and external resources. VMware SpringSource engineer Lyor Goldstein explains in a post today why this is going to be beneficial:
There are several advantages to such architecture – the most important ones being
- Decreasing the impact on the monitored application by transferring the analysis functions to a separate process
- Simplify installation and deployment of the Spring Insight framework by minimizing the number of required artifacts
- Enabling other monitoring frameworks to use the Spring Insight analysis and display capabilities – including non-Java ones e.g., .NET, Ruby, PHP, Pyhton, etc.
To have the collection function speak to the analysis one, two new dispatch transports have been introduced. Transports support three types of encoding in order to match customer transport requirements. Both the transport and encoding are built to be "pluggable" so customers are free to extend these to fit their needs. Goldstein defines the transports and encoding as follows:
- HTTP – uses HTTP POSTs to send the collected data to the analyzer. Every time such data is posted, the analyzer may optionally reply with a set of commands it needs to pass back to the agent. In other words, each HTTP session is actually an exchange of messages. This transport is suitable for “split” agent topology where several agents report to a single analyzer.
- JMX – uses direct API calls to exchange messages. This is suitable for “integrated” topology where the collection and analysis should occur within the same application server – e.g., development “mode”.
- As-is (a.k.a. “noop”) – used only for in-memory exchange of messages7
- Java serialization
The exchanged messages can be secured either by using a secure transport (e.g., https) or by employing an encryption transformer on the message. Currently, there are several builtin encryption transformers that rely on the javax.crypto package.
Extending to Non-Java Apps
One of the big interests for java developers is that Spring Insight will now be able to provide much of the level of visibility and analysis for non-Java applications by using non-Java collection agents. Goldstein describes how this will work:
One can already use the outofthebox HTTP + JSON combination to do so – in addition to supplying other transport/encoding mechanisms 8. The reason for this is that HTTP and JSON are readily available packages for most used targets besides Java – e.g., Ruby, Python, .NET. Example of such use is already under way for the .NET instrumentation being developed for the Spring Insight project.
For architecture diagrams and more detail, see Goldstein's full post on the VMware vFabric blog.