こんにちは、PharmaX エンジニアの尾崎(@FooOzaki)です。
本記事ではGoogle CloudのVM(Compute Engine)のログ収集およびインフラメトリクスの収集を「Ops エージェント」を利用して実施する方法をご紹介します。
はじめに
本記事ではシンプルに任意のログファイルを収集・送信する方法を中心にご説明しますが、Google Cloud の公式ドキュメントも引用しながらご説明しますので利用シーンに合わせて適宜ドキュメントも読んでいただけると良いかと思います。
私はLinux環境へ導入したのでLinuxベースでのご説明になりますが、Windowsのケース等も公式ドキュメントには記載があります。
記事執筆は2024年7月に実施しているのですが、Google Cloud コンソールのGUIが最近変わり、公式ドキュメントもここ1年でかなりアップデートされていたので実際に導入される方は公式ドキュメントもセットで確認しながら進めていただけると幸いです。
Ops エージェントとは
Ops エージェントは、Compute Engine インスタンスからデータを収集して Cloud Monitoring や Cloud Logging に送信するエージェントソフトウェアです。
詳細はこちらを確認いただければと思いますが、システム監視(Monitoring)とシステムログ収集(Logging)を1つのエージェントでできるのが特徴です。
Ops エージェントの登場前はMonitoringとLoggingで別々のエージェントを入れていた時代もあるようですが、今はOps エージェント1つで基本的に完結可能です。
Ops エージェントのインストール方法
導入方法はユースケースによって色々なパターンがあるため、状況に応じて以下の公式ドキュメントをご参照いただければと思います。
私は稼働中のインスタンスにサッと導入してしまいたかったので手動で導入をしました。
コンソールから導入する場合は、以下の手順で可能です。
1.Google Cloud コンソールで、[VM インスタンス] ページに移動し、エージェントをインストールする VM の名前をクリックします。
2.[オブザーバビリティ] タブをクリックし、[Ops エージェントをインストール] をクリックします。
コマンドラインから導入する場合はインスタンスへSSHして以下のコマンドで実行します。
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
今回は詳しくは紹介しませんが、VM作成時に導入する場合は「VM 作成時に Ops エージェントをインストールする」のドキュメントにある通り、構成ポリシーを設定する形が良いかと思います。
また、「自動化ツールによるエージェントの管理」にある通り、Terraformなど各種構成管理ツールにも対応してます。
インストールのトラブルに関してですが、診断ツールもあるようなので以下を参考にしていただければと思います。
私の場合は、関連付けられているサービスアカウントへログ書き込み系のロール割り当てが必要でした。
roles/logging.logWriter
roles/logging.metricWriter
Ops エージェントの構成変更
インストールが完了した後はOpsエージェントの設定（構成変更）をしていきます。
ユーザ側で構成ファイル（YAMLファイル）を変更し、デフォルト設定をマージ・オーバライドすることで構成変更することが可能です。
本記事では基本的な構成設定の考え方の説明に留めますが、詳しくはこちらのドキュメントを参照いただければと思います。
具体的な構成ファイルと変更例を見た方がイメージしやすいと思うのでご紹介していきます。
構成ファイルはLinuxの場合は以下に配置します。
/etc/google-cloud-ops-agent/config.yaml
Linuxの場合はこちらがデフォルトの設定です。
logging:
receivers:
syslog:
type: files
include_paths:
- /var/log/messages
- /var/log/syslog
service:
pipelines:
default_pipeline:
receivers: [syslog]
metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 60s
processors:
metrics_filter:
type: exclude_metrics
metrics_pattern: []
service:
pipelines:
default_pipeline:
receivers: [hostmetrics]
processors: [metrics_filter]
logging: がログ収集に関連する設定で、metrics: がモニタリング指標に関する設定です。
公式ドキュメントから引用しますが、構成ファイルの基本要素は以下の要素となっています。
-
receivers: この要素はエージェントによって収集される内容を表します。 -
processors: この要素は、エージェントが収集した情報を変更する方法を記述します。 -
service: この要素は、レシーバーとプロセッサをリンクして、パイプラインというデータフローを作成します。service要素には、複数のパイプラインを含めることができるpipelines要素が含まれます。
少し表現はわかりにくいのですが、receivers でどのデータを収集するかを定義し、processors で収集したデータをどのように加工して送信するかを定義します。
続いてservice でreceiversとprocessorsを組み合わせたパイプラインpipelines を定義します。
例えばauth.logをCloud Loggingへ送信したい場合は以下の記述でできます。
logging:
receivers:
auth_log:
type: files
include_paths:
- /var/log/auth.log
service:
pipelines:
auth_log_pipline:
receivers: [auth_log]
processorsはログの加工や出力フォーマットの変更等をしなければ省略可能なので、recivers へログファイルを追加し、併せて サービスservice:のパイプライン pipelines: へ追加すればOKです。パイプライン名は「auth_log_pipline」としてますが、任意の名前を設定可能です。
私の場合は上記の設定でユースケースを満たせましたが、前述の公式ドキュメントに細かく設定項目の記載がありますので、適宜ご参照いただければと思います。
基礎の考え方はお伝えできたかと思いますので、本記事を参考に色々設定いただけると幸いです。
おわりに
以上、Google CloudのOpsエージェントについてのご紹介でした。
Google CloudでVM(Compute Engine)の運用監視をしたり、ログ収集を行いたい場合はOpsエージェントで手軽に設定が可能です。
ぜひ導入を検討していただければと思います。
PharmaX では、様々なバックグラウンドを持つエンジニアをお待ちしております。
もし、興味をお持ちの場合は、私のXアカウント(@FooOzaki)にお気軽にメッセージいただけますと幸いです！
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note（note.com/pharmax）もご覧ください。
Discussion