Instana バックエンドのインストール

• Instana の kubectl プラグインをインストールする必要があります。
• 必要なデータ・ストアが稼働している必要があります。 「データストアの設定」 を参照してください。
• Instana Enterpriseオペレーターがインストールされている必要があります。

Core および Unitを作成する前に、 artifact-public.instana.io レジストリーから Core および Unit イメージをプルできるように、名前空間を作成し、名前空間の一連のシークレットを配置する必要があります。

コア は、共有コンポーネントを表し、データ・ストア・アクセスの構成を担当します。 結果として、ほとんどの構成がここで行われます。

詳細については、 『 API リファレンス』 を参照してください。

Core カスタム・リソースには、バージョン instana.io/v1beta2 および種類 Coreが必要です。 「コア」 の構成は、 spec セクションに移動します。

core.yaml ファイルを作成します。 Core の構成は、 spec セクションにあります。

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  ...
 

クラスタ内の少なくとも1つのノードが「untainted」であり、ラベルを持っていない node-role.kubernetes.io/monitor: "true"ことを確認してください。 tolerations とノードセレクタを指定するには、 core.yaml 以下の行を に追加してください。

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

以下のように、いくつかの基本構成を行います。

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  # The domain under which Instana is reachable
  baseDomain: <instana.example.com>

  # Depending on your cluster setup, you may need to specify an image pull secret.
  imagePullSecrets:
    - name: my-registry-secret

  # This configures an SMTP server for sending e-mails.
  # Alternatively, Amazon SES is supported. Please see API reference for details.
  emailConfig:
    smtpConfig:
      from: smtp@example.com
      host: smtp.example.com
      port: 465
      useSSL: true
 

オペレーターは、個々のコンポーネント・ポッドに割り当てられるリソースを決定する一連の事前定義リソース・プロファイルを使用します。 以下のプロファイルを使用できます。 デフォルトでは、何も構成されていない場合は medium が使用されます。

• small
• medium
• large

spec:
  resourceProfile: large
 

さらに、コンポーネント・ポッドごとにカスタム CPU およびメモリー・リソースを構成できます。 以下の例では、 filler コンポーネントが使用されます。 filler を、使用するコンポーネントに置き換え、提供する合計を使用して CPU およびメモリー・リソースを指定します。

spec:
  componentConfigs:
    - name: filler
      resources:
        requests:
          cpu: 2.5
          memory: 5000Mi
        limits:
          cpu: 4
          memory: 20000Mi
 

以下の設定は非推奨です。 「ゲートウェイ設定」 で指定された設定を使用してください。

アクセプターとは、 Instana エージェントがトレースやメトリクスを Instana バックエンドに送信するために到達する必要があるエンドポイントのことです。 アクセプターは通常、以前に 「基本構成」 セクションで構成された baseDomain のサブドメインです。

spec:
  agentAcceptorConfig:
    host: ingress.<instana.example.com>
    port: 443
 

以下の種類のイングリッストラフィックについて、ホストとポートを設定できます：

• Instana エージェント
• シンセティック
• サーバーレス
• OTLP (HTTP/gRPC)
• EUM
• OpAMP

各種 Instana アクセプタのホストとポートを設定するには、 CoreSpec に以下の設定を追加してください：

spec:
  gatewayConfig:
    enabled: true # enables gateway-v2 and gateway-controller
  acceptors:
    agent:
      host: ingress.<instana.example.com>
      port: 443
    opamp:
      host: opamp-acceptor.<instana.example.com>
      port: 443
    otlp:
      http:
        host: otlp-http.<instana.example.com>
        port: 443
      grpc:
        host: otlp-grpc.<instana.example.com>
        port: 443
    eum:
      host: eum.<instana.example.com>
      port: 443
    synthetics:
      host: synthetics.<instana.example.com>
      port: 443
    serverless:
      host: serverless.<instana.example.com>
      port: 443
 

以下の例は、さまざまな要件に応じてアクセプターのトラフィック取り込みを設定する方法を示しています：

1. 単一のポート（443）でサブドメインを使用する。この方法により、サブドメインを使用して各アクセプターへのトラフィックを区別しつつ、公開するポートを1つ（443）に限定することができます。

    spec:
      acceptors:
        agent:
          host: ingress.<instana.example.com>
          port: 443
        opamp:
          host: opamp-acceptor.<instana.example.com>
          port: 443
        otlp:
          http:
            host: otlp-http.<instana.example.com>
            port: 443
          grpc:
            host: otlp-grpc.<instana.example.com>
            port: 443
        eum:
          host: eum.<instana.example.com>
          port: 443
        synthetics:
          host: synthetics.<instana.example.com>
          port: 443
        serverless:
          host: serverless.<instana.example.com>
          port: 443
    

2. 単一のドメインで異なるポートを使用する この方法により、単一のドメインを使用しつつ、ポート番号に基づいて受信トラフィックを区別することができます。 「Custom Edition 」 1.3.0 以降のみ、単一のドメインで設定できます。

    spec:
      acceptors:
        agent:
          port: 1444
        otlp:
          http:
            port: 4318
          grpc:
            port: 4317
        eum:
          port: 1555
        synthetics:
          port: 1666
        serverless:
          port: 1777
    

   この場合、クラスタ内のロードバランサーの設定を更新し、異なるアクセプタポートを公開する必要があります。 「ロードバランサーの設定」および「 DNS 」を参照してください。

カスタムエディション環境では、すべてのテナントのトラフィックを単一のベースドメイン経由でルーティングできます。 この動作を有効にするには、 CoreSpec で次のプロパティを設定してください：

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    ...
    - name: config.url.format.pathStyle
      value: "true"
    ...
 

この動作を有効にすると、すべての Instana テナントのUIにアクセスするための URL は、 <unitname>-<tenantname>.<basedomain>.comではなく <basedomain>.com/<unitname>/<tenantname> で提供されます。 「 Instana 」のすべてのIngressトラフィックは、「 ゲートウェイ設定 」 の2番目の例にある設定と組み合わせることで、 DNS 内の単一のAレコードを経由してルーティングできます。

Custom Edition 環境では、 gateway-v2 コンポーネント用の KubernetesLoadBalancer サービスの自動作成がサポートされています。 LoadBalancer のサービスを手動で作成する必要はありません。

この機能を有効にするには、 CoreSpec に以下の設定を追加してください：

spec:
  gatewayConfig:
    enabled: true
    gateway:
      loadBalancerConfig:
        enabled: true # enables automatic loadbalancer creation
        ip: <your public IP>
        externalTrafficPolicy: Local # default
        annotations:
          your-annotation-key: your-annotation-value
 

この機能を有効にする前に、すべての Instana のインバウンドトラフィックを gateway-v2 サービスにルーティングするためのフロントプロキシがデプロイされていることを確認してください。 各アクセプタごとに個別のポートが設定されている場合は、フロントプロキシがトラフィックをそれらのポートに転送するようにしてください。 gateway-v2 上のポートは、フロントプロキシによって公開されるポートと1対1で対応していなければなりません。

Custom Edition 環境では、 TLS による接続終了を無効にする（つまり、 SSL を含まない着信トラフィックを受け入れる）ことも可能です。 このオプションは、Custom Edition 環境の前に、 TLS の接続終了を処理するフロントプロキシを展開する場合に役立ちます。

この動作を有効にするには、 CoreSpec に以下の設定を追加してください：

spec:
  gatewayConfig:
    enabled: true
    disableTLS: true # disables TLS termination for all ingress traffic
 

生のスパン・データを保管するには、以下の 3 つのオプションのいずれかを使用する必要があります。

• S3 (または互換)
• Google Cloud Storage (GCS)
• Azure ファイル・システム
• ファイル・システム

S3 エンドポイントは、リージョンによって異なります。

S3 (または互換性のあるもの) を使用して生スパン・データを保管するには、以下の例に示すように Core を構成します。

spec:
  storageConfigs:
    rawSpans:
      s3Config:
        # Endpoint address of the object storage.
        # S3 Endpoint Ref: https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region
        endpoint:
        # Region.
        region: eu-central-1
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using IRSA
  # Appropriate IAM Role should be provisioned including IAM policy with sufficient privileges.
  serviceAccountAnnotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
 

GCS を使用して生のスパン・データを保管するには、 Core を以下のように構成します。

spec:
  storageConfigs:
    rawSpans:
      gcloudConfig:
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using Workload Identity
  serviceAccountAnnotations:
    iam.gke.io/gcp-service-account: rawspans@myproject.iam.gserviceaccount.com
 

未加工のスパン・データを保管するために Azure Filesystem を使用するには、以下の手順を実行します。

1. ストレージ・アカウント名とボリュームを使用してシークレットを作成します。

   kubectl create secret generic storage-account --from-literal=azurestorageaccountname={storage_account_name} --from-literal=azurestorageaccountkey={storage_account_key} -n instana-core
    

2. pv.yamlを作成して、永続ボリュームを作成します。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: my-nfs-volume
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     azureFile:
       secretName: storage-account
       shareName: <storage_account_name>
       readOnly: false
     persistentVolumeReclaimPolicy: Retain
    

3. 以下の例に示すように、 Core を構成します。

   spec:
     storageConfigs:
       rawSpans:
         pvcConfig:
           accessModes:
             - ReadWriteMany
           resources:
             requests:
               storage: 100Gi
           volumeName: my-nfs-volume
    

生のスパン・データを保管するためにファイル・システムを使用するには、 「コア」 を以下のように構成します。

spec:
  storageConfigs:
    rawSpans:
      pvcConfig:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 100Gi
        volumeName: my-nfs-volume
        storageClassName: ""
 

Coreの spec セクションで、以下のデータ・ストアを構成する必要があります。

• cassandra
• postgres
• clickhouse
• elasticsearch
• kafka

注:

• 少なくとも、データ・ストアごとにアドレスを構成する必要があります。 以下の例を参照してください。

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - hosts:
            - <IP address or hostname>
      postgresConfigs:
        - hosts:
            - <IP address or hostname>
      elasticsearchConfig:
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        hosts:
          - <IP address or hostname>
   

  < IP address or hostname> をデータ・ストアの IP アドレスまたはホスト名に置き換えます。

• サードパーティ製のOperatorを使用してデータストアを同じクラスタにインストールする場合、以下の設定例に示すように、クラスタ内の DNS ホスト名を使用してデータストアに接続するように datastoreConfigs 設定できます

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - authEnabled: true
          datacenter: cassandra
          hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - authEnabled: true
          clusterName: local
          hosts:
            - <IP address or hostname>
            - <IP address or hostname>
      elasticsearchConfig:
        authEnabled: true
        clusterName: instana
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        saslMechanism: SCRAM-SHA-512
        authEnabled: true
        hosts:
          - <IP address or hostname>
      postgresConfigs:
        - authEnabled: true
          hosts:
            - <IP address or hostname>
   

• datacenter 属性を使用して、コア仕様の cassandraConfigs セクションで正確な Cassandra データ・センター名 (デフォルト: cassandra) が構成されていることを確認します。

• Power アーキテクチャーの場合: datacenter 属性を使用して、コア仕様の cassandraConfigs セクションで正確な Cassandra データ・センター名 (デフォルト: datacenter1) が構成されていることを確認します。

• ClickHouse (デフォルト: local) および Elasticsearch (デフォルト: onprem_onprem) は、 clusterName 属性を介してクラスター名を受け入れます。

  データ・ストアでは、 tcp ポートを構成できます。 さらに、 clickhouse および elasticsearch用に http ポートを構成することもできます。

  spec:
    datastoreConfigs:
      clickhouseConfigs:
        - clusterName: local
          hosts:
            - <IP address or hostname>
          ports:
            - name: tcp
              port: 9000
            - name: http
              port: 8123
   

ポートが構成されていない場合は、以下のデフォルト値が適用されます。

デフォルトの保存設定の上書きはオプションであり、意識的に行う必要があります。 これらの保存設定値は、 CoreSpecのプロパティーとして構成されます。

以下の保存プロパティーはメトリック・ロールアップ・テーブル用であり、リストされている値は秒単位のデフォルト値です。 値がゼロの場合、この期間のロールアップは除去されません。 サイズが小さいロールアップの値がゼロになると、ディスクがすぐに満杯になってしまう可能性があります。

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: retention.metrics.rollup5
      value: "86400"
    - name: retention.metrics.rollup60
      value: "2678400"
    - name: retention.metrics.rollup300
      value: "8035200"
    - name: retention.metrics.rollup3600
      value: "34214400"
    - name: retention.metrics.rawPayload
      value: "2592000"
...
 

アプリケーションの監視とエンドユーザー監視（EUM）では、短期データと長期データの両方に同じ保存設定が適用されます。 短期保存領域には完全なデータが保存され、デフォルトの保存期間は7日間です。 長期保存では、データの1%をランダムに抽出して保存され、デフォルトでは13ヶ月間保存されます。 デフォルト設定でデータを継続的に取り込む場合、長期保存データは短期保存データの約半分程度のディスク容量しか使用しません。

短期保存期間は2日から31日の間で設定できます。 長期保存期間は31日から396日の間で設定できます。 これらの範囲外の値を指定すると、 Instana のサービスは起動時に失敗します。

Instana は、完全な短期データとサンプリングされた長期データに加え、クエリのパフォーマンスを向上させるために集計メトリクスを保持しています。 Instana 集計メトリクスの保持期間を設定することはできず、デフォルトで31日に設定されます。

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.appdata.shortterm.retention.days
      value: "7"

    - name: config.appdata.longterm.retention.days
      value: "396"
...
 

保持設定の変更は、アプリケーションのパースペクティブおよびエンドユーザーの監視データに、それぞれ異なる影響を与えます：

• アプリケーションの観点からの短期的な保持：システムは新しい設定を新規データにのみ適用します。 保存時に適用されていた保存期間の設定に従って、以前に保存されたデータを削除します。 変更後、実際のデータ保持期間は徐々に新しい値に合わせて調整されます。
• EUMの短期保持：システムは、既存データと新規データの両方に新しい設定を適用します。 現在の保存期間の設定に基づいて、すべてのデータを削除します。
• 長期保存：システムは、アプリケーションの視点およびEUMにおいて、既存および新規のすべての長期データに変更を適用します。

アプリケーション・パースペクティブ・データに対する以下の影響を確認してください。

例：

• config.appdata.shortterm.retention.days 7日間から14日間に変更されます：変更前に保存されたデータは、7日を経過するとシステムによって削除されます。 変更後に保存されたデータは、14日以上経過すると削除されます。 システムが完全な 14‑day の履歴データを構築するには、14日間かかります。 ただし、 Instana は、14日分の完全なデータが利用可能であると即座に想定するため、移行期間中は一時的に不正確な結果が生じる可能性があります。
• config.appdata.shortterm.retention.days 14日間から7日間に変更されます：変更前、14日以上経過したデータはシステムによって削除されます。 変更後に保存されたデータは、7日以上経過すると削除されます。 保存されている短期データの容量は、14日間かけて新しいサイズまで縮小されます。 ただし、 Instana では、過去7日を超えるクエリは、長期データまたは集計データに限定されます。
• config.appdata.longterm.retention.days 396日から60日に変更されます：システムは、60日以上経過した長期のサンプリングデータを削除します。 次回のクリーンアップサイクルにおいて、現在保存されているデータのうち、60日以上経過したものを削除します。
• config.appdata.longterm.retention.days が60日から120日に変更されました：システムは、120日以上経過した長期サンプリングデータのみを削除します。 すでに60日を経過したデータも、 120‑day の延長期間中は引き続き利用可能です。

エンドユーザーの監視データに与える影響については、以下をご覧ください：

例：

• config.appdata.shortterm.retention.days 保存期間が7日から14日に変更されました：14日以上経過した短期データは削除されます。
• config.appdata.shortterm.retention.days 14日間から7日間に変更されました：7日以上経過した短期データは削除されます。
• config.appdata.longterm.retention.days 396日から60日に変更されました：60日以上経過した長期のサンプリングデータはすべて削除されます。
• config.appdata.longterm.retention.days 60日から120日に変更されます：120日以上経過したすべての長期サンプリングデータは削除されます。

シンセティック・モニターには、デフォルトが 60 日の別個のデータ保存プロパティーがあります。 シンセティック・テスト結果とシンセティック・テスト結果の詳細の両方の保存は、この設定によって制御されます。

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.synthetics.retention.days
      value: "60"
...
 

シンセティック・モニター・データに対する以下の影響を確認してください。

例：

• config.synthetics.retention.days は 60 日から 90 日に変更されます。構成変更前に保管されたデータは、60 日より古い場合は削除され、構成変更後に保管されたデータは、90 日より古い場合は削除されます。
• config.synthetics.retention.days は 60 日から 7 日に変更されます。構成変更前に保管されたデータは、60 日より古い場合は削除され、構成変更後に保管されたデータは、7 日より古い場合は削除されます。

Core の構成ファイルの準備ができたら、以下のように適用します。

kubectl apply -f path/to/core.yaml
 

すべてのポッドが実行されているかどうかを確認してから、以下の手順を実行します。

kubectl get pods -n instana-core
 

「instana-core」ネームスペース内の「core」リソースの状態を確認してください：

kubectl get core -n instana-core
 

出力例を以下に示します：

NAME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-core   1.2.0     3.289.589-0       Ready                 Ready
 

ユニットとテナントを作成するのは簡単です。

ユニットとテナントを作成するには、次の例のように unit.yaml 「Unit YAML 」ファイルを作成します

apiVersion: instana.io/v1beta2
kind: Unit
metadata:
  namespace: instana-units
  name: tenant0-unit0
spec:
  # Must refer to the namespace of the associated Core object that was created previously
  coreName: instana-core

  # Must refer to the name of the associated Core object that was created previously
  coreNamespace: instana-core

  # The name of the tenant
  # Tenant name must match the regular expression pattern `^[a-z][a-z0-9]*$`
  # Tenant name must not exceed a maximum length of 15 characters
  # Tenant name must begin with an alphabetical character
  # Tenant name can consist of alphanumeric characters
  # Characters must be in lowercase
  tenantName: tenant0

  # The name of the unit within the tenant
  unitName: unit0

  # The same rules apply as for Cores. May be ommitted. Default is 'medium'
  resourceProfile: large
 

構成の準備ができたら、以下のように設定を適用します。

kubectl apply -f path/to/unit.yaml
 

すべてのポッドが実行されているかどうかを確認してから、以下の手順を実行します。

kubectl get pods -n instana-units
 

「instana-units」ネームスペース内のユニットのリストを取得します：

kubectl get unit -n instana-units
 

出力例を以下に示します：

AME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-unit   1.2.0     3.289.589-0       Ready                 Ready
 

tolerations およびノードセレクタを指定するために、 unit.yaml 以下の行を に追加してください

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

一部の機能は、デフォルトでは自己ホスト・バックエンドで有効になっていません。 このような機能は、追加の構成オプションを使用して有効にすることができます。

オプション機能の詳細および有効化方法については、 「オプション機能の有効化」 を参照してください。