Google Cloud のログ設定 Cloud Logging の概要と一部設定など #GoogleCloud

はじめに

Cloud Logging について使い始めるのにまとめたのでその内容を記載する
一部設定についても実施してみたのでその内容も記載する (Logging Storage/オンプレ収集エージェント(fluent-plugin-google-cloud)など)

Cloud Logging とは

概要

ドキュメント： https://cloud.google.com/logging/docs/basic-concepts?hl=ja

Google Cloud のオペレーションスイートサービスの一部
ログのストレージ、ユーザーインターフェース（ログエクスプローラ）、ログをプログラムで管理する API から構成される
Logging では、ログエントリの読み取りと書き込み、ログのクエリができ、またログのルーティングと使用方法を制御可能

ログの種類

ドキュメントとその先のリンク先を参考に表にまとめてみた

種類	内容	例	ログの詳細URL	デフォルトの保持期間
Google Cloud Platform のログ	Google Cloudからログエントリを受信、インデックス作成、保存される一部はエージェントによって送信される	Cloud SQL, Binary Authorization, GKE On-prem (Anthos), Secret Manager,Serial Console, etc.(詳細は右のリンク先)	Google Cloud platform logs	30日 (デフォルトバケット `_Default`)
ユーザー作成のログ	ユーザーが独自のログを作成する一般的な方法の 1 つユーザーにより Cloud Logging に書き込まれる書き込みには、Logging エージェント、Cloud Logging API、または Cloud Logging クライアントライブラリが使用されるデフォルトの Logging エージェントよりサードパーティに対応したログ収集として BlueMedora が提供する BindPlaneもある	VM インスタンスのアプリケーションログなど(詳細は右のリンク先)	デフォルトの Logging エージェントのログ	30日 (デフォルトバケット `_Default`)
セキュリティログ	Cloud Logging では、2 種類のセキュリティ関連ログが提供される・Cloud Audit Logs Cloud プロジェクト、フォルダ、組織ごとに監査ログで、Google Cloud リソースの管理上の変更とデータアクセスの監査証跡が保存される・アクセスの透明性ログ Google のスタッフが Google Cloud のコンテンツにアクセスしたときに行ったアクションのログを提供	・Cloud Audit Logs(監査ログ) - 管理アクティビティ監査ログ - データアクセス監査ログ - システムイベント監査ログ - ポリシー拒否監査ログ	監査ログ付きの Google サービスアクセスの透明性ログを持つ Google サービス	400日 (デフォルトバケット:`_Required`) 対象：管理アクティビティの監査ログ、システムイベントの監査ログ、アクセスの透明性ログ 30日(デフォルトバケット `_Default`) 対象：`_Required`対象以外のもの
ネットワークログ (一部はセキュリティログ/Cloud Audit Logs)	・ファイアウォールルールロギング - ファイアウォールルールのロギング機能を有効化することで取得可能 - TCP/UDP のみ取得可能で、他のプロトコルはサポートしていない・VPC フローログ - Andromeda の一部の機能.遅延やパフォーマンスの低下は発生しない。 - TCP、UDP、ICMP、GRE フローをサンプリングする - GKE のフローをログに記録するには、クラスタのノード内の可視化を有効にする必要がある・Cloud Router のログ - ルータのログを取得可能	ファイアウォールポリシーの allow/deny 結果 VPC 内通信のサンプリングされたフローログルータログ (ルータイベント、BGPイベント、ルートイベントログなど)	VPC の監査ロギング情報ファイアウォールルールロギングの概要 VPC フローログの概要 Cloud Router のログと指標の表示	30日 (デフォルトバケット `_Default`)※ログ取得を有効化した場合。デフォルト取得が無効 400日(ファイアウォールログの一部.`_Required`)
マルチクラウドとハイブリッドクラウドのログ	Cloud Logging では、Azure や AWSなど、他のクラウドから送信されるログを取り込むことができるオンプレミスとアプリのログもサポートしている	Azure, AWS から収集したログ	Blue Medora を使用したオンプレミスリソースのロギング	30日 (デフォルトバケット `_Default`)

概要図

下記は、全体的な関わりをまとめた図。

Cloud Console 上のメニューは下記で表示される (2021.06 時点)

Logging コンポーネント

下記の順番で記載する

Logging エージェント
Logs Explorer
Logs Dashboard
Logs Based Metrics
Logs Router
1. Log Sinks
Logs Storage
1. Log Bucket
2. Region

1. Logging エージェント

ドキュメントから抜粋。

Compute Engine インスタンス上で動作する。AWS EC2 インスタンスにも対応されている [サポートされる環境]
Logging エージェント google-fluentd は、fluentd ログデータコレクタに変更を加えたもの
デフォルトの構成では、Logging エージェントはデフォルトのログのリストにあるログを Cloud Logging にストリーミングする
複数の OS をサポートしている [サポートされているオペレーティングシステム]

Compute Engine の VM イメージには Logging エージェントが含まれていないので、下記コマンドでインストールする(Linuxの場合)
※詳細はドキュメント

Linuxの場合のLoggingエージェントインストール

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

1.1. GKE Logging エージェント

ドキュメントから抜粋

GKE 1.17 以降では、fluentbit ベースのエージェントを使用してログが収集される
デフォルトの動作を変更する場合は、カスタマイズした fluentbit エージェントを使用する

1.2. オンプレミス向け Logging エージェント

ドキュメントから抜粋

オンプレミスからログを Cloud Logging へ取り込むには 2つの方法がある

Blue Medora の BindPlane ツールを使用して、オンプレミスまたは他のクラウドソースからログを取り込む。
アプリから直接 Cloud Logging API を使用するか、カスタムエージェントを使用する。

1.2.1. BindPlane (Blue Medora)

Blue Medora のドキュメント Get Started with BindPlane Logs for Stackdriver を参照

1.2.2. fluent-plugin-google-cloud

カスタムエージェントである fluent-plugin-google-cloud について記載する

インストール

fluentdをインストールした後にfluent-plugin-google-cloudモジュールをインストールする

gem install fluent-plugin-google-cloud

設定

config に README にある match ディレクティブに下記を記載する

<match **>
  @type google_cloud
</match>

上記に構成オプションを追記することで、
プロジェクトや VM 名などを埋め込める

<match **>
  @type google_cloud
+ project_id PROJECT_ID
+ zone asia-northeast1
+ vm_id VM_ID
+ vm_name VM_NAME
</match>

エージェント認証はドキュメントを参照。(概要は下記)

サービスアカウントを作成 (ドキュメント)
サービスアカウントの秘密鍵のダウンロード・配置 (ドキュメント)
- /etc/google/auth/application_default_credentials.json に配置する

ただし、これが GCP 以外にどこまでサポートされているかまでは確認できてない。

2. Logs Explorer

ログデータを分析するためのインターフェース
ログの可視化と分析、クエリの作成と調整、などができる

詳細はドキュメントを参照

下記は Logs Explorer 表示例

使用方法はGoogle Cloud ドキュメント：ログエクスプローラの使用を参照。

3. Logs Dashboard

ログダッシュボードには、Google Cloud プロジェクト内で実行中のシステムの健全性の概要が表示される
ログダッシュボードは、ログデータを生成しているリソースに関する情報のみを提供される

詳細はドキュメントを参照。

下記は Logs Dashboard の画面表示例

4. Logs Based Metrics

ドキュメント：https://cloud.google.com/logging/docs/logs-based-metrics?hl=ja

ログベースメトリクスは、ログエントリによって指標(メトリクス)を生成する
- 例えば
  - 特定のメッセージを含むログエントリの数を記録
  - ログエントリで報告されたレイテンシ情報を抽出
Cloud Monitoring のグラフおよびアラートポリシーで、ログベースの指標を使用できる
単一の Google Cloud プロジェクトにのみ適用

ログベースの指標には次の 2 種類があります。

システム定義のログベースの指標
- Cloud Logging によって提供され、すべての Google Cloud プロジェクトで使用できます。
ユーザー定義のログベースの指標
- Google Cloud プロジェクトで特に関心のある対象を追跡するためにユーザーが作成した指標
- たとえば、特定のフィルタに一致するログエントリの数をカウントするログベースの指標を作成できます。

下記は Logs Based Metrics の画面表示例

5. Logs Router

ドキュメントを参照。

Cloud Logging は Cloud Logging API を介してログエントリを受信し、その過程でログエントリはログルーターを通過する
ログルーターのシンクでは、各ログエントリを既存の包含フィルタと除外フィルタと照合して、ログエントリを Cloud Logging バケットなど保存先に送信するか、Cloud Logging による取り込みを完全に除外するかを決定する。
シンクは、複数の宛先にログを転送するために使用できる

下記は Logs Router の画面表示例
デフォルトの状態で、_Defaultと_Required に Sinks 設定があることが見える

5.1. Log Sinks

ドキュメントを参照。

シンクは、ログエントリを保存先(下記画像の sink service 選択できる宛先) へ転送する

ログエントリが Cloud Logging に書き込まれないようにするためにも使用される
ログシンクでは、フィルタ式(下画像. _Default への設定)と宛先(上画像)を組み合わせられる
フィルタは、一致するログエントリをシンクさせるinclude in sinkと、除外する除外フィルタfilter out of sinkがある

6. Logs Storage

ドキュメントを参考に下記にまとめる

6.1. Log Bucket

ログバケットと呼ばれる、バケットを Google Project 内に作成して、ログデータを保存、整理する
名前が似ている Cloud Storage バケットとは異なるストレージエンティティになる

下記にバケットの種類別の内容を記載する。

bucket	内容	保持期間
_Required	次の種類のログを自動的に _Required バケットに転送する。管理アクティビティ監査ログ, システムイベント監査ログ, アクセスの透明性ログこのバケットの変更や削除はできない。_Required シンクを無効にすることはできない	400 日間保持します。この保持期間は変更できません
_Default	_Required バケットによって取り込まれなかったログエントリは、_Default シンクを無効にするか編集しない限り、_Default シンクによって _Default バケットに転送される _Default バケットは削除できない。	30 日間保持(カスタム保持で変更可能
ユーザー定義のログバケット	任意の Cloud プロジェクトでユーザー定義のログバケットを作成可能	カスタム保持を設定

6.2. Region

ログのリージョンはデフォルトglobalとなっている。
ログバケットは、現在(2021.06.20)下記のリージョンが選択可能。[ドキュメント]

大陸	地域
アジア	asia-east1 asia-northeast1 asia-northeast2 asia-northeast3 asia-south1 asia-southeast1
オーストラリア	australia-southeast1
ヨーロッパ	europe-north1 europe-west1 europe-west2 europe-west3 europe-west4 europe-west6
北アメリカ	northamerica-northeast1 us-central1 us-east1 us-east4 us-west1 us-west2 us-west3
南アメリカ	southamerica-east1

下記は Logs Storage の画面表示例
デフォルトの_Defaultと_Requiredが表示されるのを確認できる (Retention period : 保持期間, Region: デフォルトglobal)

設定

ログルータ・ストレージの設定やオンプレからのログ転送の設定テストを実施する (設定は Cloud は Terraform, VM は Ansible )

Log 保存先の作成、保存設定
1. 日本リージョンに保存する Log Bucket を新たに作成し、Log Sink する (短期用 14日)
2. 日本リージョンに保存する Log Storage を新たに作成し、Log Sink する (長期保存用 180日)
オンプレ VM に fluentd から Logging へ取り込み
1. オンプレ VM への td-agent インストール
2. plugin のインストール
3. 設定
4. ログ表示確認

1. Log 保存先の作成、保存設定

デフォルト以外のログ保存先を Log Bucket と Log Storage に作成して転送設定(Log Router/Sink) を実施する

1.1. 日本リージョンに保存する Log Bucket を新たに作成し、Log Sink する (短期用 14日)

Log Bukect を作成して転送設定する
下記、terraform でやる場合の記載例 (google_project.service1 は設定するプロジェクト. filterは _Default から参照)

# log 短期閲覧用バケット
resource "google_logging_project_bucket_config" "service1_logging_log_bucket" {
  project        = google_project.service1.name
  location       = "asia-northeast1"
  retention_days = 14
  bucket_id      = "custom-bucket"
}

# audit 系のデフォルト長期保存系以外を短期保存用バケットに入れる
resource "google_logging_project_sink" "service1-default-sink" {
  project     = google_project.service1.name
  name        = join("-", [var.service1_pj.service_name, "default-sink"])
  # name        = "_Default"
  description = "default logging"
  destination = "logging.googleapis.com/${google_logging_project_bucket_config.service1_logging_log_bucket.id}"
  # same _Default
  filter      = "NOT LOG_ID(\"cloudaudit.googleapis.com/activity\") AND NOT LOG_ID(\"externalaudit.googleapis.com/activity\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"externalaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/access_transparency\") AND NOT LOG_ID(\"externalaudit.googleapis.com/access_transparency\")"
  unique_writer_identity = true
}

1.2. 日本リージョンに保存する Log Storage を新たに作成し、Log Sink する (長期保存用 180日)

Log Storage を作成して転送設定する
下記、terraform でやる場合の記載例 (google_project.service1 は設定するプロジェクト. filterは _Default から参照)


# log 長期保存用バケット 180 日保存, NEARLINE
resource "google_storage_bucket" "service1_gs_log_bueckt" {
  project       = google_project.service1.name
  name          = join("-", [var.service1_pj.service_name, "logging-bucket"])
  storage_class = "NEARLINE"
  location      = "asia-northeast1"
  force_destroy = true

  lifecycle_rule {
    condition {
      age     = "180"
    }
    action {
      type = "Delete"
    }
  }
}

# audit 系のデフォルト長期保存系以外を長期保存用バケットに入れる
resource "google_logging_project_sink" "service1-default-gcs-sink" {
  project     = google_project.service1.name
  name        = join("-", [var.service1_pj.service_name, "default-gcs-sink"])
  description = "default logging to gcs bucket"
  destination = "storage.googleapis.com/${google_storage_bucket.service1_gs_log_bueckt.name}"
  # same _Default
  filter      = "NOT LOG_ID(\"cloudaudit.googleapis.com/activity\") AND NOT LOG_ID(\"externalaudit.googleapis.com/activity\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"externalaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/access_transparency\") AND NOT LOG_ID(\"externalaudit.googleapis.com/access_transparency\")"
  unique_writer_identity = true
}

resource "google_project_iam_binding" "service1_log-writer" {
  project = google_project.service1.id
  role    = "roles/storage.objectCreator"

  members = [
    google_logging_project_sink.service1-default-gcs-sink.writer_identity,
  ]
}

1.3. 確認

下記でログルーターが設定できていることが確認できる (下二行)

下記でログストレージ設定ができいることも確認できる (下1行)

2. オンプレ VM に fluentd から Logging へ取り込み

オンプレミスの VM に td-agent (fluentd) を install して、plugin (fluent-plugin-google-cloud) を導入、
認証のためのサービスアカウント・クレデンシャルを作成して設定する

インストール

下記 Ansible Role 例。
td-agent(fluentd) および plugin のインストールを実施する。
※td-agentの実行ユーザを root に変更している。必要に応じて実施する(Groupも)

tasks/main.yml

---
- name: Add td-agent repository
  yum_repository:
    name: treasuredata
    description: TreasureData
    baseurl: http://packages.treasuredata.com/4/redhat/$releasever/$basearch
    gpgkey: https://packages.treasuredata.com/GPG-KEY-td-agent
    gpgcheck: yes
  become: true
  when:
    - ansible_distribution == "CentOS"

- name: install gem, ruby-devel
  yum:
    name: "{{ packages }}"
    state: latest
  vars:
    packages:
      - gem
      - ruby-devel
      - gcc
      - gcc-c++
      - rpm-build
      - make
      - td-agent
  become: true
  when:
    - ansible_distribution == "CentOS"
    - ansible_distribution_major_version == "7"

- name: install gem, ruby-devel
  dnf:
    name: "{{ packages }}"
    state: latest
  vars:
    packages:
      - gem
      - ruby-devel
      - gcc
      - gcc-c++
      - rpm-build
      - make
      - td-agent
  become: true
  when:
    - ansible_distribution == "CentOS"
    - ansible_distribution_major_version == "8"

- name: enabled and start td-agent
  systemd:
    name: td-agent
    state: started
    enabled: yes
  become: true
  when:
   - ansible_distribution == "CentOS"

- name: install fluentd
  gem:
    name: fluentd
    state: present
    user_install: no
  become: true

- name: install fluent-plugin-google-cloud
  gem:
    executable: /usr/sbin/td-agent-gem
    name: fluent-plugin-google-cloud
    state: present
    user_install: no
  become: true

- name: systemd file 
  lineinfile:
    path: /lib/systemd/system/td-agent.service
    regexp: '^User=td-agent'
    line: User=root
  become: true
  when:
    - ansible_distribution == "CentOS"
  notify: tdagent reload

ログ用サービスアカウント作成

ログを書き込むためにサービスアカウントを作成し、権限を付与する
下記、terraform での作成例
※クレデンシャルキーをダウンロードするための output 例も記載

# loggig 書き込み用 ServiceAccount for Onprem VM
resource "google_service_account" "service1_logging_onpremvm_sa_account" {
  account_id   = join("-", [var.service1_pj.service_name, "vm-onprem-logging-sa"])
  display_name = "${google_project.service1.name} vm onprem logging serviceAccount"
  project      = google_project.service1.name
}

# 必要な Role の付与 (https://cloud.google.com/logging/docs/agent/logging/authorization#create-service-account)
resource "google_project_iam_binding" "service1_logging_writer" {
  project = google_project.service1.id
  for_each = toset([
    "roles/logging.logWriter",
    "roles/monitoring.metricWriter",
  ])

  role = each.value

  members = [
    "serviceAccount:${google_service_account.service1_logging_onpremvm_sa_account.email}"
  ]
}

# オンプレ VM への配置用のクレデンシャルキーのダウンロード
output "serviceAccount_for_fluentd_onprem_vm" {
  value       = join("", ["gcloud --project ${google_project.service1.name} iam service-accounts keys create service1_vmonprem_logging_serviceacoount_credential.json --iam-account ", google_service_account.service1_logging_onpremvm_sa_account.email])
  description = "Service Account for OnPrem VM Fluentd write logging"
}

設定

クレデンシャルキーをダウンロードして下記へ配置する

mkdir /etc/google/
mkdir /etc/google/auth/
cp [ダウンロードしたクレデンシャルファイル] /etc/google/auth/application_default_credentials.json
chown td-agent:td-agent /etc/google/auth/application_default_credentials.json

td-agent.conf へ google_cloud 向け設定を実施する

/etc/td-agent/td-agent.conf(へ追記)

<match **>
  @type google_cloud
  project_id PROJECT_ID
  zone asia-northeast1
  vm_id VM_ID
  vm_name VM_NAME
</match>

ここでは下記で設定してテストする (/var/log/secure のログを飛ばせるか確認する.)

テスト設定/etc/td-agent/td-agent.conf(へ追記)

<match **>
  @type google_cloud
  project_id suzuyu-service1-dev
  zone asia-northeast1
  vm_id onprem_ansible01
  vm_name onprem_ansible01
</match>

<source>
  type tail
  path /var/log/secure
  pos_file /var/log/td-agent/secure.pos
  tag log_secure
  format none
</source>

td-agent をリロードする

systemctl reload td-agent

下記のようなログ (Successfully) が出れば OK.

# tail -f /var/log/td-agent/td-agent.log 
~中略~
2021-07-18 19:00:35 +0900 [info]: #0 Successfully sent to Stackdriver Logging API.

下記、SSH ログインや su を入力して、ログを飛ばし、
ログエクスプローラからログが出力できていることを確認できる (下記確認したスクリーンショット)

オペレーションロギング -> ログエクスプローラ

注記

時刻差分が大きいと Stackdriver Logging API へ認証できないため、ntp同期をしておく必要がある
(エラー例： Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim.)

おわりに

Cloud Logging を調べて概要をまとめてみた
Logging の保存先やオンプレミスからの設定テストも一応動作確認ができた
保存設定やエクスプローラ、メトリクスなど、まだまだ機能があるので今後試していきたい

追記(2021.08.09)

Fluentd ではなく、Fluent Bit を利用する方法を別記事で記載したので追記する