xk6-common-util
v1.0.6
Published
This library offers a collection of utility functions and modules that address common funcunalities that are used across other related projects.
Downloads
6
Readme
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: [email protected]
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, usecontainer(region)
andcontainer(central)
.- Container name in
Target
andSource
cannot contain spaces`.
- Make sure that table is exactly in the given format and that it is enclosed by
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. }