Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

Latest commit

 

History

History
93 lines (63 loc) · 4.15 KB

README.md

File metadata and controls

93 lines (63 loc) · 4.15 KB
Raw

pipeline status

coverage report

ExplorViz Trace-Service

Scalable service that processes, aggregates and persists the observed traces of method executions within monitored software applications.

Features

trace-service

The service serves three purposes

  1. it aggregates dynamic information of monitored applications, i.e., method calls with timing information (SpanDynamic), and reconstructs traces based on these spans.
  2. persists these traces in a Cassandra database.
  3. assembles a list of traces upon client request (for a given landscape token and optionally time frame).

Processing Dynamic Information

The Trace-Service reads SpanDynamic records from a Kafka topic. Its main purpose is to identify and aggregate spans that belong to the same trace and store them. A SpanDynamic consists of

  • spanId (uniquely identifies a span)
  • traceId (identifies the trace the span belongs to)
  • parentSpanId (identifies the parent of this span in the call hierarchy, i.e., the caller)
  • timestamps of the start and end time
  • the fingerprint (i.e. mapping to a structural record) and other metadata

You can find the full definition as an Avro schema here.

Each time the service ingests a span with an unknown traceId, it waits for 10s (in stream time) for more spans of that trace to arrive. After 10s the window closes, all related spans are aggregated into a trace object, which is subsequently written to a Cassandra database.

Stored traces can be retrieved by clients. For that purpose, client have to specify the landscape token, and the time period for which traces should be retrieved.

Prerequisites

  • Java 11 or higher
  • Make sure to run the ExplorViz software stack before starting the service, as it provides the required database(s) and the Kafka broker

Running the application in dev mode

You can run your application in dev mode that enables live coding using:

./gradlew quarkusDev

This also enables the dev configuration profile, i.e. using the properties prefixed with %dev from src/main/resources/application.properties.

Packaging and running the application

The application can be packaged and tested using:

./gradlew build

It produces the quarkus-run.jar file in the build/quarkus-app/ directory.

You can skip running the integration tests by adding -x integrationTest. To skip all tests and code analysis use the assemble task instead of build.

The application is now runnable using java -jar build/quarkus-app/quarkus-run.jar. Be aware that it’s not an über-jar as the dependencies are copied into the build/quarkus-app/lib/ directory.

If you want to build an über-jar, which includes the entire application in a single jar file, execute the following command:

./gradlew build -Dquarkus.package.type=uber-jar

The application, packaged as an über-jar, is now runnable using java -jar build/trace-service-1.0-SNAPSHOT-runner.jar. You can add -Dquarkus.profile=dev to enable the %dev properties.

Creating a native executable

You can create a native executable using:

./gradlew build -Dquarkus.package.type=native

Or, if you don't have GraalVM installed, you can run the native executable build in a container using:

./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true

You can then execute your native executable with: ./build/trace-service-1.0-SNAPSHOT-runner

If you want to learn more about building native executables, please consult https://quarkus.io/guides/gradle-tooling#building-a-native-executable.