セルフホスト型クラシックエディションのインストール( Docker )

インストール中、 Instana は各コンポーネントに必要なサイズを自動的に設定します。この計算は、お使いのマシンで利用可能なリソースの総量に基づいて行われます。

Classic Edition は、複数のコンポーネントとサービスで構成されており、それぞれが個別の Docker コンテナとして実行され、サイズ設定に関して独自の構成を持っています。

注: セルフホスト型クラシックエディション( Docker ) は、機能や性能が限定されています。 さらなる機能や性能を活用するには、 Standard Edition をインストールするか、移行してください。 Instana を初めて導入する場合は、Classic Editionではなく Standard Edition をインストールしてください。

シングルホストアーキテクチャ

シングルホストのインストールは、軽量で使いやすく、中小規模の環境に最適です。 これは、 Instana プラットフォームに必要なすべてのコンポーネントを Docker コンテナとして、単一のホスト上で Instana を実行することを意味します。

このインストール方法の利点としては、その簡便さと迅速なセットアップ、リソース要件の低さ、そしてテストや開発に適している点が挙げられます。 しかし、この導入方法にはスケーラビリティに制限があり、冗長性が欠如しており、高可用性の選択肢も限られています。

セルフホスト型クラシックエディション( Docker ) のインストール方法については、 セルフホスト型クラシックエディションのインストール( Docker )」 を参照してください。

デュアルホストアーキテクチャ

デュアルホスト構成は、 ClickHouse が1つのホストに、 ZooKeeper が別のホストに導入されている環境向けに設計されています。 Instana の残りのコンポーネントとデータストアは、2台目のホストにデプロイされます。

このアプローチにより、秒間リクエスト数(負荷)に基づいて、 ClickHouse を Instana の他の部分とは独立して、より適切にスケーリングできるようになります。 ホストを分離することで、 Instana と ClickHouse がより多くの CPU やメモリを必要とする場合に、それぞれに独立してリソースを割り当てられるため、リソース配分がより効率的になります。

ただし、デュアルホスト構成はシングルホスト構成よりもやや複雑です。2台のホストを維持・管理し、設定を行う必要があるため、より多くのインフラストラクチャが必要となるからです。

Docker でのデュアルホスト構成の Instana のセットアップ方法については、 「インストール:デュアルホスト」 を参照してください。

コンポーネント

完全な停止を防止するため、また、局所的な停止のシナリオでデータを部分的に処理または提供できるようにするため、バックエンドの各コンポーネントは、データ処理全体ではなく、その一部について責任を持ちます。

表 1. コンポーネントの責任
コンポーネント 責任
acceptor メトリックおよびトレース入口。
serverless-acceptor サーバーレス・トレース入口。
appdata-legacy-converter 既存の処理パイプラインを使用した問題検出を可能にします。
appdata-processor トレースから呼び出しを抽出します。
appdata-reader アプリケーション・データを読み取るためのゲートウェイ。
appdata-writer 処理された呼び出しを書き込みます。
butler 公開ログインおよびユーザー設定の管理。
cashier-ingest 使用統計を計算します。
cashier-rollup 使用統計ロールアップを計算します。
eum-acceptor EUM ビーコン入口。
eum-processor EUM 処理。
js-stack-trace-translator EUM の js スタック・トレースをデミニファイします。
filler メトリックとトレースの処理、およびグラフの保守
groundskeeper エージェントの内部アクセス管理。
issue-tracker イベントの生成、管理、および通知。
nginx EUM および UI の中心的な接点。
プロセッサー 問題の認識。
eum-health-processor EUM での問題の認識。
appdata-health-processor アプリケーション・パースペクティブでの問題の認識。
ui-backend UI のバックエンド部分および API プロバイダー。
ui-client ブラウザー内の UI 部分。
表 2. データベースの責任
データベース 責任
cassandra メトリック履歴、スパン、およびプロファイル。
clickhouse 呼び出し、アプリケーション・データ・グラフ、および EUM。
elasticsearch グラフ履歴および EUM。
kafka コンポーネント間通信。
PostgreSQL ユーザー設定ストアおよび履歴使用統計。
zookeeper Kafka および clickHouse の状態管理。

コンポーネントの影響のマトリックス

個々のバックエンド・コンポーネントが使用不可になっても、処理パイプラインが完全に中断されることはありませんが、一部のコンポーネントは、他のコンポーネントより大きい影響を与える場合があります。

表 3. コンポーネント影響マトリックス
コンポーネント ライブ・メトリック ライブ・トレース ライブ EUM ライブ・マップ ライブ・イベント 履歴メトリック 履歴トレース 履歴マップ 履歴イベント 通知 UI ログイン API 使用統計
acceptor X X X X
serverless-acceptor X
appdata-legacy-converter X X
appdata-processor X
appdata-reader X X X
appdata-writer X X X
butler X X
cashier-ingest X
cashier-rollup X
eum-acceptor X
eum-processor X
js-stack-trace-translator X
filler X X X X X
groundskeeper X X X X
issue-tracker X X
nginx X X X X X X X
プロセッサー X X
eum-health-processor X
appdata-health-processor X
ui-backend X X X
ui-client X X

インストール、設定、およびトラブルシューティング