シンガポールでDatadogの代替を検討する:Guanceとの比較と検証手順
シンガポールでDatadogとGuanceを比較。データ配置、収集互換性、調査の流れ、料金、サポートと段階移行を同じ条件で検証します。
シンガポールで Datadog の代替を探す理由は、請求額だけではありません。障害時に必要な情報へたどり着けるか、データの処理場所を説明できるか、今あるアラートを維持して移行できるか。その条件まで含めて初めて、候補の比較ができます。
Guance は、シンガポールの SaaS サイトやプライベート配置を検討したいチームの候補になります。ただし、Datadog の設定や契約をそのまま置き換える製品ではありません。本稿は Datadog と Guance の二製品を、シンガポールで運用するチームの視点で比較します。市場全体のランキングではありません。
発行者は Guance です。2026年10月27日に公式資料を再確認しましたが、両製品の同条件ベンチマーク、顧客契約の検査、以下の30日間の検証は実施していません。公開仕様、編集部の評価方法、実環境で確認すべき事項を分けて記載します。
先に、変更する理由を絞る
| 今の課題 | Guanceを評価する理由 | Datadogを継続する理由 |
|---|---|---|
| データの配置 | AWSまたはAlibaba Cloudのシンガポールサイト、プライベート配置を検討できる | 契約済みサイトとデータ処理条件が要件を満たす |
| 費用 | 実際の信号量をGuanceの計量方式で試算したい | 現行の使用量、契約割引、運用資産を含む総費用が妥当 |
| 収集の自由度 | OpenTelemetryや既存DDTraceを使う接続を検証したい | DatadogにもOpenTelemetryの接続方法があり、変更理由が収集形式だけでは弱い |
| 障害調査 | ログ、トレース、インフラ、RUMを使う流れを比較したい | 既存の調査手順、監視、担当者の習熟が十分に機能している |
| 運用責任 | 専用・プライベート構成の責任を引き受けられる | 自社運用の人員がなく、SaaSの責任分担が適している |
試験で必須のアラートや調査が再現できなければ、導入を見送る判断も正解です。単価だけで、稼働中の監視を交換する必要はありません。
評価の概念図です。移行完了や費用削減を観測した結果ではありません。
比較すべきなのは機能名より、調査の流れ
両社のDatadog製品群とGuance製品には、複数の可観測性領域があります。同じカテゴリがあることと、機能・プラン・操作が等価であることは別です。
- インフラ:ホスト、コンテナ、クラウド資源、ネットワークを、同じ属性と期間で調べられるか。
- APM:サービス、依存先、エラー、遅い処理を探し、必要なプロファイルまで進めるか。対応言語や保持条件も含める。
- ログ:収集、解析、検索、アーカイブと再検索、アクセス制御まで一連の流れを比較する。
- RUM:ブラウザー・モバイルの操作からバックエンドへ関連付けられるか。Session Replayの有無だけでなく、同意、マスキング、保持を確認する。
例えば「リリース後、購入処理の一部だけが遅い」という一つの障害を使います。利用者側の症状から該当サービス、依存先、ログ、変更履歴へ進み、同じ調査担当者が必要な証拠を得られるかを記録します。画面の数や検索結果の多さだけでは判断できません。
AI支援や自動相関も、入力データ、利用者の権限、説明可能性、誤検知、調査担当者の検証を含めて評価します。製品説明の「原因分析」を、その環境で原因が自動確定した証拠として扱わないでください。
収集を標準化しても、バックエンドは同じにならない
DatadogはAgent、OpenTelemetry Collector、DDOT、OTLP取り込みなどのOpenTelemetry経路を提供します。GuanceのDataKitにもOpenTelemetryと、DDTrace、Jaeger、SkyWalking、Zipkinなどのトレース入力があります。
Collectorをアプリとバックエンドの間に置けば、送信経路を整理できる可能性があります。ただし、これは公式の収集機構から組み立てる構成案です。本稿で互換性や無損失を実証した構成ではありません。Collectorの複数のエクスポーターと、従来のDDTraceが自動で二重送信できることも同義ではありません。
小規模な検証では、まず次を照合します。
service、環境、バージョン、region、ホスト・コンテナ属性が維持されるか。- ゲートウェイからサービス、DBまでのコンテキスト伝播と親子スパンが正しいか。
- HTTP route、peer、エラー、ログの時刻とTrace IDが検索・相関に使えるか。
- SDK、Collector、受信側のサンプリングが重なったとき、何が残り何が失われるか。
- キュー、再試行、データ破棄、CPU、メモリ、ネットワーク量を監視できるか。
- 独自の分析、プロファイル、サービスマップなど、必要なバックエンド機能が使えるか。
すでにDDTraceを使うサービスなら、一サービスから始めるGuance接続手順を検証の入口にできます。手順があること自体は、既存機能の完全互換を保証しません。
「AP1」の意味は製品ごとに異なる
Datadogのサイト一覧では AP1は日本、AP2はオーストラリアです。公開一覧にシンガポールサイトがないことは、シンガポールの企業が利用できない、または個別契約の選択肢が一切ないという意味ではありません。
Guanceの商用サイトでは、AP1はAWSシンガポール、AP2はAlibaba Cloudシンガポール、ID1はTencent Cloudジャカルタです。製品間で同じサイトコードを読み替えないでください。Guanceのサイトは独立しており、アカウントやデータが自動共有・移行されるわけでもありません。
サイトの所在地だけでは、バックアップ、災害復旧、サポート資料、サブプロセッサー、越境アクセスまで説明できません。保存・処理・閲覧の経路、暗号鍵、通知、削除、データの持ち出しと契約終了時の扱いを、注文書とデータ処理条件で確認します。本稿はシンガポールの法令適合を認定しません。
シンガポールの無料ワークスペースについても、公開資料から適用を確認できない条件を無条件の特典として約束しません。対象サイト、契約、機能と容量は申込時に確認してください。
BYOCとプライベート配置は、対象範囲から比べる
Datadog BYOC Logsは、ログの処理・保存を顧客側クラウドに置く選択肢です。Datadog側のUIからクエリを送り、結果を返す経路を含みます。これをDatadog全製品のセルフホストと呼ぶのは正確ではありません。
Guanceのプライベート配置を検討する場合も、対象モジュール、バージョン、ライセンス、対応クラウド、容量、使用量報告、アップグレードと障害対応の責任を確認します。「自社環境に置ける」だけでは、必要な機能が全て含まれるとはいえません。
SaaSなら不要だったストレージ、バックアップ、パッチ適用、容量計画、当番の負担も見積もります。運用主体を決められないなら、プライベート配置は比較表の加点項目になりません。
費用は、同じ仕事を同じ期間で測る
金額と計算式の詳細はシンガポール向けDatadog料金ガイドにまとめています。ここでは見積もりに必要な入力を整理します。表示単価や一つのホスト数だけで、月額全体を比較しないでください。
Datadogでは、プランに応じてホスト、コンテナ、カスタムメトリクス、ログ取り込みと索引、APMやインデックス化スパン、セッション、テストなどが関係します。含まれる量、保持期間、サイト、年契約、サポートも照合します。公式料金
Guanceでは、課金明細に信号別の単位があります。計量の規則では、指標は現在データポイント数が基本です。時系列数での計量は、既存契約などの条件を区別します。ログはレコード数または有効化されたトラフィック方式、APMはトレースまたはスパン方式など、実際に有効な計量を確認してください。RUMのPV計量は、PV数と、resource・long task・error・actionの合計件数を100で割った値の大きい方です。Session Replay、Syntheticや保持期間も別に確認します。代替計量が申請・有効化を要する場合、公開単位を見ただけで自由に選択できるとは考えません。
生のログ量が同じでも、イベント分割、索引、サンプリング、保持によって請求対象量は変わります。取り込みから検索可能な証拠までそろえ、サポート、導入、契約最低額、割引、税、移行作業を加えます。通常月だけでなく、2倍・5倍の成長時にも計算をやり直してください。本稿にはGuanceの方が安いと断定する同条件の請求実績はありません。
サポートは、言語と時刻と責任を具体化する
DatadogのサポートプランにはFree、Standard、Premierがあります。初動応答の目標と、障害の解消時間は別の約束です。
Guanceにも公開のサポート区分や応答条件がありますが、それだけでシンガポールの英語対応、現地要員、時間外の当番、担当TAM、移行支援を確約できません。次を契約前に書面で確認します。
- 対応言語、窓口、タイムゾーン、営業日と祝日。
- 重大度別の初動、更新頻度、時間外エスカレーション。
- データへアクセスする担当者と場所、導入・運用の責任分担。
- 既存設定の移行支援範囲、専任担当の有無、終了時の支援。
UIが英語であることと、その時間帯に必要な技術支援が受けられることは別です。
移行対象は、送信先より多い
ダッシュボード、モニター、SLO、権限、ログパイプライン、外部連携、ノートブック、ケース管理、履歴データを棚卸しし、残す・再構築する・廃止する・保留するに分けます。OpenTelemetryは、それらの自動変換形式ではありません。
新しい調査経路を検証する間も、旧Datadogの重要アラートと必要な履歴参照を維持します。機能の不足、権限の不備、取り込み損失、予算超過があれば、候補経路を止められる構成にします。全面移行だけでなく、継続、併用、一部サービスだけの採用も結果として認めてください。
30日で判断材料を集める検証案
これは未実施の計画です。30日で移行が終わるという約束でも、機能が一致したという結果でもありません。
開始前に、責任者と承認者、SDK・Agent・Collector・DataKitの正確なバージョン、信号と量、現在の識別属性、個人情報の扱い、受け入れ閾値、停止条件、証拠の保存先を決めます。公開する記録にAPIキーや顧客データを含めません。
| ケース | 比較する証拠 |
|---|---|
| 遅いSQL | 同一リクエストのDBスパン、アプリログ、依存先の状態 |
| Pod再起動・資源飽和 | 時刻、再起動、CPU/メモリとアプリへの影響 |
| 下流のタイムアウト | コンテキスト伝播、エラー属性、依存関係 |
| フロントエンドのJSエラー | RUMの症状と、条件を満たすバックエンドのトレースとの関連 |
| リリース後の退行 | バージョン、エラー率、遅延、変更時刻 |
| Collector障害と復旧 | 受信・拒否件数、キュー、再試行、データ破棄、復旧後の欠落 |
| 必須アラート | 発火、担当者への通知、エスカレーション、重複 |
| 費用 | 実際の請求対象量、保持、契約条件、運用作業 |
| 候補経路の取り消し | 元の送信・アラートへの復帰と残存データの扱い |
取得した画面だけでなく、クエリ、時刻、件数、欠落する属性やコンテキスト、CPU/メモリ/ネットワークも保存します。結果は「同等性を確認」「許容できる差」「採用を妨げる差」「不明」「未試験」に分けます。
- 1~5日目:現行の調査・費用・契約と要件を固定する。
- 6~12日目:代表サービスの限定した信号で収集経路を比較する。
- 13~20日目:同じ担当者が同じ障害課題を調べる。
- 21~26日目:権限、運用、サポート、請求対象量を照合する。
- 27~30日目:復帰手順を確認し、継続・併用・一部採用・延長・中止を決める。
公開資料だけでは決まらないこと
機能やクエリの同等性、実負荷の性能、カーディナリティ、履歴の移行、地域ごとの全モジュール、保存とアーカイブ、AI機能、セキュリティ、サポート、退出条件は、対象環境と契約で確かめる必要があります。これらは一律に「資料不足」として消すべき話題ではありません。製品文書で確定する仕様と、自分たちの条件でしか確定しない結果を分けて、未確認事項に担当者を置いてください。