A mortgage application that gets stuck. A permit application that stalls. Blueriq applications are often mission-critical and play a central role in a chain of systems. If performance drops, the end user feels it immediately. And recovery takes time that you’d rather spend on further development than on digging through log files that become completely jumbled when there are many concurrent users.
Moreover, the delay often isn’t even in Blueriq itself, but in an integration with an external system or database, called via a service call or container in your model. With Metrics and Tracing, the extension of the observability capabilities in the Blueriq runtime, you can identify those bottlenecks faster, often before users are even affected by them.
Mortgage application (financial services). An application goes through multiple service calls, such as a BKR check or a property appraisal integration. With Metrics, you can immediately see which of those calls is consistently the slowest, even before the first complaint from an advisor comes in.
Permit application (government). Is an application getting stuck at an integration with an external BAG or BRK registry? With Tracing, you can see exactly which step of that specific event is causing the delay, and whether it’s on Blueriq’s end or the external registry’s.
Identify trends and anomalies before they affect users
Metrics provide continuous, objective insight into the performance of your Blueriq containers and service calls—for example, the average response time over the past 60 minutes. You can visualize them in a dashboard using tools like Grafana, where you can see the top 10 slowest service calls or containers at a glance. You can set up an alert based on a threshold so that you’re automatically notified as soon as the response time becomes too long. Metrics answer the question: Is the system consistently performing well or poorly, and how does performance change over time?
Track a single event step by step through the entire chain
Where metrics end, Tracing zooms in. You select a specific event and track, step by step, which requests and responses occur within it, so you can see exactly which chain is being traversed and where exactly the delay is occurring. Tracing answers the question: Why was this particular event slow, and which component caused it? Is the issue within Blueriq itself, or is Blueriq waiting for an external component?
Metrics and Tracing operate from the same Blueriq runtime (Micrometer/OpenTelemetry), but each follows its own data path to its own visualization: Prometheus collects the metrics data, Grafana visualizes the metrics, and Jaeger visualizes the tracing. These are the tools we’ve tested. If you’re already using other observability tools, they’ll work just as well, as long as they connect to the OpenTelemetry protocol.
You often identify issues before users are even affected by them, rather than trying to figure out what went wrong after the fact.
You no longer have to sift through log files from many concurrent users. Metrics point you to the underlying problem, while tracing pinpoints the exact cause within a single event.
You can build your own dashboards featuring trends, peaks, and anomalies, and set alerts based on the thresholds that are relevant to your application.
End users no longer have to wait, business engineers no longer have to pore over logs, and you can free up your best people for further development instead of putting out fires.
When using our cloud service, Blueriq handles the underlying tooling for you.
If you choose to self-host—for example, in your own cloud environment—you’ll need to add the necessary dependencies to the runtime yourself and set up and manage Prometheus, Grafana, Jaeger, or similar OpenTelemetry-compatible tools on your own.
Runtime Performance Insights is available starting with Blueriq version 18.5.
Please contact your Customer Success Manager to enable Metrics and Tracing for your Blueriq environment. For other questions, please contact Yuri Versluis.