こんにちは、G-genの渡邉@norry です。
皆さんCloud Logging は活用されていますか？
Cloud Logging は Google Cloud (GCP) 上のシステム等が生成したログを収集・保管・管理する仕組みです。 まずはCloud Logging とは何か？ をしっかり理解したい方は以下の記事をおすすめします。
本項では GCP 上の Windows VM より Google Cloud オペレーションスイートのエージェント ( Ops Agent ) を利用して Cloud Logging にログファイルを収集する方法をご案内します。
Ops エージェント概要
Ops エージェントとは
Ops エージェントは、Compute Engine インスタンスからテレメトリー (稼働データ)を収集して Cloud Monitoring や Cloud Logging に送信するエージェントソフトウェアです。
公式ガイドはコチラを参照くだい。
Ops エージェントではログの取得と指標 を一つのエージェントに統合している部分がポイントです。以前は指標の収集送信に "Cloud Monitoring エージェント" を、ログの収集には "Cloud Logging エージェント" を、というように別々のエージェントが存在していました。現在ではこれらが Ops エージェントとして統合されています。
また、ここで言うログはシステムから出力される何らかのイベントログやアプリケーションから出力されるテキスト形式のログのこと、指標は例えば1秒間あたりにどのくらいのCPUやメモリの使用率があったかと言うような稼働状況と捉えていただいても問題ないかと思います。
Ops エージェントはログに Fluent Bit を使用しており、高スループット ロギングと指標の OpenTelemetry Collector がサポートされています。
サポートされるOS
エージェントは標準的な Linux 及び Windows ディストリビューションで稼働します。
サポート対象 OS の一覧はコチラです。
Ops エージェントの機能
ロギング関連の主要な機能は次のとおりです。
- 設定なしで標準のシステムログ（Linux の /var/log/syslog と /var/log/messages、Windows のイベントログ）を収集
- カスタム ログファイル
- JSON ログ。
- 書式なしテキストのログ
- 正規表現を使用した解析。
- JSON ベースの解析
任意の形式のログを取得する際に、正規表現でログを抽出しJSON 形式に変換し Cloud Logging に送信する事が可能です。
標準対応しているサードパーティアプリ
Ops エージェントではサポートされているサードパーティ アプリケーションの自動ログ解析が可能となっています。その場合にはファイル解析をする為に Ops エージェントを構成します。この構成については後述します。
2022年2月時点での対応サードパーティアプリは次のとおりです。
- Apache Tomcat
- Cassandra
- Elasticsearch
- IIS (WIndows のみ)
- JVM
- MariaDB
- Memcached
- MS SQL Server (WIndows のみ)
- MySQL
- Nginx
- PostgreSQL
- Redis
なお、ここにリストされているソフトウェア以外の収集も、カスタム構成を行うことで 実現できます のでご安心ください (後述) 。
さらに参考として、モニタリング機能は次のとおりです (当記事では詳しく扱いません) 。
- CPU 指標
- ディスク指標
- iis 指標（Windows のみ）
- インターフェース指標
- メモリ指標
- mssql 指標（Windows のみ）
- pagefile 指標（Windows のみ）
- スワップ指標
- ネットワーク指標
- プロセス指標
- 内部エージェント指標の選択:
- api_request_count
- memory_usage
- monitoring/point_count
- 稼働時間
Ops エージェントのインストールと起動確認
インストール方法
インストール方法については大きく下記3つの方法があります。
- gcloud / エージェント ポリシーを使用して VM フリートにエージェントをインストール
- 自動化ツール (Ansible、Chef、Puppet、Terraform ) を使用して VM フリートにエージェントをインストールする
- 個々の VM に Ops エージェントをインストールする
今回は Windows VM で任意のログを取得する事を目的としていますので、さくっと個々のVM に Ops エージェントをインストールする方法で、インストールを行います。
Compute Engine ＞ 該当のWindows インスタンス ＞ インスタンスの編集 よりメタデータに以下の内容を記載します。
キー1 : windows-startup-script-ps1
値1:
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1")
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"
上記を記述し WIndows VM を起動すると自動的にインストールが開始されます、インストールは初回のみで良いのでインストールが終了したらメタデータの記述は消去しても大丈夫です。
起動確認
VM 起動後にOps エージェントが正常起動すると、Google Cloud Ops Agent、Google Cloud Ops Agent - Logging Agent、Google Cloud Ops Agent - Metrics Agent のサービスが実行されている事が確認できます。
またGCP 管理コンソール ＞ ロギング ＞ ログエクスプローラー で RESOURCE TYPE にVM Instance が表示されWindows のイベントログが取得出来ている事が確認出来ます。
任意のログの取得方法
Ops エージェントの構成
前項で表記したデフォルトで取得するログ以外を取得する場合にはOps エージェントの構成の変更が必要になります。それ以外にも下記のような目的の時に変更が必要になります。
- デフォルトのロギングや指標の取り込みをオフにする
- ログ収集元のファイルパスをカスタマイズする
- ログをJSON や正規表現で解析し構造を変更する
- 指標のサンプリングレートの変更 (60秒周期から30秒など)
Ops エージェントはデフォルトの構成があり、その構成は直接操作する事は出来ません。そのかわりにユーザー側で追加・変更の構成ファイルを作成しデフォルトの構成にマージ・上書きします。適用にはOps エージェントのサービス再起動が必要になります。
把握しておくべき構成要素は次の通りです。
receivers:この要素はエージェントによって収集される内容を表します。(ログの場所の指定など)processors:この要素は、エージェントが収集した情報を変更する方法を記述します。(ログを正規表現で抽出、JSON形式で格納など)service:この要素は、レシーバーとプロセッサをリンクして、パイプラインというデータフローを作成します。service 要素には、複数のパイプラインを含めることができる pipelines 要素が含まれます。
Windows のOps エージェントではデフォルトの構成では次の通りです。デフォルトの内容を変更したい場合にはユーザー側で新たに設定ファイルを作成します。
logging:
receivers:
windows_event_log:
type: windows_event_log
channels: [System, Application, Security]
service:
pipelines:
default_pipeline:
receivers: [windows_event_log]
metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 60s
iis:
type: iis
collection_interval: 60s
mssql:
type: mssql
collection_interval: 60s
processors:
metrics_filter:
type: exclude_metrics
metrics_pattern: []
service:
pipelines:
default_pipeline:
receivers: [hostmetrics, iis, mssql]
processors: [metrics_filter]
詳しくはコチラを参照ください。
Windows VM での設定手順実例
ユーザーがデフォルトで収集されないログ、例えばベンダーのパッケージ製品のテキストログを Cloud Loggingに集約する場合を想定して設定確認をしてみます。
今回はコチラ の簡易的なWeb サーバーを利用してそのログを Ops エージェントを通じて Cloud Logging へ送信します。
Webサーバーの構成は次の通りです、実行ファイルと同一フォルダにHTTDir.log というログファイルが出力されました。
Web サーバー起動時のログはこのような内容です。
[2/17/2022 12:22:51 AM] awdss_1 [2/17/2022 12:22:51 AM] awdss_2 [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\Get.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTT.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTTDir.exe [2/17/2022 12:22:51 AM] awdss_self_noop [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\MimeType.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_3 [2/17/2022 12:22:51 AM] awdss_4
Windows では以下のパスにある yaml ファイルをメモ帳などで編集します。
C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml
今回は次のように設定しました。
logging:
receivers:
HTTDir_general:
type: files
include_paths: [C:\HTTDir\*.log]
service:
pipelines:
HTTDir_general:
receivers:
- HTTDir_general
内容について詳述します。
logging:ログを収集して送信します、指標を取得する場合はmetrics:で記述します。receivers:どのデータを収集するかの指定HTTDir_general:RECEIVER_ID と呼ばれるIDです、任意のIDを設定します。type:どの形式で取得するかを指定します、filessyslogwindows_event_logなどが指定可能です。include_paths:type がfilesの場合、取得するログが保存されている場所を指定します。
service:receivers:とprocessors:を紐づけて Cloud Logging へ送信します。重要度に応じてレベル分けも可能となっています。pipelines:パイブライン名をHTTDir_general:としています。receivers:レシーバー名HTTDir_generalの内容を Cloud Logging へ出力します。
Cloud Logging ＞ [VM Instance] ＞ [Log Name] で確認すると次のようになります。 IDで設定した名前でログが登録されている事が分かります。
また、ログの中はこのようになりました。 jsonPayload 内にログが、まるっと格納されている事が確認できます。
jsonPayload の中にそのままメッセージ内容を入れるだけであればこのままで良いですが、フィールドとして表記したい場合やタイムスタンプとしてjsonPayload 外に値として取り入れたい事もあるかもしれません
その場合は config.yaml に processors: を追記、正規表現を用いてフィールドに格納します。
今回は単純なログですので簡単にtime フィールドと msg フィールドに分けてみました。
logging:
receivers:
HTTDir_general:
type: files
include_paths: [C:\HTTDir\*.log]
+ processors:
+ HTTDir_general:
+ type: parse_regex
+ regex: "\[(?<time>[^\]]+)]\s+(?<msg>.*)$"
service:
pipelines:
HTTDir_general:
receivers:
- HTTDir_general
+ processors:
+ - HTTDir_general
追記部分の補足をします。
processors:レシーバーで得たデータを操作します。-
HTTDir_general:PROCESSOR_ID を指定します。今回はRECEIVER_ID と同一名にしています。 -
type:ログの内容を解析・変換方法を指定します。parse_regexでは正規表現を使って解析し、JSON形式に変換します。元々のログ形式がJSON の場合はparse_jsonを利用します。 -
regex:type にparse_regexを指定した場合必須、正規表現で内容を解析し各キーにあてます。今回は正規表現を用いて 時間とメッセージで抽出しています。 service:processors:のPROCESSOR_IDを追記しています。
上記内容にconfig.yaml を変更しOps Agent サービスを再起動した後の jsonPayload の内容は次の通りになりました。 jsonPayload 内でtime キー と msg キーでログの値が抽出されている事が分かります。
サポートされているサードパーティアプリであれば正規表現等は使わずとも良い感じにCloud Loggingへ収集してくれますので興味がある方は公式ドキュメントを読んでみてください。
渡邉 宣之 (記事一覧)
クラウドソリューション部
データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持
週末フォトグラファーで、観葉植物や塊根植物にハマってます。
