Loggingエージェントを捨ててOpsエージェントに乗り換える

こんにちは、クラウドエース編集部です。

GCPでログを収集したり、インスタンスの使用状況などを監視する場合は、LoggingエージェントやMonitoringエージェントを利用することが一般的でした。

筆者もこれらを利用してきましたし、Loggingエージェントのために数々のfluentdのconfigファイルを書いてきましたが、これらは新たなOpsエージェントに置き換えるのが良さそうに見えます。

Opsエージェントに関するGoogle Cloud Japanの公式ブログによれば、「従来のLoggingエージェントに存在していたOutOfMemoryエラーやデータの損失を防止できる」と書いてあるので、これらに頭を悩まされてきた身としては見過ごすわけにはいきません。

この記事では、Opsエージェントを使い始めるまでの設定と、任意のアプリケーションログをGCPのLoggingで閲覧するための設定内容を調査していきます。

Opsエージェントのインストール

Ubuntu20.04のVMインスタンスを起動し、オペレーションスイート(旧Stackdriver)のエージェントポリシーを利用してインストールと起動までをある程度自動化しましょう。

Ubuntuの起動

gcloud compute instances create ubuntu20 \ --zone=asia-northeast1-a \ --subnet=<YOUR_SUBNET> \ --no-address \ --image=ubuntu-2004-focal-v20210720 \ --image-project=ubuntu-os-cloud \ --boot-disk-size=100GB

OS Configエージェントのインストール

# インスタンス内で実行 sudo apt update sudo apt -y install google-osconfig-agent
これで、エージェントポリシーをUbuntu OSに対して設定すれば、今後Ubuntuのインスタンスには自動でOpsエージェントがインストールされます。

エージェントポリシーの設定

次のコマンドは、Ubuntu 20.04 のインスタンスにOS Configエージェントが起動していれば ops-agentを自動アップグレードを有効にしてインストールするポリシーです。
これをCloud Consoleから閲覧する手段は執筆時点では無いようです。
紛らわしいですが、OS Policyとは別の機能です。
gcloud beta compute instances ops-agents policies create ops-agents-policy-safe-rollout \ --agent-rules="type=ops-agent,version=current-major,package-state=installed,enable-autoupgrade=true" \ --os-types=short-name=ubuntu,version=20.04
これで、インスタンスに ops-agentがインストールされます。
# インスタンス内で実行 systemctl status google-cloud-ops-agent ● google-cloud-ops-agent.service - Google Cloud Ops Agent Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled) Active: active (exited) since Sat 2021-08-07 04:16:23 UTC; 1h 47min ago
ドキュメントによると、デフォルトでは、次のような設定が有効のようです。
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に送る

nginxのコンテナを実行して、その標準出力をLoggingに送ってみます。
まずはdockerをインストールして、nginxコンテナを実行しましょう。
ここからはrootユーザで実行します。
# インスタンス内で実行 sudo su apt install docker.io docker run -d --name nginx -p 0.0.0.0:80:80 nginx:stable-alpine

docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8f6af88ebe4a nginx:stable-alpine “/docker-entrypoint.…” 4 minutes ago Up 4 minutes 0.0.0.0:80->80/tcp nginx

この時、コンテナの標準出力は /var/lib/docker/containers/CONTAINER_IDディレクトリのCONTAINER_ID-json.logに吐き出されているので、
コンテナの標準出力をLoggingに送るには、次のようにconfigを書けば良さそうです。
このとき、LoggingにおけるlogNameはcontainersとなっていました。
logging: receivers: containers: # これがlogNameになる type: files include_paths: - /var/lib/docker/containers/*/*.log service: pipelines: default_pipeline: receivers: [] nginx_pipeline: recievers: [containers] processors: [nginx] processors: nginx: type: parse_json field: log time_key: time time_format: '%Y-%m-%dT%H:%M:%S.%NZ'
fluentdであれば、下記のようなログの中から logプロパティを取り出したりできるのですが、
Opsエージェントでの方法がわかりませんでした。
筆者の理解の範囲では、fluentdで柔軟な設定ができるLoggingエージェントの方が自分たちの要件にあったparseができそうです。
{"log":"172.17.0.1 - - [07/Aug/2021:05:35:21 +0000] \GET / HTTP/1.1\" 200 612 \"-\" \"curl/7.68.0\" \"-\"\n"stream":"stdout"

ログファイルをLoggingに送る

続いてはコンテナの標準出力ではなく、インスタンスの任意のpathに吐き出されるログをLoggingに送ります。
色々なログパターンが欲しいので、GitLabを起動することにします。
次のdocker-composeファイルを用意しました。
34.146.28.37はubuntuインスタンスに外部から到達するために起動したTCPロードバランサーのIPアドレスです。
version: "3.8" services: gitlab: image: 'gitlab/gitlab-ee:latest' hostname: 'gitlab' environment: GITLAB_OMNIBUS_CONFIG: | external_url 'http://34.146.28.37' nginx['listen_port'] = 80 nginx['listen_https'] = false gitlab_exporter['enable'] = true ports: - '80:80' volumes: - '/srv/gitlab/config:/etc/gitlab' - '/srv/gitlab/logs:/var/log/gitlab' - '/srv/gitlab/data:/var/opt/gitlab'
これをdocker composeで実行すると、 /srv/gitlab/logs/gitlab-rails/application_json.logに次のようなログが出力されるので、
これをLogginに送ることを目的にします。
{"severity":"DEBUG"
これは、次のようにconfigを書けば実現できます。
logging: receivers: gitlab-application: type: files include_paths: - /srv/gitlab/logs/gitlab-rails/application_json.log service: pipelines: default_pipeline: receivers: [] gitlab_application: receivers: [gitlab-application] processors: [gitlab-application] processors: gitlab-application: type: parse_json field: message time_key: time time_format: '%Y-%m-%dT%H:%M:%S.%LZ'
Cloud Consoleでは次のように構造化されたログを確認することができます。

さらに別のログを見ていきましょう。
/srv/gitlab/logs/nginx/gitlab_access.logには、nginxのアクセスログが出力されています。
これを正規表現を使ってparseしてみましょう。

サンプルとして、ログを1つ取り出します。
36.13.16.123 - - [07/Aug/2021:09:39:46 +0000] "GET /search/opensearch.xml HTTP/1.1" 200 321 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML
これをparseするためには次のような正規表現を書けます。
/^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"(?:\s+(?<http_x_forwarded_for>[^ ]+))?)?$/
先程のconfigと合わせると、最終的に次のようなファイルが出来上がりました。
logging: receivers: gitlab-application: type: files include_paths: - /srv/gitlab/logs/gitlab-rails/application_json.log gitlab-access: type: files include_paths: - /srv/gitlab/logs/nginx/gitlab_access.log service: pipelines: default_pipeline: receivers: [] gitlab_application: receivers: [gitlab-application] processors: [gitlab-application] gitlab_access: receivers: [gitlab-access] processors: [gitlab-access] processors: gitlab-application: type: parse_json field: message time_key: time time_format: '%Y-%m-%dT%H:%M:%S.%LZ' gitlab-access: type: parse_regex fielad: message regex: '/^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"(?:\s+(?<http_x_forwarded_for>[^ ]+))?)?$/' time_key: time time_format: '%d/%b/%Y:%H:%M:%S %z'
Loggingの画面でもしっかり構造化されていることを確認できます。