Interceptor and Business Application Lifecycle¶
A Biz Interceptor isn't a standalone service the platform runs on your behalf — it's a pluggable module that lives inside the business application it instruments, for as long as that application runs. This page covers two practical questions that follow directly from that fact: how many interceptors should I actually configure (Configuration Time), and what should I expect to see running once they're deployed (Run Time).
Configuration Time¶
Interceptors Are Business-Application-Specific¶
Because an interceptor runs embedded inside a specific business application, the recommended default is to scope one interceptor per business application — mapped across every environment that application runs in (DEV, SIT, PROD, ...), not a separate interceptor per environment. If your organization has identified 3 distinct business applications worth instrumenting, the recommendation is 3 separate interceptors, one per application, so the resulting metrics stay segregated along the same lines as the applications themselves.
This per-application separation pays off in three concrete ways:
Separate administration. A configuration change to one interceptor only ever affects the one application it belongs to — never several at once. Capture stays scoped to a specific area of the business instead of one shared configuration trying to serve everything.
Workload-specific tuning. Different business applications genuinely behave differently — one might see its heaviest traffic on weekends and stay quiet on weekdays, another might run a steady load every day with an afternoon peak. Those differences mean the tunable parameters (buffering, batching, sync intervals) that make sense for one application can be entirely wrong for another. A single shared interceptor trying to serve every workload at once makes correct tuning effectively impossible; splitting by application is what makes it tractable.
Specialized monitoring and alerting. Different business applications are often owned by different teams, with different people responsible for their production health — and very likely different SLA thresholds and alert recipients appropriate to each application's own criticality. What's a sensible Pressure alert threshold for one application's traffic pattern may be completely wrong for another's. Segregating interceptors by application is what lets each one carry SLA and alerting configuration that actually fits its own needs, rather than a one-size-fits-all compromise.
One interceptor, many applications, is possible — but not the recommendation
Nothing technically stops you from pointing a single interceptor configuration at multiple business applications. As a general rule, though, an interceptor should map to one specific business application across that application's environments — the goal being specialized capture and monitoring tuned to that application's own needs and workload characteristics, for the reasons above.
Weigh the number of interceptors you're willing to maintain against how specific each one's tuning and alerting needs to be. As a general rule, a 1:1 mapping between interceptor and business application gives the best balance between the two.
Run Time¶
An interceptor always executes inside the runtime context of the application it's embedded in — this holds true whether that application is deployed on Kubernetes or not; the interceptor operates without limitation either way.
On Kubernetes, your application is typically configured with some number of replicas, N. Since the interceptor lives inside the application's own process, there will correspondingly be N running interceptor instances, one per assignable Pod.
Outside Kubernetes — a standalone or siloed deployment — each interceptor instance still lives inside whatever application runtime instance is actually executing. For example, a Java application running on WebLogic Server has one interceptor instance per Managed Server it's deployed to; a 2-node WebLogic cluster means 2 visible interceptor instances.
Either way, every currently-running instance is visible on the Runtime Instances tab of Consolidated Stats — it's the direct, real-time reflection of however many copies of the application (and therefore the interceptor) actually happen to be running at that moment.
One interceptor instance per running application instance
The interceptor follows its application's own deployment model rather than having one of its own — in a Java runtime, as a rule of thumb, every running JVM instance has its own interceptor instance alongside it, capturing business telemetry from that application. Each instance communicates with the BizMetry platform directly for near-real-time monitoring, and with its environment's Agent for the actual transmission of business telemetry packets, over BizMetry's native RTMP (Real-Time Application Monitoring Protocol).