Since Blueriq 14.6, the Timeline DAO, which used to be included in the Trace SQL Store Component, has been split to a separate component. See Timeline SQL Store component for details. |
Table of contents
This Trace SQL Store Component contains a Trace DAO implementation that can be used by the trace engine to store trace messages in a database.
Blueriq 14.8 introduces the possibility to consume trace events that are pushed on a queue by the Trace Event Publisher Component and then store them in a database in an asynchronous way. See consume trace events.
This component persists data in a database, that must be provided. See platform support for the supported databases.
Optional: the consumer functionality needs to be able to access a queue. Currently only RabbitMQ is supported. For setting this up see Configuration of RabbitMQ for Customerdata service and Trace Event Publisher.
In order to use this component, the or
(Blueriq 14.6 and onwards) profile must be active. More information on how to configure the application using Spring Profiles can be found here: Component configuration with Spring Profiles.
The latter profile will only write trace message to the database and not timeline messages. See Timeline SQL Store component for writing timeline messages to a separate database.
Add the artifact with groupId "com.blueriq" and artifactId "blueriq-component-trace-sql-store" as a dependency to your Blueriq runtime POM file if you want to depend on it.
The trace can be used in different settings, to configure how the trace will behave, and how the timeline will behave. In the table below, different combinations of are explained:
| Active bootstrap profiles | Effect |
|---|---|
| Both timeline and trace will be stored in the external datasource configured as "trace-sql-store" | |
| Timeline is stored in external datasource "timeline-sql-store", trace is ignored | |
| Timeline is stored in external datasource "timeline-sql-store", trace in "trace-sql-store" |
| Timeline is stored in external datasource "timeline-sql-store", trace is pushed to the exchange configured at the properties and will be consumed by the consumer functionality |
Scripts to create the required database content are provided for the following databases:
For customers that are upgrading an existing version of Blueriq, database upgrade scripts are provided in the Upgrade instructions when applicable. |
Please make sure the trace-sql-store has a separate datasource. Using the same datasource for other components is known to cause errors. |
Use the following steps to configure the datasource:
Using JDBC datasource : this can be configured in the application-externaldatasources.properties file. When configuring external datasources, the profile should be enabled.
blueriq.datasource.trace-sql-store.url=jdbc:sqlserver://<database_url>:<port>;databaseName=bq_comments;instance=SQL_EXPRESS blueriq.datasource.trace-sql-store.username=<username> blueriq.datasource.trace-sql-store.password=<password> blueriq.datasource.trace-sql-store.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver blueriq.hibernate.trace-sql-store.hbm2ddl.auto=validate blueriq.hibernate.trace-sql-store.dialect=org.hibernate.dialect.SQLServer2012Dialect |
Using JNDI datasource : this can be configured in the application-jndidatasources.properties file When configuring JNDI datasources the profile should be enabled.
blueriq.datasource.trace-sql-store.jndiName=java:/comp/env/jdbc/blueriqTrace blueriq.hibernate.trace-sql-store.hbm2ddl.auto=validate blueriq.hibernate.trace-sql-store.dialect=org.hibernate.dialect.SQLServer2012Dialect |
trace-sql-store datasource. The same properties are available for configuration as from the properties file. Make sure the corresponding profile is enabled (Supported dialects:
Supported hbm2ddl.auto values:
The Trace SQL Store component can store trace messages directly in the database, but it is also possible to decouple the storage of trace messages using the Trace Event Publisher Component to publish trace events to a queue and then consume them using this component.
To be able to consume event messages, the event channel needs to be configured in the . This file can be found, or otherwise should be placed in the
The Trace SQL Store either stores trace messages in the database, or consumes trace events from the queue. When the configuration below is enabled, only trace events are consumed, no trace messages are saved to the database directly. So if you enable this configuration, be sure to also enable the Trace Event Publisher Component, otherwise no trace information is saved anywhere. |
# RabbitMQ configuration blueriq.trace.event.listener.amqp.rabbitmq.host=localhost blueriq.trace.event.listener.amqp.rabbitmq.port=5672 blueriq.trace.event.listener.amqp.rabbitmq.virtualHost=/ blueriq.trace.event.listener.amqp.rabbitmq.username=guest blueriq.trace.event.listener.amqp.rabbitmq.password=guest blueriq.trace.event.listener.amqp.rabbitmq.queueNames=trace # Enable consumer functionality blueriq.trace.event.listener.amqp.enabled=true |
To enable a secure (TLS) AMQP connection to the queue, set the property "blueriq.trace.event.listener.amqp.rabbitmq.ssl.enabled" to "true".The default for AQMP port with TLS on RabbitMQ is '5671', it needs to be explicitly enabled though, see https://www.rabbitmq.com/ssl.html for more information.
The performance impact of the Trace SQL Store is minimal when used normally: to write trace messages to the database.
It is also possible to use the Trace SQL Store to query the trace engine database, like the timeline container does. The Trace SQL Store offers good performance as long as the result set is limited. For large scale analysis, when summaries or aggregates are desired, the Trace SQL Store is not recommended because it is primarily designed to return a list of trace entries. For these scenarios it is recommended to use SQL (or HQL) to query the database.