Enabling optional features

VMware Tanzu (formerly Pivotal Cloud Foundry)

To enable the VMware Tanzu (formerly know as Pivotal Cloud Foundry (PCF)) platform dashboard, set the feature.pcf.enabled feature flag in the core.yaml file; for example:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.pcf.enabled
    enabled: true
...

For more information about this feature, see Monitoring Cloud Foundry and VMware Tanzu (formerly know as Pivotal Cloud Foundry).

VMware vSphere

To enable the VMware vSphere platform dashboard, set as follows in the core.yaml file:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.vsphere.enabled
    enabled: true
...

For more information about this feature, see Monitoring vSphere.

OpenStack

To enable the OpenStack platform dashboard, set as follows in the core.yaml file:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.openstack.enabled
    enabled: true
...

For more information about this feature, see Monitoring OpenStack.

IBM Power HMC

To enable the IBM Power HMC platform dashboard, set as follows in the core.yaml file:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.phmc.enabled
    enabled: true
...

For more information about this feature, see Monitoring IBM Power HMC.

IBM Power VC

To enable the IBM Power VC platform dashboard, set as follows in the core.yaml file:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.powervc.enabled
    enabled: true
...

For more information about this feature, see Monitoring IBM Power VC.

IBM IBM Z HMC

To enable the IBM IBM Z HMC platform dashboard, set as follows in the core.yaml file:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
featureFlags:
  - name: feature.zhmcEnabled.enabled
    enabled: true
...

For more information about this feature, see Monitoring IBM Z HMC.

Using instana-console datastore host

If instana-console is used as the database backend, a dual-host installation is recommended, with a second Clickhouse instance running on another host. For this purpose, the second host needs to be set up with a settings.hcl file as follows:

type      = "dual-clickhouse"
host_name = "<IP-accessible-from-the-k8s-cluster>"

dir {
  metrics    = "" // data dir for metrics
  traces     = "/mnt/traces" // data dir for log data
  data       = "/mnt/data" // data dir for any other data
  logs       = "/var/log/instana" // log dir
}

docker_repository {
  base_url = "artifact-public.instana.io"
  username = "_"
  password = "<Your-agent-key>"
}

Using Clickhouse operator cluster

In this senario set up another Clickhouse cluster according to the [operator instructions] (../datastores/3rd_party_operators.md#installing-data-store-operators/creating-clickhouse-cluster-with-a-dedicated-zookeeper-cluster).

Operator Core spec

On the operator side, the Core spec needs two Clickhouse entries and the feature flag.

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
clickhouseConfigs:
  - clusterName: local
    hosts:
      - <application_ch_cluster>
    schemas:
      - application
  - clusterName: local
    hosts:
      - <logs_ch_cluster>
    schemas:
      - logs
  ...
featureFlags:
  - name: feature.logging.enabled
    enabled: true
...

Furthermore, the respective cluster credentials must be included in the core config secret as follows.

...
datastoreConfigs:
  ...
  clickhouseConfigs:
    - user: clickhouse-application-user
      password: <USER_GENERATED_PASSWORD>
      adminUser: clickhouse-application-user
      adminPassword: <USER_GENERATED_PASSWORD>
      schemas:
        - application
    - user: clickhouse-logs-user
      password: <USER_GENERATED_PASSWORD>
      adminUser: clickhouse-logs-user
      adminPassword: <USER_GENERATED_PASSWORD>
      schemas:
        - logs
...

Run and configure BeeInstana datastore via instana-console host

To run BeeInstana as an additional Docker container on the instana-console database host, the following feature flag must be added to the file settings.hcl for new installations or to the file /root/.instana/effective-settings.hcl for existing installations.

...
feature "beeinstana" {
  enabled=true
}
...

After that, the change must still be applied to the system with an instana datastores update. After the restart, an additional container named aggregator should appear. This service must then be accessible via port 9998 from the Instana backend.

Note: Ensure that the free space is enough in the storage location for the metric data.

An estimated disk size of 1 million metrics can be derived from this table:

Run and configure BeeInstana datastore via Operator

For self-hosted Instana environments on Kubernetes with large metric loads, it is recommended that you deploy BeeInstana using the BeeInstana operator. See the documentation for using BeeInstana on Kubernetes.

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
...
datastoreConfigs:
  beeInstanaConfig:
    clustered: false # Set to true if beeinstana is operated as a cluster
    hosts:
      - <beeinstana_aggregator_host> # in a docker environment the FQDN of the docker host and in case of an BeeInstana operator cluster use the service name here
...
featureFlags:
  - name: feature.beeinstana.infra.metrics.enabled
    enabled: true
  - name: feature.beeinstana.histograms.enabled
    enabled: true
...

...
datastoreConfigs:
  ...
  beeinstanaConfig:
    - user: beeinstana-user
      password: <SECRET_PASSWORD>
...

Configure external storage for Synthetic monitoring

Before enabling Synthetic Monitoring, two external storage configuration needs to be configured in the storageConfigs section in the Core spec (synthetics, syntheticsKeystore).

Currently, GCloud, S3 or compatible Buckets are supported and file system is based on a multi read/write persistent volume.

For more information on storageConfigs spec for synthetics, refer storageConfigs

Enable Synthetic Monitoring components using feature flag

To enable Synthetic Monitoring components, set the following feature flag under the featureFlags configuration in the Core spec.

featureFlags:
    ...
      - name: feature.synthetics.enabled
      enabled: true