2026.10.13 Google Cloud

Ops Agentとは？Google CloudのVMにログ・指標収集を入れる手順とconfig.yaml設定、旧エージェント移行を実装者目線で解説

Ops Agentは、Compute EngineのVMからログとメトリクス（指標）、トレースを集めてCloud LoggingとCloud Monitoringへ送る、Google Cloud公式の収集エージェントです。従来の旧Loggingエージェントと旧Monitoringエージェントは2026年9月28日にサポートが終わり、VMの監視はOps Agentへの一本化が前提になりました。この記事では、内部構成と対象範囲、インストール、config.yamlでの独自ログ追加とノイズ除外、旧エージェントからの移行、料金の勘所までを、動かせるコマンド付きで整理します（版番号と料金は2026年10月時点）。

まとめ：Ops Agentの正体と旧エージェントからの移行判断の物差し

Ops Agentの中身は、ログ担当のFluent Bitと、指標・トレース担当のOpenTelemetry Collectorを1つのパッケージに束ねたものです。入れるだけでsyslogとCPU・メモリ・ディスクなどのホスト指標が送られ、独自のログファイルやミドルウェアの指標はYAMLを数行足せば増やせます。

旧エージェントが残っているVMは移行が待ったなしです。旧エージェントを外し、Ops Agentを入れ、ダッシュボードとアラートの参照先を直す、という順で進めれば事故は起きにくくなります。

費用は送ったデータ量で決まります。入れる前に「何を取り込まないか」を決めておくのが、最初に効くコスト対策です。

Ops Agentとは：ログとメトリクスを1本で集めるGCE専用エージェント

Google CloudのOps Agentの公式概要は、Ops AgentをCompute Engineインスタンスからテレメトリを集める「主要なエージェント」と位置づけています。集めたログはCloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いで解説したログバケットへ、指標はCloud Monitoringへ入ります。導入先となるVMの基本はCompute Engineとは？GCPの仮想マシンの仕組み・料金とgcloudでのVM作成手順を参照してください。

Fluent BitとOpenTelemetry Collectorの2エンジン構成

Ops Agentは自前の収集エンジンを持たず、OSSを2つ組み合わせています。ログはFluent Bit、指標とトレースはOpenTelemetry Collectorが受け持ちます。旧Loggingエージェントの基盤だったFluentdより軽量なFluent Bitへ切り替えたことで、高スループットのログ収集に対応しました。

2つのエンジンは、それぞれ別のプロセスとして動く構成です。エンジン単体の設定思想はFluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例とOpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違いにまとめています。Ops Agentではそれらを直接書かず、独自のYAML形式で書いた設定がエンジン用の設定へ変換されます。

GitHubのリリース一覧では、2026年10月5日公開の2.72.0が最新です。この版で対応パイプラインのOTel Loggingが既定で有効になり、同梱のOpenTelemetry Collectorはv0.162.0に上がっています。

対応OSと既定の収集対象：syslog・イベントログ・hostmetrics

対応OSはRocky Linux、RHEL、CentOS Stream、Debian、Ubuntu、SLESの各版と、Windows Server 2016〜2025です。ArmのVM（C4A、Tau T2A）も一部のOSイメージで動きます。設定を1行も書かなくても、次のデータは自動で送られます。

OS	既定のログ	既定の指標
Linux	syslog（messages・syslog）	hostmetrics（60秒間隔）
Windows	システム・アプリケーション・セキュリティ	ホスト指標・IIS・SQL Server

Windowsの既定ログは、表の順にSystem、Application、Securityです。ホスト指標のhostmetricsにはCPU、ディスク、メモリ、ネットワーク、プロセスが含まれます。ApacheやMySQL、PostgreSQL、Redis、nginxなどはサードパーティ統合として用意されており、設定で有効にすればサンプルのダッシュボードとアラートポリシーも使えます。

対象外になる環境：EC2・オンプレミスと既存Fluentd資産の扱い

公式概要は、Amazon EC2インスタンスとオンプレミスのマシンをサポート対象外と明記しています。AWSや自社データセンターのサーバーからCloud Loggingへ送るなら、Google-Built OpenTelemetry Collectorか素のFluentdを使う構成です。

もう1つの例外がDataflowです。Dataflowのワーカーには、サービス専用の設定を持つ旧Monitoringエージェントが事前に組み込まれています。利用者が入れたものではないので、移行作業の対象から外して扱います。

旧Loggingエージェント・旧Monitoringエージェントのサポート終了と移行期限

Ops Agentが話題に上る直接のきっかけは、旧エージェントのサポート終了です。期限と移行先の選択肢を先に確認します。

2026年9月28日に止まったものと2027年9月28日までの猶予

Googleの旧Monitoring・Loggingエージェントのサポート終了ページによると、2026年9月28日をもって両エージェントの通常の保守と定期的なバグ修正が終わりました。同日から12か月の移行猶予期間に入り、その間はCloud Customer Careがサポートチケットで移行を手伝います。移行支援は2027年9月28日に終わり、それ以降は自力で移行することになります。

エージェントがその日に止まるわけではありませんが、脆弱性が見つかっても修正版は出ません。Google Cloud Observabilityのリリースノートにも、2026年9月28日付で旧Monitoringエージェントのサポート終了が記録されています。

移行先の3択とログ収集だけの現場でupstream Fluentdを残す判断

公式が示す移行先は、Ops Agent、Google-Built OpenTelemetry Collector、upstream Fluentd（ログのみ）の3つです。Compute EngineのVMで、ログと指標の両方を集めたいならOps Agent一択と考えてかまいません。

Fluentdを残すのは、旧Loggingエージェントに独自プラグインや複雑な設定を積み上げていて、すぐには書き直せない場合に限られます。Google提供のプラグインを使えば、引き続きCloud Loggingへの送信が可能です。Fluentd側の設定の書き方とfluent-package v6への移行はFluentdとは？設定ファイルの書き方とfluent-package v6移行の判断で扱っています。

Ops Agentのインストール手順：単一VMへの導入とIAMロールの付与

ここからは1台のLinux VMへ手で入れる手順です。台数が多い場合はエージェントポリシー（ベータ）でまとめて配る方法もありますが、まず1台で動きを確かめてから広げるのが安全です。

事前準備：サービスアカウントにlogWriterとmetricWriterを付与

Ops Agentは既定でVMに紐づくCompute Engineのサービスアカウントを使って送信します。インストール手順の公式ページが求めるロールは、ログ書き込み用のroles/logging.logWriterと、指標書き込み用のroles/monitoring.metricWriterの2つです。

# SA_EMAIL にはVMに紐づくサービスアカウントのメールアドレスを入れる
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/logging.logWriter"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/monitoring.metricWriter"

ロールが足りないと、エージェントは起動していても送信に失敗し、Cloud Loggingには何も届きません。

Linux VMへのインストールと–versionでのメジャー版固定

VMにSSHで入り、公式のリポジトリ追加スクリプトを取得して実行します。--also-installを付けるとリポジトリ登録とインストールが1回で済み、入れた直後からエージェントが動き始めます。

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# 本番はメジャー版を固定して、2系の範囲でだけ更新させる
sudo bash add-google-cloud-ops-agent-repo.sh --also-install --version=2.*.*

本番VMでは--version=2.*.*のようにメジャー版を固定しておくと、OSのパッケージ更新で意図せず3系へ上がる事故を防げます。特定の版に固定したいときは--version=2.72.0のように3桁で指定する方法です。WindowsではPowerShellスクリプトに-AlsoInstallと-Versionを渡す、同じ考え方の手順が用意されています。

起動確認：systemctlで2つのサブエージェントの稼働を見る

インストール後は、2つのサブエージェントが動いているかを確認します。

sudo systemctl status "google-cloud-ops-agent*"

# 設定を変えたあとはサービスを再起動して反映する
sudo systemctl restart google-cloud-ops-agent

「Logging Agent」と「Metrics Agent」が両方active なら成功で、片方だけ落ちるときはconfig.yamlの書き間違いを疑います。WindowsではGet-Service google-cloud-ops-agent*で状態がRunningになっているかを見ます。

config.yamlの書き方：独自ログの追加・ノイズ除外・指標の間引き

設定ファイルはLinuxなら/etc/google-cloud-ops-agent/config.yaml、WindowsならC:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yamlです。中身はloggingとmetricsの2系統で、それぞれ取得元のreceivers、加工のprocessors、両者をつなぐservice.pipelinesで組み立てます。設定の公式リファレンスのとおり、書いた設定は再起動時に組み込みの既定設定へマージされるので、config.yamlに記述するのは、既定設定との差分だけで十分です。既定の収集を止めたいときは、同じIDで定義し直して上書きします。

アプリのJSONログをfilesレシーバーとparse_jsonで取り込む設定

受託開発の現場でまず書くのは、アプリが出力するログファイルの追加です。次の設定は、/var/log/myapp/配下のJSON形式のログを読み、JSONを解析して構造化ログとしてCloud Loggingへ送ります。

logging:
  receivers:
    myapp_log:
      type: files
      include_paths: [/var/log/myapp/*.log]
      record_log_file_path: true
  processors:
    myapp_json:
      type: parse_json
      time_key: time
      time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"
  service:
    pipelines:
      myapp_pipeline:
        receivers: [myapp_log]
        processors: [myapp_json]

record_log_file_path: trueを付けると、どのファイルから読んだかがagent.googleapis.com/log_file_pathラベルに残ります。ファイルを日付で分けるアプリでは、障害調査で出どころを絞るのに役立ちます。time_keyとtime_formatはアプリのログに合わせて書き換えてください。

exclude_logsとexclude_metricsで取り込み量を入口で削る設定

Cloud Loggingの課金は取り込み量で決まるため、不要なログは送る前に落とすのが一番効きます。exclude_logsは、条件のどれか1つに一致したエントリを取り込みません。

logging:
  processors:
    drop_noise:
      type: exclude_logs
      match_any:
      - 'jsonPayload.path = "/healthz"'
      - 'jsonPayload.level = "debug"'
  service:
    pipelines:
      myapp_pipeline:
        receivers: [myapp_log]
        processors: [myapp_json, drop_noise]

metrics:
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern:
      - agent.googleapis.com/processes/*

数秒おきに来るヘルスチェックのログだけで、取り込み量の大半を占める構成もあります。後半のexclude_metricsはプロセス指標をまるごと止める例です。

旧エージェントからOps Agentへの移行手順と切り替え時の落とし穴

手順は公式の移行ガイドに沿って組み立てます。ガイドの流れは「旧エージェントを外す、Ops Agentを入れる、必要に応じて設定する」の3段で、そこに事前の検出を足します。

旧エージェントの検出からアンインストール・入れ替えまでの4工程

旧エージェントが入っているVMを洗い出す（コンソールのVM一覧でエージェント列を確認）
旧Loggingエージェントと旧Monitoringエージェントをアンインストールする
Ops Agentを入れ、起動確認をする
旧エージェントの独自設定をOps Agentのconfig.yamlへ書き直す

Debian・Ubuntu系では、次のコマンドで旧エージェントの有無を確かめてから外します。アンインストールは、旧Loggingエージェントと旧Monitoringエージェントそれぞれのインストール手順ページにある、導入時と同じスクリプトに--uninstallと--remove-repoを付けて実行します。

# 旧エージェントのパッケージが入っているか確認する
dpkg-query --show google-fluentd stackdriver-agent

# 導入時のスクリプトでアンインストールし、リポジトリ登録も消す
sudo bash add-logging-agent-repo.sh --uninstall --remove-repo
sudo bash add-monitoring-agent-repo.sh --uninstall --remove-repo

アンインストール後、コンソールの表示に反映されるまで最大1時間かかることがあります。旧エージェントとOps Agentを同じVMで並べて動かすと、同じログを二重に取り込んで課金も二重になるため、必ず外してから入れる順番を守ります。

既存のダッシュボードとアラートが壊れるディスク名と指標名の差分

移行後に気づきにくいのが、指標の名前と値の書式の違いです。移行ガイドは、ディスクのデバイス名がOps Agentでは/dev/sda15のようなフルパス、旧エージェントではsda15だと注意しています。デバイス名で絞り込んでいたアラートポリシーは、そのままでは一致しなくなります。

サードパーティ統合の指標もworkload.googleapis.com/nginx.requestsのような名前で入るため、旧エージェント時代のダッシュボードは移行直後に開き、グラフが空になっていないかを確かめます。指標側の画面構成とアラートの組み方はCloud Monitoring（Google Cloud）とは？機能・料金・設定・他ツール比較で確認できます。

Telemetry API経由の送信と2.71.0以降のotlp_exporter設定

2026年9月14日に出た2.71.0から、Ops AgentはOpenTelemetryベースのTelemetry APIへデータを送れるようになりました。従来のCloud Monitoring API・Logging API・Trace APIを個別に呼ぶ代わりに、OTLP形式で1つのAPIへまとめて送る経路です。

# Telemetry APIをプロジェクトで有効にする
gcloud services enable telemetry.googleapis.com

# /etc/google-cloud-ops-agent/config.yaml に追記する
global:
  otlp_exporter: true

Telemetry APIの公式手順によると、トレースも送る場合はサービスアカウントにroles/telemetry.tracesWriterが要ります。注意点は既存の監視で、monitoring.googleapis.comやlogging.googleapis.comのAPI指標を見ているチャートやアラートは、telemetry.googleapis.comを見るように修正する必要がある点に注意してください。元に戻すときはotlp_exporterの行を消して再起動します。アプリから送るOTLPトレースの見え方はCloud Traceとは？Google Cloudの分散トレーシングの仕組み・OpenTelemetry連携・料金と導入判断が参考になります。

既存VMの移行では、まず従来の経路でOps Agentへ載せ替え、落ち着いてから切り替えるほうが原因を切り分けやすくなります。

Ops Agentの料金：ログ50GiB無料枠とエージェント指標の課金範囲

Ops Agent自体は無料で、課金は送ったデータに対して発生します。Google Cloud Observabilityの料金ページの主な単価は次のとおりです（2026年10月時点）。

対象	単価	無料枠
ログの取り込み	0.50米ドル／GiB	月50GiB／プロジェクト
ログの保持（30日超）	0.01米ドル／GiB・月	30日までは無料
指標（〜10万MiB）	0.2580米ドル／MiB	月150MiB／請求先
プロセス指標	通常の5%換算	上記と共通

ログは取り込み時の1回課金で、30日分の保管まで含みます。たとえば月120GiBを取り込むプロジェクトなら、無料枠を引いた70GiBに0.50米ドルを掛けて月35米ドルです。

指標は、agent.googleapis.com配下のエージェント指標が課金対象です（エージェント自身の状態を示すagent.googleapis.com/agent/配下は無料）。サードパーティ統合のworkload.googleapis.com指標も課金対象なので、統合を有効にするVMを増やすほど指標の費用が積み上がります。

GCE運用でOps Agentを入れる条件と入れずに済ませる場面の線引き

ここでの導入判断は、本番VMかどうかが基準です。Compute EngineのVMを本番で動かすなら、Ops Agentは原則として入れます。入れなくてよい場面ははっきりしているので、条件で切り分けます。

導入すべき条件：GCEで常駐ミドルウェアを持ち障害調査が必要な構成

次のどれかに当てはまるVMには入れます。第一に、nginxやMySQLなど常駐ミドルウェアのログと指標を障害調査に使う構成です。第二に、メモリ使用率やディスク使用率でアラートを出したい場合で、これは標準の指標だけでは取れません。第三に、旧エージェントが残っているVMで、2027年9月28日より前に片付けます。

VMを持ったまま運用を続ける案件では、config.yamlの差分管理とアラートの見直しまでを運用手順に組み込んでおくと、担当者が替わっても監視が崩れません。当社の保守運用・内製化支援でも、旧エージェントの棚卸しからOps Agentへの入れ替え、取り込み量の設計までを運用チームと一緒に進めています。

見送る場面：Cloud Run・GKE中心や1台きりの検証VMでは過剰

Cloud RunやGKEが中心のシステムには入れません。収集経路がプラットフォーム側に組み込まれているためです。数日で消す検証用のVMに入れるのも過剰で、シリアルコンソールと標準の指標で足ります。

もう1つの失敗パターンは、入れたあとexclude_logsを書かずに放置することです。デバッグログを出し続けるアプリがあると、無料枠の50GiBを月の前半で使い切り、ログ費用がVM本体の費用を上回ることもあります。導入と同時に、取り込まないログを決めてください。

Ops Agentの導入・設定・旧エージェント移行に関するよくある質問

Ops Agentの導入と移行で問い合わせの多い5点に、実装者の目線で答えます。

Ops AgentとCloud Loggingは何が違いますか？

Ops AgentはVMの中で動いてデータを集めて送る側、Cloud Loggingはそれを受け取って保管・検索する側のサービスです。Ops Agentは指標とトレースも送るため、送り先はCloud LoggingとCloud Monitoringの両方になります。

旧Loggingエージェントは2026年9月28日以降も動きますか？

入っているVMでは動き続けますが、2026年9月28日で保守とバグ修正が終わり、OS更新で動かなくなっても修正は出ません。移行支援も2027年9月28日で終わるため、動いているうちに入れ替えを計画してください。

Amazon EC2やオンプレミスのサーバーにも入れられますか？

入れられません。公式ドキュメントはAmazon EC2とオンプレミスのマシンをサポート対象外としています。それらからCloud Loggingへ送るなら、Google-Built OpenTelemetry CollectorかFluentdで経路を組みます。

Ops Agentを入れるとどのくらい費用がかかりますか？

エージェントは無料で、費用は送ったデータ量で決まります。ログは月50GiBまで無料、超過分は1GiBあたり0.50米ドル、指標は月150MiB超から1MiBあたり0.2580米ドルです（2026年10月時点）。最初に効く節約策は、ヘルスチェックなどのログをexclude_logsで落とすことです。