中国で運用するチームのDatadog代替：八つの選択肢と評価方法

Datadog を置き換える作業は、テレメトリの送信先変更だけでは終わりません。公開されている製品群にはインフラ監視、APM、ログ、RUM、アラート、セキュリティがあり、それらを使うチームには既存のダッシュボード、権限、監視ルール、履歴があります。その移行作業も選択に含める必要があります。

中国本土でサービスを運用するチームでは、調達、接続品質、現地サポート、クラウドとデータセンターをまたぐデータ経路も重要です。本稿はその条件で八つの選択肢を比較します。発行者の Guance も候補の一つであり、公式資料に基づく検討であって、第三者ランキングや本番規模の実測比較ではありません。日本語版であっても、対象は中国での運用を含むチームです。他地域での提供条件を保証するものではありません。

制約から候補を絞る

候補を試すために、先に Datadog を廃止する必要はありません。代表的なサービス、管理された収集経路、元に戻す方法を用意します。二〜四週間は最初の評価期間の例で、移行完了を保証する期間ではありません。Guance の無料版を使う場合も、現在の上限、機能、保持期間を確認して範囲を決めます。

判断が変わる四つの要因

費用は単価よりワークロードで決まる

ログ、索引化イベント、トレースの取り込みと保持、カスタムメトリクス、RUM、Profiling、安全関連データ、ユーザーライセンスには異なる計量が使われます。すべての製品がすべての単位で課金するわけではなく、契約にはコミット量や超過条件もあります。

サービスやテナントの増加は時系列数を増やし、リクエストの詳細を多く残せばログとトレース量も増えます。障害時の文脈を残したいエンジニアと、支出を予測したい担当者が同じ前提で話せるように、トラフィック、信号、サンプリング、保持期間を揃えます。二重運用と通信も費用に含めます。収集量を減らした結果、必要な証拠までなくなるなら、単純な改善とはいえません。

中国での導入は機能表だけでは判断できない

購入、請求書、支払、安全審査、接続性能、対応言語、事故時の連絡先は、実際の利用可否を左右します。本社所在地や翻訳されたサイトから、個別の契約条件は推測できません。

どこでデータを収集・処理・保存・バックアップするか、どのネットワークを通るか、どこまでサポートされるかを確認します。地域名の付いた endpoint は、すべてのデータ取扱条件を証明しません。必要な機能があっても、配備方式やサポート契約の調整が必要な場合があります。

マルチクラウドでは識別子がつながる必要がある

一つのリクエストがブラウザー、ゲートウェイ、アプリケーション、キュー、データベースを通り、複数クラウドや IDC を横断することがあります。クラウド事業者のツールも外部データを受け取れますが、収集だけでは不十分です。サービス名、時刻、trace context、ネットワーク、クエリ権限を揃えて初めて経路を追えます。

その実際の調査手順を評価に使います。同じ画面に表示できても、必要な信号が揃っているか、別名のサービスが同じ対象を示すかは確認が必要です。

AI 支援はツール接続から先を検証する

MCP、CLI、API は Agent がツールを呼び出す手段です。それだけで信頼できる事故対応プロセスにはなりません。時間範囲の選び方、証拠の引用、欠損の扱い、権限、承認要求を確認し、説明の候補と確定原因を区別します。

まず読み取り専用で試します。変更を伴う操作には、範囲、監査記録、復旧手順が必要です。承認画面があることは危険な動作がすべて検出される証拠ではなく、タスク停止は実行済み操作の取り消しではありません。結果の判断は運用者に残ります。

同じ基準で比べる

1. Guance：中国と複数環境での運用を評価する

現地の導入・サポート、複数のインフラ環境、信号を横断する調査が主な要件なら、Guance は検討候補になります。公開製品資料にはログ、メトリクス、トレース、RUM、インフラ、Kubernetes、アラート、イベントが含まれます。Datadog の全項目をそのまま複製した製品ではありません。必要な連携と識別子を確認して、調査が成立するか判断します。

中国語の文書やサポート窓口、配備の選択肢は評価対象ですが、すべての契約を保証したり、料金が必ず下がることを示したりはしません。実際のデータで権限、フィールド、クエリ、費用を確かめます。

OWL CLI、MCP Server、OpenAPI を使うと、Codex、Claude Code、OpenClaw、社内 Agent から対応する Guance のデータと機能を利用できます。この場合、調査方法、権限、復旧はチームが設計します。Obsy AI の資料は Copilot の支援と Agent Teams の継続タスクを区別しています。Teams では Agent の役割、Skill、MCP サービス、Channel を構成でき、タスク資料で成果物、承認要求、停止の扱いを確認できます。

ログでは checkout-service、トレースでは checkout-api、手順書では「決済」と呼ぶサービスには、どちらの方法でも検証できる対応付けが必要です。収集されなかったログや登録されていない担当者を、製品が補完できるわけではありません。AI サービスの説明も出力のレビューを求めており、解決や正答率を保証していません。

Datadog 固有の連携やモジュールへの依存が大きければ、一つずつ試験します。今の構成が要件を満たし、移行作業が効果を上回るなら、継続も合理的です。Guance は運用条件が合う場合の候補であり、結論は試用結果から出します。

2. Grafana LGTM / Prometheus：基盤の選択権を残す

Prometheus と Grafana を維持する能力があり、その投資を活かしたいチームに適します。Prometheus はメトリクス、Loki はログ、Tempo はトレース、Mimir は拡張可能なメトリクス保存を扱います。Thanos は Prometheus ベースの構成を拡張する別プロジェクトです。Grafana は設定されたデータソースのクエリと可視化を担います。

自社運用では配備と拡張の自由を持つ一方、収集、高カーディナリティ、アクセス、保存、更新、バックアップ、復旧も担当します。RUM、イベント、通知、信号間の関連には適切な構成が必要です。Grafana Cloud は運用分担が異なるため、自社運用と同じ保守項目をそのまま適用しません。

可観測基盤の運用を、担当者と時間のある継続的な仕事として選ぶ場合に向きます。ライセンス費だけで総費用の低さは証明できません。

3. Elastic Observability / ELK：検索要件から検討する

Elasticsearch の経験と本格的なログ検索が必要なら有力な検討対象です。ELK のログ構成と、APM、メトリクス、デジタル体験まで扱う Elastic Observability を区別します。安全分析は Elastic Security と該当エディション・ライセンスで確認し、すべての構成に含まれるとは考えません。

自社運用では mapping、シャード、ストレージ階層、拡張、更新、復旧を計画します。Elastic Cloud Hosted と Serverless では責任の分担が異なります。ログしか収集していない構成に調査の空白があっても、それを製品全体の制限とは扱わず、設定した複数信号の経路を試します。実際の全文検索、履歴クエリ、障害調査で費用と性能を確認してください。

4. New Relic：別の国際 SaaS を比べる

New Relic は APM、ブラウザー監視、ログ、インフラなどを提供します。必要な機能と国際 SaaS の調達形態が組織に合う場合の候補です。

中国の運用では、ネットワーク、サポート、購買、データ取扱条件を再確認します。SaaS の銘柄を変えるだけでは、この制約はなくなりません。同じワークロードで連携と課金方式を比較し、適用されるユーザーや計算の単位も含めます。元の障害が調達や配備地域なら、その条件が実際に変わるかが重要です。

5. Dynatrace：複雑なシステムの検出と管理を評価する

自動検出、サービストポロジー、企業内の管理要件が重要な場合に検討します。対応技術、計装、配備で見える範囲が変わるため、実際のアプリケーション群を使います。トポロジー図や AI の説明だけで、原因が確定したとは考えません。

選択する製品、利用量、配備、導入作業から費用を見積もります。企業向けという位置付けだけで高いとも安いとも決められません。中国での提供、接続、サポートも個別に確認します。単に価格表の候補を増やすのではなく、実際の複雑さを扱えるかが評価軸です。

6. Alibaba Cloud SLS / ARMS：クラウドの運用経路に合わせる

Alibaba Cloud のリソースが中心なら、既存の収集・購買経路に合う可能性があります。ログ、アプリケーション監視、リソース監視の境界は別々に評価します。

SLS は他クラウドや IDC のログも収集できます。Alibaba 内だけという説明は不正確です。ただし、ネットワーク、権限、外向き通信費、共通フィールドは必要です。SLS と ARMS が同じ事業者の製品であっても、必要な調査経路が自動で成立するわけではありません。複数環境では、他候補と同じ障害調査を実施します。

7. Tencent Cloud の可観測性サービス / CLS / TMP：組み合わせを確認する

Tencent Cloud の監視、CLS、マネージド Prometheus は、同クラウドに多くの資産と購入経路があるチームの候補です。どの製品を組み合わせれば、メトリクス、ログ、依存関係、アラートを必要な範囲まで扱えるかを確認します。

CLS LogListener は他クラウドと自社 IDC にも対応します。外部収集が可能でも、識別子、トレースの関係、ネットワーク、費用は検証が必要です。「クラウド中立」を曖昧な点数にせず、実際の環境間を調査できるかで判断します。

8. SigNoz / OpenObserve：名称ではなく配備形態を選ぶ

SigNoz と OpenObserve は自社運用とホスト型の経路を提供します。配備の選択権、公開コード、必要な機能が要件に合うなら比較できます。機能がすべての配布形態に含まれるとは限らないため、ライセンスとエディションを確認します。

自社運用には更新、安全性、権限、容量、バックアップ、通知管理が残ります。ホスト型では一部の責任が変わります。企業向け機能、連携、サポートは選ぶ版で確認してください。「オープンソース」や小規模な初期構成だけで、長期運用が軽く安くなるとはいえません。

PoC を実際の判断につなげる

最初に隔離環境で収集、権限、停止手順を確認し、代表的な非重要サービスや承認済みのマスキングデータへ進みます。簡単なデモは接続を確認できても、本番の機能、費用、性能を証明しません。

1. 有用なリクエスト経路を選ぶ。 該当するフロントエンド、API、データベースやミドルウェア、Kubernetes、エラーログを含めます。
2. 既存システムを維持する。 並行送信の対応、キュー、再試行、負荷、重複、料金を確認します。追加送信先が無害とは仮定しません。
3. 過去の障害を振り返る。 仮説の形成と検証に必要なシステムと人、信号の欠損、通知の差異を記録します。
4. 同じ範囲で費用を計算する。 ログ、メトリクス、トレース、RUM、保持、ユーザー、AI、サポート、二重運用を適用単位で見積もります。
5. Agent の境界を検証する。 隔離環境で引用、権限、承認、監査、失敗した操作、復旧、人の訂正を確認します。機能説明だけで運用の成立とはしません。
6. 当番担当者に使ってもらう。 調査が分かりやすく再現できるかを確認し、購入比較表だけで決めません。

範囲を広げる前に、合格・停止条件、旧収集設定と通知設定、履歴アクセス、復旧確認者を記録します。履歴や全画面の移動を最初に行う必要はなく、試用中に使わなかっただけで復旧・監査用の監視を消してはいけません。

中国での配備、開発者の経験、検索、単一クラウド、複雑な管理といった実際の制約から候補を選びます。Guance の小規模な並行収集では調査画面を、別途 Obsy Agent Teams の評価では許可したタスクとレビューを確かめます。どちらかが成功しても、Datadog 全機能の置き換えが完了した証拠ではありません。

参考資料

技術資料の確認日：2026 年 10 月 27 日。文書に基づく比較で、本番の性能試験、地域別の法的評価、移行演習は実施していません。

• Datadog の製品と料金
• Prometheus・Grafana Cloud
• Elastic Observability・OpenTelemetry
• SLS の収集・CLS の収集（中国語）
• Guance 製品概要・Agent Teams のタスク
• SigNoz・OpenObserve