Kyma provides a Kubernetes-based solution for managing content that relies on the custom resource (CR) extensibility feature and Rafter as a backend mechanism. This solution allows you to upload multiple and grouped data for a given documentation topic and store them as Asset CRs in external buckets located in MinIO storage. All you need to do is to specify topic details, such as documentation sources, in an AssetGroup CR or a ClusterAssetGroup CR and apply it to a given Namespace or cluster. The CR supports various documentation formats, including images, Markdown documents, AsyncAPI, OData, and OpenAPI specification files. You can upload them as single, direct file URLs and packed assets (ZIP or TAR).

The content management solution offers these benefits:

• It provides a unified way of uploading different document types to a Kyma cluster.
• It supports baked-in documentation. Apart from the default documentation, you can add your own and group it as you like, the same way you use micro frontends to personalize views in the Console UI. For example, you can add contextual help for a given Service Broker in the Service Catalog.

This diagram provides more details of the AssetGroup CR flow, the controller that manages it, and underlying processes:

NOTE: This flow also applies to the ClusterAssetGroup CR.

1. The user creates an AssetGroup CR in a given Namespace.
2. The AssetGroup Controller (AGC) reads the AssetGroup CR definition.
3. If the AssetGroup CR definition does not provide a reference name (bucketRef) of the Bucket CR, the AssetsGroup Controller checks if the default Bucket CR already exists in this Namespace. If it does not exist yet, the AssetsGroup Controller creates a new Bucket CR with:

• the rafter-public-{ID} name, where {ID} is a randomly generated string, such as rafter-public-6n32wwj5vzq1k.
• the rafter.kyma-project.io/default: true label
• the rafter.kyma-project.io/access: public label

4. The AGC creates Asset CRs in the number corresponding to the number of sources specified in the AssetGroup CR. It adds rafter.kyma-project.io/type and rafter.kyma-project.io/asset-group labels to every Asset CR definition. It also adds the bucket name under the bucketRef field to every Asset CR definition.
5. The AGC verifies if the Asset CRs are in the Ready phase and updates the status of the AssetGroup CR accordingly. It also adds the bucket reference name to the AssetGroup CR.

This diagram provides an overview of the basic Asset and Bucket CRs flow and the role of particular components in this process:

1. The user creates a bucket through a Bucket CR.
2. The Bucket Controller (BC) listens for new events and acts upon receiving the Bucket CR creation event.
3. The BC creates the bucket in the MinIO Gateway storage.
4. The user creates an Asset CR which specifies the reference to the asset source location and the name of the bucket for storing the asset.
5. The Asset Controller (AC) listens for new events and acts upon receiving the Asset CR creation event.
6. The AC reads the CR definition, checks if the Bucket CR is available, and if its name matches the bucket name referenced in the Asset CR. It also verifies if the Bucket CR is in the Ready phase.
7. If the Bucket CR is available, the AC fetches the asset from the source location provided in the CR. If the asset is a ZIP or TAR file and the Asset CR's mode is set to package, the AC unpacks and optionally filters the asset before uploading it into the bucket.
8. Optionally, the AC validates, modifies the asset, or extracts asset's metadata if such a requirement is defined in the Asset CR. The AC communicates with the validation, mutation, and metadata services to validate, modify the asset, or extract asset's metadata according to the specification defined in the Asset CR.
9. The AC uploads the asset to MinIO Gateway, into the bucket specified in the Asset CR.
10. The AC updates the status of the Asset CR with the storage location of the file in the bucket.

Learn about the lifecycle of the Bucket custom resource (CR) and how its creation and removal affect other Rafter components.

NOTE: This lifecycle also applies to the ClusterBucket CR.

Create a Bucket CR

When you create a Bucket CR, the Bucket Controller (BC) receives a CR creation Event and creates a bucket with the name specified in the CR. It is created in the MinIO Gateway storage under the {CR_name}-{ID} location, such as test-bucket-1b19rnbuc6ir8, where {CR_name} is the name field from the Bucket CR and {ID} is a randomly generated string. The status of the CR contains a reference URL to the created bucket.

Remove a Bucket CR

When you remove the Bucket CR, the BC receives a CR deletion Event and removes the bucket with the whole content from MinIO Gateway.

The Asset Controller (AC) also monitors the status of the referenced bucket. The AC checks the Bucket CR status to make sure the bucket exists. If you delete the bucket, the AC receives information that the files are no longer accessible and the bucket was removed. The AC updates the status of the Asset CR to ready: False and removes the asset storage reference. The Asset CR is still available and you can use it later for a new bucket.

NOTE: This lifecycle also applies to the ClusterAssetGroup CR.

Asset CR manual changes

The AssetGroup custom resource (CR) coordinates Asset CR creation, deletion, and modification. The AssetGroup Controller (AGC) verifies AssetGroup definition on a regular basis and creates, deletes, or modifies Asset CRs accordingly.

The AssetGroup CR acts as the single source of truth for the Asset CRs it orchestrates. If you modify or remove any of them manually, the AGC automatically overwrites such an Asset CR or updates it based on the AssetGroup CR definition.

AssetGroup CR and Asset CR dependencies

Asset CRs and AssetGroup CRs are also interdependent in terms of names, definitions, and statuses.

Names

The name of every Asset CR created by the AGC consists of these three elements:

• The name of the AssetGroup CR, such as service-catalog.
• The source type of the given asset in the AssetGroup CR, such as asyncapi.
• A randomly generated string, such as 1b38grj5vcu1l.

The full name of such an Asset CR that follows the {assetGroup-name}-{asset-source}-{suffix} pattern is service-catalog-asyncapi-1b38grj5vcu1l.

Labels

There are two labels in every Asset CR created from AssetGroup CRs. Both of them are based on AssetGroup CRs definitions:

• rafter.kyma-project.io/type equals a given type parameter from the AssetGroup CR, such as asyncapi.

• rafter.kyma-project.io/asset-group equals the name metadata from the AssetGroup CR, such as service-catalog.

Statuses

The status of the AssetGroup CR depends heavily on the status phase of all Asset CRs it creates. It is:

• Ready when all related Asset CRs are already in the Ready phase.
• Pending when it awaits the confirmation that all related Asset CRs are in the Ready phase. If any Asset CR is in the Failed phase, the status of the AssetGroup CR remains Pending.
• Failed when processing of the AssetGroup CR fails. For example, the AssetGroup CR can fail if you provide incorrect or duplicated data in its specification.

The whole concept of Rafter relies on MinIO as the storage solution. It supports Kyma's manifesto and the "batteries included" rule by providing you with this on-premise solution by default.

Depending on the usage scenario, you can:

• Use MinIO for local development.
• Store your assets on a production scale using MinIO in Gateway mode.

Rafter ensures that both usage scenarios work for Kyma, without additional configuration of the built-in controllers.

Development mode storage

MinIO is an open-source asset storage server with Amazon S3-compatible API. You can use it to store various types of assets, such as documents, files, or images.

In the context of Rafter, the Asset Controller stores all assets in MinIO, in dedicated storage space.

Production storage

For the production purposes, Rafter uses MinIO Gateway which:

• Is a multi-cloud solution that offers the flexibility to choose a given cloud provider for the specific Kyma installation, including Azure, Amazon, and Google.
• Allows you to use various cloud providers that support the data replication and CDN configuration.
• Is compatible with Amazon S3 APIs.

TIP: Using Gateway mode may generate additional costs for storing buckets, assets, or traffic in general. To avoid them, verify the payment policy with the given cloud provider before you switch to Gateway mode.

See this tutorial to learn how to set MinIO to Google Cloud Storage Gateway mode.

Access MinIO credentials

For security reasons, MinIO credentials are generated during Kyma installation and stored inside the Kubernetes Secret object. You can obtain both the access key and the secret key in the development (MinIO) and production (MinIO Gateway) mode using the same commands.

• To get the access key, run:

• To get the secret key, run:

You can also set MinIO credentials directly using values.yaml files. For more details, see the official MinIO documentation.

Types

Rafter supports the following types of webhooks:

• Mutation webhook modifies fetched assets before the Asset Controller uploads them into the bucket. For example, this can mean asset rewriting through the regex operation or key-value, or the modification in the JSON specification. The mutation webhook service must return modified files to the Asset Controller.

• Validation webhook validates fetched assets before the Asset Controller uploads them into the bucket. It can be a list of several different validation webhooks that process assets even if one of them fails. It can refer either to the validation of a specific file against a specification or to the security validation. The validation webhook service must return the validation status when the validation completes.

• Metadata webhook allows you to extract metadata from assets and inserts it under the status.assetRef.files.metadata field in the (Cluster)Asset CR. For example, the Asset Metadata Service which is the metadata webhook implementation in Kyma, extracts front matter metadata from .md files and returns the status with such information as title and type.

Service specification requirements

If you create a specific mutation, validation, or metadata service for the available webhooks and you want Rafter to properly communicate with it, you must ensure that the API exposed by the given service meets the API contract requirements. These criteria differ depending on the webhook type:

NOTE: Services are described in the order in which Rafter processes them.

• mutation service must expose endpoints that:

  • accept parameters and content properties.
  • return the 200 response with new file content.
  • return the 304 response informing that the file content was not modified.

• validation service must expose endpoints that:

  • contain parameters and content properties.
  • return the 200 response confirming that validation succeeded.
  • return the 422 response informing why validation failed.

• metadata service must expose endpoints that:

  • pass file data in the "object": "string" format in the request body, where object stands for the file name and string is the file content.
  • return the 200 response with extracted metadata.

See the example of an API specification with the /convert, /validate, and /extract endpoints.

The Upload Service is an HTTP server that exposes the file upload functionality for MinIO. It contains a simple HTTP endpoint which accepts multipart/form-data forms. It uploads files to public system buckets.

The main purpose of the service is to provide a solution for hosting static files for components that use Rafter, such as the Application Connector. You can also use the Upload Service for development purposes to host files for Rafter, without the need to rely on external providers.

System buckets

The Upload Service creates a system-public-{generated-suffix} system bucket, where {generated-suffix} is a Unix nano timestamp in the 32-base number system. The public bucket has a read-only policy specified.

To enable the service scaling and to maintain the bucket configuration data between the application restarts, the Upload Service stores its configuration in the rafter-upload-service ConfigMap.

Once you upload the files, system buckets store them permanently. There is no policy to clean system buckets periodically.

The diagram describes the Upload Service flow:

Use the service outside the Kyma cluster

You can expose the service for development purposes. To use the Upload Service on a local machine, run the following command:

kubectl port-forward deployment/rafter-upload-svc 3000:3000 -n kyma-system

You can access the service on port 3000.

Upload files

To upload files, send the multipart form POST request to the /v1/upload endpoint. The endpoint recognizes the following field names:

• public that is an array of files to upload to a public system bucket.
• directory that is an optional directory for storing the uploaded files. If you do not specify it, the service creates a directory with a random name. If the directory and files already exist, the service overwrites them.

To do the multipart request using curl, run the following command:

curl -v -F directory='example' -F public=@sample.md -F public=@text-file.md -F public=@archive.zip http://localhost:3000/v1/upload

The result is as follows:

{
   "uploadedFiles": [
      {
         "fileName": "text-file.md",
         "remotePath": "{STORAGE_ADDRESS}/public-1b0sjap35m9o0/example/text-file.md",
         "bucket": "public-1b0sjap35m9o0",
         "size": 212
      },
      {
         "fileName": "archive.zip",
         "remotePath": "{STORAGE_ADDRESS}/public-1b0sjaq6t6jr8/example/archive.zip",
         "bucket": "public-1b0sjaq6t6jr8",
         "size": 630
      },
      {
         "fileName": "sample.md",
         "remotePath": "{STORAGE_ADDRESS}/public-1b0sjap35m9o0/example/sample.md",
         "bucket": "public-1b0sjap35m9o0",
         "size": 4414
      }
   ]
}

See the OpenAPI specification for the full API documentation.

AsyncAPI Service is an HTTP server enabled by default in Kyma to process AsyncAPI specifications. It only accepts multipart/form-data forms and contains two endpoints:

• /validate that validates the AsyncAPI specification against the AsyncAPI schema in version 2.0.0. AsyncAPI Service uses the AsyncAPI Parser for this purpose.

• /convert that converts the version and format of the AsyncAPI files. The service uses the AsyncAPI Converter to change the AsyncAPI specifications from older versions to version 2.0.0, and convert any YAML input files to the JSON format that is required to render the specifications in the Console UI.

See the asyncapi-service-openapi.yaml file for the full OpenAPI specification of the service.

The Front Matter Service is an HTTP server that exposes the functionality for extracting metadata from files. It contains a simple HTTP endpoint which accepts multipart/form-data forms. The service extracts front matter YAML metadata from text files of all extensions.

The main purpose of the service is to provide metadata extraction for Rafter controllers. That's why it is only available inside the cluster. To use it, define metadataWebhookService in Asset and ClusterAsset custom resources.

Front matter metadata

Front matter YAML metadata are YAML properties added at the beginning of a file, between --- lines. The following snippet represents an exemplary Markdown file with metadata specified:

---
title: Example document title
description: Example page description
order: 3
array:
 - foo
 - bar
---
## Lorem ipsum
Dolores sit amet

Use the service outside the Kyma cluster

You can expose the service for development purposes. To use the Front Matter Service on a local machine, run the following command:

kubectl port-forward deployment/rafter-front-matter-svc 3000:3000 -n kyma-system

You can access the service on port 3000.

Metadata files

To extract metadata from files, send the multipart form POST request to the /v1/extract endpoint. Specify the relative or absolute path to the file as a field name. To do the multipart request using curl, run the following command:

curl -v -F foo/foo.md=@foo.md -F bar/bar.yaml=@bar.yaml http://localhost:3000/v1/extract

The result is as follows:

{
  "data": [
    {
      "filePath": "foo/foo.md",
      "metadata": {
        "no": 3,
        "title": "Access logs",
        "type": "Details"
      }
    },
    {
      "filePath": "bar/bar.yaml",
      "metadata": {
        "number": 9,
        "title": "Hello world",
        "url": "https://kyma-project.io"
      }
    }
  ]
}

See the OpenAPI specification for the full API documentation.

The assetgroups.rafter.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define an orchestrator that creates Asset CRs for a specific asset type. To get the up-to-date CRD and show the output in the YAML format, run this command:

kubectl get crd assetgroups.rafter.kyma-project.io -o yaml

Sample custom resource

This is a sample AssetGroup custom resource (CR) that provides details of the Asset CRs for the markdown, asyncapi, and openapi source types.

apiVersion: rafter.kyma-project.io/v1beta1
kind: AssetGroup
metadata:
  name: slack
  labels:
    rafter.kyma-project.io/view-context: service-catalog
    rafter.kyma-project.io/group-name: components
    rafter.kyma-project.io/order: "6"
spec:
  displayName: Slack
  description: "Slack documentation"
  bucketRef:
    name: test-bucket
  sources:
    - type: markdown
      name: markdown-slack
      mode: single
      parameters:
        disableRelativeLinks: "true"
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/README.md
    - type: asyncapi
      displayName: "Slack"
      name: asyncapi-slack
      mode: single
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/events-api/slack_events_api_async_v1.json
    - type: openapi
      name: openapi-slack
      mode: single
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/web-api/slack_web_openapi_v2.json
status:
  lastHeartbeatTime: "2019-03-18T13:42:55Z"
  message: Assets are ready to use
  phase: Ready
  reason: AssetsReady

Custom resource parameters

This table lists all possible parameters of a given resource together with their descriptions:

NOTE: The AssetGroup Controller automatically adds all parameters marked as Not applicable to the AssetGroup CR.

TIP: ClusterAsset CRs have an additional configmap mode that allows you to refer to asset sources stored in ConfigMaps. If you use this mode, set the url parameter to {namespace}/{configMap-name}, like url: default/sample-configmap. This mode is not enabled in Kyma. To check how it works, see Rafter tutorials for examples.

Status reasons

Processing of an AssetGroup CR can succeed, continue, or fail for one of these reasons:

Related resources and components

These are the resources related to this CR:

These components use this CR:

The buckets.rafter.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define the name of the cloud storage bucket for storing assets. To get the up-to-date CRD and show the output in the YAML format, run this command:

kubectl get crd buckets.rafter.kyma-project.io -o yaml

Sample custom resource

This is a sample resource that defines the storage bucket configuration.

apiVersion: rafter.kyma-project.io/v1beta1
kind: Bucket
metadata:
  name: test-sample
  namespace: default
spec:
  region: "us-east-1"
  policy: readonly
status:
  lastHeartbeatTime: "2019-02-04T11:50:26Z"
  message: Bucket policy has been updated
  phase: Ready
  reason: BucketPolicyUpdated
  remoteName: test-sample-1b19rnbuc6ir8
  observedGeneration: 1
  url: https://{STORAGE_ADDRESS}/test-sample-1b19rnbuc6ir8

Custom resource parameters

This table lists all possible parameters of a given resource together with their descriptions:

NOTE: The Bucket Controller automatically adds all parameters marked as Not applicable to the Bucket CR.

Status reasons

Processing of a Bucket CR can succeed, continue, or fail for one of these reasons:

Related resources and components

These are the resources related to this CR:

These components use this CR:

The clusterassets.rafter.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define an asset to store in a cloud storage bucket. To get the up-to-date CRD and show the output in the YAML format, run this command:

kubectl get crd clusterassets.rafter.kyma-project.io -o yaml

Sample custom resource

This is a sample ClusterAsset CR configuration that contains mutation, validation, and metadata services:

apiVersion: rafter.kyma-project.io/v1beta1
kind: ClusterAsset
metadata:
  name: my-package-assets
spec:
  source:
    mode: single
    parameters:
      disableRelativeLinks: "true"
    url: https://some.domain.com/main.js
    mutationWebhookService:
    - name: swagger-operations-svc
      namespace: default
      endpoint: "/mutate"
      filter: \.js$
      parameters:
        rewrite: keyvalue
        pattern: \json|yaml
        data:
          basePath: /test/v2
    validationWebhookService:
    - name: swagger-operations-svc
      namespace: default
      endpoint: "/validate"
      filter: \.js$
    metadataWebhookService:
    - name: swagger-operations-svc
      namespace: default
      endpoint: "/extract"
      filter: \.js$
  bucketRef:
    name: my-bucket
  displayName: "Operations svc"
status:
  phase: Ready
  reason: Uploaded
  message: Asset content has been uploaded
  lastHeartbeatTime: "2018-01-03T07:38:24Z"
  observedGeneration: 1
  assetRef:
    baseUrl: https://{STORAGE_ADDRESS}/my-bucket-1b19rnbuc6ir8/my-package-assets
    files:
    - metadata:
        title: Overview
      name: README.md
    - metadata:
        title: Benefits of distributed storage
        type: Details
      name: directory/subdirectory/file.md

Custom resource parameters

This table lists all possible parameters of a given resource together with their descriptions:

NOTE: The ClusterAsset Controller automatically adds all parameters marked as Not applicable to the ClusterAsset CR.

Status reasons

Processing of a ClusterAsset CR can succeed, continue, or fail for one of these reasons:

Related resources and components

These are the resources related to this CR:

These components use this CR:

The clusterassetgroups.rafter.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define an orchestrator that creates ClusterAsset CRs for a specific asset type. To get the up-to-date CRD and show the output in the YAML format, run this command:

kubectl get crd clusterassetgroups.rafter.kyma-project.io -o yaml

Sample custom resource

This is a sample ClusterAssetGroup custom resource (CR) that provides details of the ClusterAsset CR for the markdown source type.

apiVersion: rafter.kyma-project.io/v1beta1
kind: ClusterAssetGroup
metadata:
  name: service-mesh
  labels:
    rafter.kyma-project.io/view-context: docs-ui
    rafter.kyma-project.io/group-name: components
    rafter.kyma-project.io/order: "6"
spec:
  displayName: "Service Mesh"
  description: "Overall documentation for Service Mesh"
  bucketRef:
    name: test-bucket
  sources:
    - type: markdown
      displayName: "Documentation"
      name: docs
      mode: package
      parameters:
        disableRelativeLinks: "true"
      url: https://github.com/kyma-project/kyma/archive/master.zip
      filter: /docs/service-mesh/docs/
status:
  lastHeartbeatTime: "2019-03-18T13:42:55Z"
  message: Assets are ready to use
  phase: Ready
  reason: AssetsReady

Custom resource parameters

This table lists all possible parameters of a given resource together with their descriptions:

NOTE: The ClusterAssetGroup Controller automatically adds all parameters marked as Not applicable to the ClusterAssetGroup CR.

Status reasons

Processing of a ClusterAssetGroup CR can succeed, continue, or fail for one of these reasons:

Related resources and components

These are the resources related to this CR:

These components use this CR:

The clusterbuckets.rafter.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define the name of the cloud storage bucket for storing assets. To get the up-to-date CRD and show the output in the YAML format, run this command:

kubectl get crd clusterbuckets.rafter.kyma-project.io -o yaml

Sample custom resource

This is a sample resource that defines the storage bucket configuration.

apiVersion: rafter.kyma-project.io/v1beta1
kind: ClusterBucket
metadata:
  name: test-sample
spec:
  region: "us-east-1"
  policy: readonly
status:
  lastHeartbeatTime: "2019-02-04T11:50:26Z"
  message: Bucket policy has been updated
  phase: Ready
  reason: BucketPolicyUpdated
  remoteName: test-sample-1b19rnbuc6ir8
  url: https://{STORAGE_ADDRESS}/test-sample-1b19rnbuc6ir8
  observedGeneration: 1

Custom resource parameters

This table lists all possible parameters of a given resource together with their descriptions:

NOTE: The ClusterBucket Controller automatically adds all parameters marked as Not applicable to the ClusterBucket CR.

Status reasons

Processing of a ClusterBucket CR can succeed, continue, or fail for one of these reasons:

Related resources and components

These are the resources related to this CR:

These components use this CR:

By default, you install Kyma with Rafter in MinIO stand-alone mode. This tutorial shows how to set MinIO to Gateway mode on different cloud providers using an override.

CAUTION: The authentication and authorization measures required to edit the assets in the public cloud storage may differ from those used in Rafter. That's why we recommend using separate subscriptions for Minio Gateway to ensure that you only have access to data created by Rafter, and to avoid compromising other public data.

CAUTION: Cloud providers offer different payment policies for their services, such as bucket storage or network traffic. To avoid unexpected costs, verify the payment policy with the given provider before you start using Gateway mode.

Prerequisites

Steps

You can set MinIO to the given Gateway mode both during and after Kyma installation. In both cases, you need to create and configure an access key for your cloud provider account, apply a Secret and a ConfigMap with an override to a cluster or Minikube, and trigger the Kyma installation process. This tutorial shows how to switch to MinIO Gateway in the runtime, when you already have Kyma installed locally or on a cluster.

CAUTION: Buckets created in MinIO without using Bucket CRs are not recreated or migrated while switching to MinIO Gateway mode.

Create required cloud resources

Configure MinIO Gateway mode

CAUTION: If you want to activate MinIO Gateway mode before you install Kyma, you need to manually add the ConfigMap and the Secret to the installer-config-local.yaml.tpl template located under the installation/resources subfolder before you run the installation script. In this case you start from scratch, so add the ConfigMap without these lines that trigger the default buckets migration from MinIO to MinIO Gateway:

Click to copy

controller-manager.minio.podAnnotations.persistence: "off"
upload-service.minio.podAnnotations.persistence: "off"

Trigger installation

Trigger Kyma installation or update it by labeling the Installation custom resource. Run:

kubectl -n default label installation/kyma-installation action=install

It may happen that the Upload Service returns 502 Bad Gateway with the The specified bucket does not exist message. It means that the bucket has been removed or renamed.

If the bucket is removed, delete the ConfigMap:

kubectl -n kyma-system delete configmaps rafter-upload-service

If the bucket exists but with a different name, set a proper name in the ConfigMap:

kubectl -n kyma-system edit configmaps rafter-upload-service

After that, restart the Upload Service - it will create a new bucket or use the renamed one:

kubectl -n kyma-system delete pod -l app.kubernetes.io/name=upload-service

This table shows the AsyncAPI Service custom metrics, their types, and descriptions.

Apart from the custom metrics, the AsyncAPI Service also exposes default Prometheus metrics for Go applications.

To see a complete list of metrics, run this command:

kubectl -n kyma-system port-forward svc/rafter-asyncapi-service 80

To check the metrics, open a new terminal window and run:

curl http://localhost:80/metrics

TIP: To use these commands, you must have a running Kyma cluster and kubectl installed. If you cannot access port 80, redirect the metrics to another one. For example, run kubectl -n kyma-system port-forward svc/rafter-asyncapi-service 8080:80 and update the port in the localhost address.

See the Monitoring documentation to learn more about monitoring and metrics in Kyma.

This table shows the Upload Service custom metrics, their types, and descriptions.

Apart from the custom metrics, the Upload Service also exposes default Prometheus metrics for Go applications.

To see a complete list of metrics, run this command:

kubectl -n kyma-system port-forward svc/rafter-upload-service 80

To check the metrics, open a new terminal window and run:

curl http://localhost:80/metrics

TIP: To use these commands, you must have a running Kyma cluster and kubectl installed. If you cannot access port 80, redirect the metrics to another one. For example, run kubectl -n kyma-system port-forward svc/rafter-upload-service 8080:80 and update the port in the localhost address.

See the Monitoring documentation to learn more about monitoring and metrics in Kyma.

This table shows the Front Matter Service custom metrics, their types, and descriptions.

Apart from the custom metrics, the Front Matter Service also exposes default Prometheus metrics for Go applications.

To see a complete list of metrics, run this command:

kubectl -n kyma-system port-forward svc/rafter-front-matter-service 80

To check the metrics, open a new terminal window and run:

curl http://localhost:80/metrics

TIP: To use these commands, you must have a running Kyma cluster and kubectl installed. If you cannot access port 80, redirect the metrics to another one. For example, run kubectl -n kyma-system port-forward svc/rafter-front-matter-service 8080:80 and update the port in the localhost address.

See the Monitoring documentation to learn more about monitoring and metrics in Kyma.

As an external, open-source file storage solution, MinIO exposes its own metrics. See the official documentation for details. Rafter comes with a preconfigured ServiceMonitor CR that enables Prometheus to scrap MinIO metrics. Using the metrics, you can create your own Grafana dashboard or reuse the dashboard that is already prepared.

Apart from the custom metrics, MinIO also exposes default Prometheus metrics for Go applications.

To see a complete list of metrics, run this command:

kubectl -n kyma-system port-forward svc/rafter-minio 9000

To check the metrics, open a new terminal window and run:

curl http://localhost:9000/minio/prometheus/metrics

TIP: To use these commands, you must have a running Kyma cluster and kubectl installed. If you cannot access port 9000, redirect the metrics to another one. For example, run kubectl -n kyma-system port-forward svc/rafter-minio 8080:9000 and update the port in the localhost address.

See the Monitoring documentation to learn more about monitoring and metrics in Kyma.