よくある質問
環境外に送信されるデータは何ですか？
metric_log、asynchronous_metric_log、tables、warnings、server_settings) の結果、ヘルスおよびステータスのハートビート、インスタンスとバックアップの状態、コネクタ自身のメトリクスを送信します。デフォルトのスクレイプセットでは意図的に system.query_log を除外しているため、明示的に追加しない限り、生のSQLテキストやそこに含まれるリテラル、個人データがスクレイプパス経由で送信されることはありません。セッション中は、デフォルトのテーブル許可リストに、実行中のクエリテキストを表示する system.processes が含まれます。これを非表示にする必要がある場合は、許可リストから削除してください。
アクティブなサポートセッション中、トラブルシューターは追加でコマンド出力を返送します。返送対象は、許可リストに含まれるClickHouseテーブルと、ポッドログを含む読み取り専用のKubernetesビューに限定されます。また、送信前に編集処理が行われます (IPアドレス、認証情報、トークン、秘密鍵向けの組み込みパターンに加え、独自のパターンも使用できます) 。テーブルデータ、バックアップ、クエリ履歴 (system.query_log、system.text_log) が環境外に送信されることはありません。ただし、許可リストに含まれるメトリクス履歴テーブル (system.metric_log、system.asynchronous_metric_log) の行はすべてのスクレイプで送信され、実行中のクエリテキストは許可リストから削除しない限り system.processes を通じてセッション中に確認でき、Kubernetesサポートセッション中に読み取られたポッドログは編集処理後に送信されます。アウトバウンド接続の完全な一覧は、権限モデルページにあります。
ClickHouse のアクセスを取り消すにはどうすればよいですか？
- 対話型アクセスを終了します。 VM ホストで
sudo clicklink clctl troubleshoot session disableを実行してセッションを無効にするか、Kubernetes ではポートフォワード経由で--gateway-urlを指定して同じコマンドを実行します (正確なコマンドについてはサポートセッションページを参照) 。アクティブなセッションがない場合、トラブルシューターは接続中であってもすべてのコマンドを拒否します。 - 今後のセッションを防止します。 オペレーターの許可リストを空にする (許可リストを空にするとゲートウェイが閉じます) か、ゲートウェイを無効にします。VM では、ホスト上の root は引き続きローカルセッション管理を利用できます。設定ガイドを参照してください。
- ClickHouse Cloud との接続を遮断します。 ネットワーク層でコネクタエンドポイントへの送信トラフィックをブロックするか、強制適用される CNI で
networkPolicy.allowEgressCIDRsを空にします。コネクタは送信専用のため、ClickHouse Cloud には接続を復旧するための受信経路がありません。ワークロードを停止またはアンインストールするまで、ClickHouse に対するローカル読み取りは継続します。これが完全な停止です。 - 認証情報を取り消します。
pcm_scraperとpcm_troubleshooterの ClickHouse ユーザーを削除し、コネクタの Secret (Kubernetes) または/etc/clicklink配下のファイル (VM) を削除します。 - コネクタを完全に削除します。 操作を参照してください。
エアギャップ環境や独自のミラー経由で実行できますか？
releases.clicklink.clickhouse.com とパブリックregistryからCLI tarballおよびコンテナーイメージをミラーリングし、image.repository にミラーを指定して、oci:// 参照、URL、またはローカルアーカイブとともに --chart を指定します (--chart-version も指定します。デフォルトはCLI自体のバージョンです) 。コネクタのAPI エンドポイントがネットワーク境界内でprivate CAの背後に配置されている場合は、--api-private-ca (Kubernetes) または api.tls.ca_file (VM) により、オンボーディングバンドルのchainを使用して検証できます。直接接続せずにオンボーディングする場合、init --handoff は帯域外で取得したbundleを使用します。また、--no-auto-sign と init --signed-cert により、証明書署名を帯域外で完了できます。private mirrors およびonboardingのエアギャップセクションを参照してください。コネクタは実行時にも組織のコネクタAPI エンドポイントへの経路を必要とします。経路がない場合、ClickHouse Cloudはテレメトリーを受信しません。
コネクタが停止した場合はどうなりますか？
/var/lib/clicklink/buffer にスプールし (デフォルトで最大 168 時間または 1024 MB) 、再接続時に送信します。そのため、エンドポイントの停止によってテレメトリーが失われることはありません。デーモンがクラッシュした場合は systemd によって再起動され、Kubernetes ではキューブレットによって再起動されます。診断するには、各コンポーネントの /livez エンドポイントを確認し (HTTP コードではなく JSON の status フィールドを確認します) 、clicklink clctl preflight を実行します (VM ホストでは sudo を使用します) 。これにより、設定、接続性、ClickHouse への到達可能性、アクセス、ディスクを一度に確認できます。操作を参照してください。コネクタが不健全な状態のままである場合は、ClickHouse Support にお問い合わせください。
サポートセッションはどのように監査されますか？
/var/log/clicklink/troubleshoot-audit.logの監査ログに追記されます。ゲートウェイ呼び出しにはトークンによって証明されたオペレーターのメールアドレス (自己申告の名前は使用されません) が記録され、VM上のローカルセッションの変更には実行元のホストユーザーが記録され、セッション中に実行されたコマンドには認証済みチャネルの組織アイデンティティが記録されます。セッションには時間制限があり (デフォルトでは4時間、最長24時間) 、有効化のたびに、有効化したユーザー、有効期限、任意の理由が記録されます。これらはclicklink clctl troubleshoot session statusで表示できます。
ログはclicklink clctl troubleshoot audit tailで閲覧します。Kubernetesでは、このコマンドがサポートされているreaderです (runtimeイメージにはシェルがありません) 。デフォルトのpersistence.enabled: trueでは、ログはtroubleshooterの永続volumeに保存されるため、ポッドの再スケジュール後も監査履歴が維持されます。永続化を無効にすると、監査ログとセッション状態はポッドの存続期間に限定され、chart自体でもローカル開発専用として扱われます。rotationでは、デフォルトで最大128 MBのファイルを5つ、168時間保持します。調整方法については設定リファレンスを、信頼モデルの詳細についてはサポートセッションを参照してください。