Trace Service Map

A Kibana plugin to show a graphical service map created from execution traces in Zipkin format. The traces have to contain certain tags and attributes to get displayed correctly in the map (see Trace Format).

---

Installation

Prerequisites: Elasticsearch and Kibana 7.10.0

./bin/kibana-plugin install https://github.com/noah-kogler/trace_network_map/blob/main/build/traceNetworkMap-7.10.0.zip?raw=true

Development

1. See the kibana contributing guide for instructions setting up your development environment!
2. Download the code of this plugin and put it into the kibana/plugins-directory.
3. Start your kibana development environment with nvm use; yarn start --oss
4. Navigate your browser to /app/traceNetworkMap

Note: You can a URL parameter /app/traceNetworkMap?enableTimeFilter=false to disable Kibana's time filtering mechanism. This may be helpful for development.

Scripts

yarn kbn bootstrap

Execute this to install node_modules and setup the dependencies in your plugin and in Kibana

yarn plugin-helpers build

Execute this to create a distributable version of this plugin that can be installed in Kibana

---

Trace Format

The service map supports different types of traces. Each trace-type has a corresponding node-data-class in public/node/data. These classes defined which information from the traces is displayed in the service map nodes and also contains some nodes to aggregate and group traces for a better overview. To extend the traces a specific node-data-class needs to be created and registered in public/node/data.ts.

The Laminas Tracing Module provides tools to create traces in the right format.

Traces are recognized by their localEndpoint or their remoteEndpoint. Additional tags must be set to provide the service map with the required information. The following traces are supported:

Web frontend

localEndpoint

web-frontend

tags

• page Should contain the URL path of the page the fetch call was triggered from.
• http.status_code The HTTP status code of the request.

Traces coming from the web frontend must be in the format provided by the zipkin-js fetch instrumentation.

Api

localEndpoint

api

tags

• http.path Needed to identify the API-URL.

Redis

remoteEndpoint

redis

tags

• hash An additional hash code describing the cache item.
• result.exists For "has" operations. Should be "1" if a cache object exists and "0" otherwise.
• result.success For "get", "set",... operations. Should be "1" if a cache object exists and "0" otherwise.

The name of the trace should be the name of the operation on the redis cache.

MySql

remoteEndpoint

mysql

tags

• table The tables a database statement operates on. Could be a list in case of joins.
• result.count The number of returned/modified rows in the statement.

The name of the trace should be the database operation: E.g. "select", "update" or "insert".

S3

remoteEndpoint

s3

tags

• name The name of the s3 operation. E.g. CopyObject, ListObjects.
• key The key of the object manipulated/queried in s3.
• result.exists Needed if the operation checks the existence of an object. Should be "1" or "0".
• result.count The number of objects manipulated/queried.

The name of the trace should be method name of the method called on S3 (e.g. executeAsync).