コンテンツにスキップ

よくある質問


プラン選択と決済方法

セッションリプレイは、ログのように保存期間を個別に 3 日間や 7 日間に設定できますか?

お使いのプランによって異なります:

  • 商用プラン:対応していません。セッションリプレイのデータ保持ポリシーはリアルユーザーモニタリング(RUM)に紐づいており、RUM の保持ポリシー(3 日間/7 日間/14 日間)が一律で適用されるため、個別に調整できません。
  • デプロイメントプラン:管理コンソールでセッションリプレイの保持ポリシーを個別に設定できます。
注意

セッションリプレイのファイルは通常サイズが大きいため、保存期間を延長するとストレージコストが大幅に増加します。実際の調査ニーズに応じて適切に設定することをおすすめします。


ビジネスの中心は中国リージョンですが、一部のユーザーは海外にいます。決済時には人民元と米ドルのどちらを選択すべきですか?

Guanceには、2 つの決済センターシステムがあります:

リージョン 対応通貨 ユースケース
中国リージョン 人民元(CNY) 中国国内のビジネス。請求書は増値税の普通/専用請求書が必要
中国香港・グローバルリージョン 米ドル(USD) 海外ビジネス。米ドル決済が必要、または為替変動リスクを回避したい場合

通貨の選択は請求書の種類と支払い方法に影響するため、ワークスペースの登録時に決定する必要があります。ビジネスが複数のリージョンにまたがる場合は、リージョンごとにワークスペースを作成し、それぞれ現地通貨で決済することをおすすめします。


人民元での決済をしばらく利用していますが、米ドル決済に切り替えられますか?

セルフサービスでの直接切替はできません。異なる決済センターシステム(中国リージョン vs グローバルリージョン)とアカウント移行が関係するため、次の対応が必要です:

  1. アカウントマネージャーに連絡し、通貨切替の申請を提出する
  2. 元のワークスペースの過去の請求は人民元決済のまま維持される
  3. 切り替え後に発生した新しい費用は米ドルで決済される

切り替え前に人民元アカウントの未払い額を清算し、為替変動が予算に与える影響を評価することをおすすめします。


ログ量は非常に多いもののアクセス頻度は低いです。商用プランとエンタープライズプランではどちらがお得ですか?

これは「書き込みトラフィック」と「ストレージ総量」の比率によって異なります:

  • 商用プラン:書き込み量(件数またはトラフィック)+保存期間に応じた段階的課金です。データへのアクセス頻度が高く、長期保存と頻繁な検索が必要なユースケースに適しています。短期保存(3〜7 日間)のみの場合は、通常は商用プランの方が経済的です。

  • エンタープライズプラン:圧縮後の書き込みトラフィック+ストレージ総量で課金され、保存期間には依存しません。ログ量が極めて多いが検索頻度が低く、長期アーカイブが必要なユースケースに適しています。360 日間保存しても単価が期間に応じて段階的に上がることはありませんが、ストレージ総量に対して継続的に支払う必要があります。

データの圧縮率が高い(テキストログは 20% まで圧縮可能など)場合や、保存期間が 30 日間の場合は、アカウントマネージャーに連絡してエンタープライズプランの評価を依頼することをおすすめします。


データ保持ポリシーの変更

ログの保存期間を 14 日間から 3 日間に短縮したのに、請求額がすぐに下がらないのはなぜですか?

これはローリング課金メカニズムによるものです。非メトリクスデータ(ログ、Trace など)でポリシーを変更した場合:

  1. 履歴データ:元の保存期間(14 日間)に達するまで保持され、元のポリシーの高い単価で課金されます
  2. 新規データ:直ちに新しいポリシーの低い単価で課金されます

そのため、費用が下がるまで 14 日間の移行期間があります。すぐにコストを下げる必要がある場合は、履歴データを手動で削除する必要があります(ただし、データは失われます)。

メトリクスデータの保持ポリシーを変更すると、古いデータは直ちに削除され、費用もすぐに下がりますが、データは復元できません。


同じ日に保存ポリシーを複数回変更した場合、どれが有効になりますか?

当日の最初の変更は直ちに有効になり、その後の変更は翌日に有効になります。

シナリオ例:

  • 09:00:ログを 14 日間から 7 日間に変更 → 直ちに有効になり、当日から 7 日間の単価で課金
  • 15:00:さらにログを 7 日間から 3 日間に変更 → 翌日 0 時に有効になり、今日は引き続き 7 日間で課金

課金記録が複雑になるのを避けるため、1 日以内に複数回変更しないことをおすすめします。


データ保持ポリシーを変更した後、メトリクスデータと非メトリクスデータの扱いが異なるのはなぜですか?

  • メトリクスデータ:変更後すぐに有効になり、古いデータは直ちに削除され、復元できません。メトリクスデータは量が多く更新頻度が高いため、システムは即時クリーンアップポリシーを採用しています。

  • 非メトリクスデータ(ログ、Trace、プロファイル、RUM など):変更後、新規データは新しいポリシーで課金され、古いデータは元の保存期間の終了まで保持されます。非メトリクスデータは通常、監査価値があり、データの継続性を保証する必要があるためです。

メトリクスの保存期間を短縮すると即座にコストを削減できますが、非メトリクスの保存期間を短縮した場合は、移行期間が終わって初めて完全なコスト削減効果が見られます。


「カスタム複数インデックス」を有効にした後、保存ポリシーの変更は「デフォルト」インデックスしかできないのはなぜですか。他のインデックスはどうすればよいですか?

各インデックスは個別に保持ポリシーに紐づいています。変更手順:

  1. ログ > インデックス管理 に移動します
  2. 各カスタムインデックスにそれぞれ保存期間を設定します
  3. 各インデックスはそれぞれの期間ポリシーに基づいて課金されます

カスタムインデックスに個別のポリシーを設定していない場合、default インデックスのポリシーが継承されます。ただし、課金時は各インデックスが独立して集計され、合算されることはありません。


課金項目と計算ロジック

商用プランで、ログの件数課金と書き込みトラフィック課金は、どのような場合に切り替えると有利ですか?

鍵となるのは、ログ 1 件あたりの平均サイズです:

  • 1 件あたり 1KB 未満:件数課金の方が通常は有利です(1GB あたり約 100 万件で、件数課金なら 1 単位で済む可能性があります)
  • 1 件あたり 10KB(ES)超または 2KB(SLS)超:トラフィック課金の方が有利です。大きなログが複数件に分割されて課金されるのを防げます
注意

切り替えにはアカウントマネージャーへの連絡が必要で、切り替え後も履歴データは元の方式で決済されます。まずログエクスプローラーで 1 件あたりの平均サイズ(総トラフィック/総件数)を確認してから判断することをおすすめします。


モニターの検出間隔を 30 分に設定した場合、トリガーは 2 回(30/15)ですか、それとも 6 回(基本 5 回 + 超過 1 回)ですか?

後者が正しいです。課金式は次のとおりです:

総回数 = 検出タイプの基本回数 + ⌈(検出間隔 - 15 分) / 15 分⌉

「急変検知」(基本 5 回)の場合、30 分間隔では:

  • 基本:5 回
  • 超過分:(30-15)/15 = 1、切り上げて 1 回
  • 合計:6 回
注意

単純な「間隔 / 15」ではなく、15 分を超えた部分のみを 15 分単位で課金します。


AI モニターが 1 回検出を実行すると、どのような使用量が発生しますか?

AI モニターは検出を 1 回実行するたびに、次の 2 種類の使用量が同時に発生し、それぞれ別々に集計されます:

  • トリガー:トリガー 1 回としてカウントされます
  • AI クレジット:今回の検出で実際に消費した Credits が差し引かれます

詳細設定の「1 回の検出あたりのクレジット予算」は、1 回の検出で消費するクレジットを制御するためのもので、毎回この額が固定で差し引かれることを意味するものではありません。


インテリジェントモニタリングのタイプごとに、トリガーはどのように計算されますか?

タイプごとに次のルールで集計されます:

  • ホスト/ログ/アプリケーションのインテリジェント検出:実行あたり 10 回
  • ユーザーアクセスのインテリジェント検出:実行あたり 100 回
  • AI インテリジェントモニタリング:実行あたり 100 回

AI インテリジェントモニタリングは検出を実行するたびに、今回の AI 分析で実際に消費した Credits も差し引かれます。トリガーと Credits はそれぞれ別に集計されます。


トレースデータは Trace 単位で課金されることもあれば、Span 単位で課金されることもあります。請求額を予測するにはどうすればよいですか?

システムが自動的に有利な方を選択します:

  • Trace 数 ≥ Span 数/10 の場合、Trace 単位で課金されます(100 万 Trace ごと)
  • それ以外の場合は Span 単位で課金されます(1,000 万 Span ごと)

アプリケーションパフォーマンスモニタリング(APM)のサービス概要で確認できます。平均して 1 つの Trace に含まれる Span 数が 10 を超える場合は Span 単位で課金される可能性が高く、10 未満の場合は Trace 単位で課金されます。サンプリングポリシーを調整して Trace 数を制御することで、課金方式に影響を与えることができます。


エスカレーションポリシーの通知がトリガーされるたびにトリガー 100 回分が差し引かれるのは、通知を送信するたびにですか?

はい。エスカレーションポリシーに 1 回ヒットするたびに、通知送信時にトリガー 100 回分として記録されます。

注意
  • 課金されるのは「通知の送信時」のみです。エスカレーションポリシーで通知を設定していても実際に送信されなかった場合(通知先の設定ミスなど)は、課金されない可能性があります
  • 同じイベントがエスカレーションポリシーを複数回トリガーした場合(障害が継続的にエスカレーションする場合など)、エスカレーションのたびに 100 回分が差し引かれます
  • エスカレーションポリシーとモニター検出は独立した課金項目です。モニター検出で既に課金されていても、エスカレーションポリシーの通知では追加で課金されます

商用プランで、イベントと自前の Synthetic テストデータが、デフォルトでログの default インデックスの保持ポリシーを使用するのはなぜですか?

これらの 2 種類のデータは物理的にログの default インデックスに保存されるためです:

  • イベントデータ(モニター、SLO、インテリジェントインスペクションで生成)は default インデックスに保存されます
  • 自前の Synthetic テストデータは DataKit 経由で送信され、同じく default インデックスに保存されます

そのため、これらの保存期間と課金単価は default インデックスの設定を継承します。個別に調整したい場合、現時点ではイベントや自前の Synthetic テスト用に独立した保持ポリシーを直接設定することはできず、default インデックスの保存期間を調整することで間接的に影響を与えることしかできません。

例外:Guanceノードの Synthetic テストデータも default インデックスに保存されますが、テストの実行自体はテスト回数に基づいて別途課金され、ストレージ課金とは別の次元です。


データ分割と圧縮課金

超大ログの分割しきい値は ES と SLS ストレージで異なります。実際の件数はどのように計算されますか?

ストレージタイプに応じてそれぞれ計算します:

ES ストレージ:

  • 1 件あたり 10 KB 以下:1 件として計上
  • 1 件あたり 10 KB 超:課金件数 = ⌈実際のサイズ/10 KB⌉

例:15 KB のログは 2 件、25 KB は 3 件として計上されます

SLS ストレージ:

  • 1 件あたり 2 KB 以下:1 件として計上
  • 1 件あたり 2 KB 超:課金件数 = ⌈実際のサイズ/2 KB⌉

例:3 KB のログは 2 件、5 KB は 3 件として計上されます

注意

SLS の分割しきい値はより低く(2KB vs 10KB)、同じログでも SLS ではより多くの件数に分割されて課金される可能性があります。ただし、SLS 自体の圧縮率は高いため、総コストを総合的に評価する必要があります。


セッションリプレイのセッションが 5 時間継続し、2 つの課金単位に分割されました。この 2 つの単位は連続して課金されるのですか、それとも実際のアクティブ時間に応じて割り当てられるのですか?

切り上げによる整数倍で課金され、時間の分布には関係ありません:

課金単位 = ⌈time_spent / 4 時間⌉ = ⌈5/4⌉ = 2 単位

この 2 単位は当日の請求に一括で計上され、時間単位で分割して課金されるわけではありません。セッションの途中に 1 時間の非アクティブ時間があっても、time_spent フィールドが合計 5 時間を示している限り、2 単位で課金されます。


プロファイルファイルが 300KB を超えて分割される場合、分割後の件数で個別に保存されるのですか、それとも課金時のみ分割されるのですか?

課金時のみ分割され、ストレージは元のファイルのままです。システムは大きなプロファイルファイルを複数のレコードに分割してインデックス作成と課金を行います(300KB ごとに 1 件)が、ストレージ上では 1 回のプロファイル収集として紐づけられたままです。これは、1 件のレコードが大きすぎてクエリパフォーマンスに影響するのを防ぎつつ、課金がストレージリソースの消費に比例するようにするためです。


PV 課金の「PV と PV/100 の大きい方を採用」とはどういう意味ですか?

これは低トラフィックシナリオ向けの下限保証付き課金メカニズムです:

  • 当日の PV 数が 500 の場合、500/100=5 となり、大きい方の 500 を採用して 500 で課金されます
  • 当日の PV 数が 50 の場合、50/100=0.5 となり、大きい方の 50 を採用して 50 で課金されます(0.5 や 1 ではありません)

PV 数が 100 を超えた場合のみ「PV/100」が 1 より大きくなるため、その場合は PV 数自体を採用します。このルールは主に超小流量時の計算精度の問題を避けるためのもので、通常の業務トラフィック(1 日あたり 100 PV 超)には実質的な影響はありません。


機密データスキャンで、同じログの複数のフィールドをマスキングすると、なぜ複数回の費用が発生するのですか?

課金がフィールドレベルのスキャントラフィックに基づくためです:

  • マスキングが必要な各フィールドの元のトラフィックが個別に計算されます
  • これらのフィールドが同じログに属していても、それぞれ別々に課金されます

例:1KB のログに 3 つの機密フィールドが含まれる場合、スキャン課金は 3 つのフィールドの元のトラフィックの合計(フィールドの内容サイズによっては 1KB を超える可能性があります)で計算され、ログ 1 件分の 1KB では計算されません。


プラン切り替えとデータ移行


無料プラン サービス終了のお知らせ

無料プランは 2026 年 9 月 2 日にサービスを終了する予定です。サービス終了までに商用プランへアップグレードするか、データエクスポート機能を使用して保持したい重要なデータを保存してください。

無料プランから商用プランにアップグレードした後、無料期間中のデータが見えないのはなぜですか?

無料プランのデータは独立したインスタンスに保存されています。アップグレード後:

  • DataKit 設定:自動的に商用プランのワークスペースを参照するようになり、データは引き続き送信されます
  • 履歴データ:無料プランの環境に保持され、通常 7 日後に自動的に削除されるため、商用プランでは確認できません

無料プランの履歴データは商用プランに移行できません。保持する必要がある場合は、アップグレード前にデータエクスポート機能でバックアップしてください。


フィードバック

このページは役に立ちましたか?