--- title: "Ops Agentとは？Google CloudのVMにログ・指標収集を入れる手順とconfig.yaml設定、旧エージェント移行を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/18306/" published: 2026-10-13 updated: 2026-10-13 categories: ["Google Cloud"] publisher: "株式会社一創" --- # 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の公式概要](https://docs.cloud.google.com/stackdriver/docs/solutions/agents/ops-agent)は、Ops AgentをCompute Engineインスタンスからテレメトリを集める「主要なエージェント」と位置づけています。集めたログは[Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違い](https://www.issoh.co.jp/tech/details/15671/)で解説したログバケットへ、指標はCloud Monitoringへ入ります。導入先となるVMの基本は[Compute Engineとは？GCPの仮想マシンの仕組み・料金とgcloudでのVM作成手順](https://www.issoh.co.jp/tech/details/15665/)を参照してください。 ### Fluent BitとOpenTelemetry Collectorの2エンジン構成 Ops Agentは自前の収集エンジンを持たず、OSSを2つ組み合わせています。ログはFluent Bit、指標とトレースはOpenTelemetry Collectorが受け持ちます。旧Loggingエージェントの基盤だったFluentdより軽量なFluent Bitへ切り替えたことで、高スループットのログ収集に対応しました。 2つのエンジンは、それぞれ別のプロセスとして動く構成です。エンジン単体の設定思想は[Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例](https://www.issoh.co.jp/tech/details/12612/)と[OpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違い](https://www.issoh.co.jp/tech/details/3625/)にまとめています。Ops Agentではそれらを直接書かず、独自のYAML形式で書いた設定がエンジン用の設定へ変換されます。 [GitHubのリリース一覧](https://github.com/GoogleCloudPlatform/ops-agent/releases)では、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エージェントのサポート終了ページ](https://docs.cloud.google.com/logging/docs/agent)によると、2026年9月28日をもって両エージェントの通常の保守と定期的なバグ修正が終わりました。同日から12か月の移行猶予期間に入り、その間はCloud Customer Careがサポートチケットで移行を手伝います。移行支援は2027年9月28日に終わり、それ以降は自力で移行することになります。 エージェントがその日に止まるわけではありませんが、脆弱性が見つかっても修正版は出ません。[Google Cloud Observabilityのリリースノート](https://docs.cloud.google.com/stackdriver/docs/release-notes)にも、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移行の判断](https://www.issoh.co.jp/tech/details/17743/)で扱っています。 ## Ops Agentのインストール手順：単一VMへの導入とIAMロールの付与 ここからは1台のLinux VMへ手で入れる手順です。台数が多い場合はエージェントポリシー（ベータ）でまとめて配る方法もありますが、まず1台で動きを確かめてから広げるのが安全です。 ### 事前準備：サービスアカウントにlogWriterとmetricWriterを付与 Ops Agentは既定でVMに紐づくCompute Engineのサービスアカウントを使って送信します。[インストール手順の公式ページ](https://docs.cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/installation)が求めるロールは、ログ書き込み用の`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`で組み立てます。[設定の公式リファレンス](https://docs.cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/configuration)のとおり、書いた設定は再起動時に組み込みの既定設定へマージされるので、`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への移行手順と切り替え時の落とし穴 手順は[公式の移行ガイド](https://docs.cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/transition)に沿って組み立てます。ガイドの流れは「旧エージェントを外す、Ops Agentを入れる、必要に応じて設定する」の3段で、そこに事前の検出を足します。 ### 旧エージェントの検出からアンインストール・入れ替えまでの4工程 1. 旧エージェントが入っているVMを洗い出す（コンソールのVM一覧でエージェント列を確認） 2. 旧Loggingエージェントと旧Monitoringエージェントをアンインストールする 3. Ops Agentを入れ、起動確認をする 4. 旧エージェントの独自設定をOps Agentの`config.yaml`へ書き直す Debian・Ubuntu系では、次のコマンドで旧エージェントの有無を確かめてから外します。アンインストールは、旧[Loggingエージェント](https://docs.cloud.google.com/logging/docs/agent/logging/installation)と旧[Monitoringエージェント](https://docs.cloud.google.com/monitoring/agent/monitoring/installation)それぞれのインストール手順ページにある、導入時と同じスクリプトに`--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）とは？機能・料金・設定・他ツール比較](https://www.issoh.co.jp/column/details/2834/)で確認できます。 ## 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の公式手順](https://docs.cloud.google.com/monitoring/agent/ops-agent/use-telemetry-api)によると、トレースも送る場合はサービスアカウントに`roles/telemetry.tracesWriter`が要ります。注意点は既存の監視で、`monitoring.googleapis.com`や`logging.googleapis.com`のAPI指標を見ているチャートやアラートは、`telemetry.googleapis.com`を見るように修正する必要がある点に注意してください。元に戻すときは`otlp_exporter`の行を消して再起動します。アプリから送るOTLPトレースの見え方は[Cloud Traceとは？Google Cloudの分散トレーシングの仕組み・OpenTelemetry連携・料金と導入判断](https://www.issoh.co.jp/tech/details/15752/)が参考になります。 既存VMの移行では、まず従来の経路でOps Agentへ載せ替え、落ち着いてから切り替えるほうが原因を切り分けやすくなります。 ## Ops Agentの料金：ログ50GiB無料枠とエージェント指標の課金範囲 Ops Agent自体は無料で、課金は送ったデータに対して発生します。[Google Cloud Observabilityの料金ページ](https://cloud.google.com/products/observability/pricing)の主な単価は次のとおりです（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`の差分管理とアラートの見直しまでを運用手順に組み込んでおくと、担当者が替わっても監視が崩れません。当社の[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)でも、旧エージェントの棚卸しから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`で落とすことです。 ### GKEやCloud RunにもOps Agentは必要ですか？ 必要ありません。GKEやCloud Runにはログと指標の収集経路が組み込まれており、アプリが標準出力に書いた構造化JSONがそのままログエントリになります。Ops Agentの対象はCompute EngineのVMです。 ## 関連記事 - [Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15671/)：Ops Agentが送ったログの保管・振り分け・保持期間の設計。 - [Cloud Monitoring（Google Cloud）とは？機能・料金・設定・他ツール比較を解説](https://www.issoh.co.jp/column/details/2834/)：Ops Agentの指標を受けるダッシュボードとアラートの組み方。 - [Compute Engineとは？GCPの仮想マシンの仕組み・料金とgcloudでのVM作成手順を実装者目線で解説](https://www.issoh.co.jp/tech/details/15665/)：Ops Agentを入れる側のVMの基本と作成手順。 - [Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例](https://www.issoh.co.jp/tech/details/12612/)：Ops Agentのログ側エンジンの仕組みと設定思想。 - [OpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違い](https://www.issoh.co.jp/tech/details/3625/)：Ops Agentの指標・トレース側エンジンの基礎。 --- 出典: [Ops Agentとは？Google CloudのVMにログ・指標収集を入れる手順とconfig.yaml設定、旧エージェント移行を実装者目線で解説]()（株式会社一創）