xk6-common-util

xk6-common-utils

[[TOC]]

Summary

This library offers a collection of utility functions and modules that address common funcunalities that are used across other related projects.

Component Owner

The components in the repository are being maintained by

• Value Stream: VS03
• Team: Cliffhanger
• Main technical contacts: [e-mail]

Dependencies

The following table lists all dependencies of the component.

• Source: This component (use the container name).

• Target: The used component (use the container name).

• Protocol: Specify the protocol used for the dependency: REST, JMS, AMQP, SQL, erc.

• Purpose: Specify for what the dependency is used - and maybe also when (e.g. if only during installation).

• Error Detection: Describe what symptoms indicate that the dependency is broken.

• Troubleshooting: Describe what is required to fix issues (typically something like 'restart target' or 'restart both').

  Beware:

  • Make sure that table is exactly in the given format and that it is enclosed by <!-- Dependencies -->.
  • This is imperative for the tooling which extracts the contents of all those tables and creates the dependency overview and matrix.

  Source	Target	Protocol	Purpose	Error Detection	Troubleshoot
  Container A	Container B	REST	Describe for why A needs B and when.	Ex: logs, not working functions, etc.	Ex: restart target.
  Container A	Container C	SQL	Describe for why A needs C and when.	Ex: logs, not working functions, etc.	Ex: restart target.

  Notes:

  • If and only if the container name is not unique between region and central, use container(region) and container(central).
  • Container name in Target and Source cannot contain spaces`.

Customizing

This section describes configuration which can be done by operations. All configuration will be retained during upgrades.

{Describe only configuration which can (or has to be) done by operations. Please be aware that this configuration also has to be maintained, e.g. may not be lost during an update.}

{If you don't have any configuration like this, write: This component does not provide any configuration for operations.}

{Config 1}

{Describe config item, what it is about and where/how it can be configured.}

{Config 2}

{Describe config item, what it is about and where/how it can be configured.}

{Config n}

Monitoring

This section describes how to best check and monitor the state of the component.

Healthchecks

{Describe when the component is healthy - and possible root causes when it is unhealthy}

{Mention if there are special things to do to check further (no need to mention no-brainers)}

Grafana Dashboards

All components provide generic metrics which can be found in Grafana dashboards. Please refer to general monitoring section.

{Add information about dashboard specific to the component/service}

Troubleshooting

This section gives hints with respect to troubleshooting.

Logging

{Describe log-index used in Kibana } {Describe where to find other logging sinks, e.g. of wildfly, keycloak etc} {Describe how to increase the logging level if applicable. Also mention explicitly that this change shall be reverted after analysis!}

Error Handling

{Describe what can be done in case the component is in error. Be as concrete as possible. Which errors can an operator come across? How can she analyze them further, what can she do about it?}

Known Limitations

This section lists known limitations of the service:

• {Ado-Link or Title of Issue 1}
• {Ado-Link or Title of Issue 2}
• {Ado-Link or Title of Issue n}

{Only use for things which are NOT part of the release notes anyways. Examples: The need to use an API instead of UI to do some configuration, or a missing, but already planned observability feature... Anything where operations might think it should be there, but is not.}

Developer Information

{Use this for everything else, e.g. also developer configuration, pipelines, debug etc. }