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

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

## Cloud Logging とは

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

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

### ログの種類

[ドキュメント](https://cloud.google.com/logging/docs/view/available-logs?hl=ja)とその先のリンク先を参考に表にまとめてみた

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



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


![スクリーンショット 2021-06-20 14.36.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/9c0f62e2-b065-944b-19ff-92c491ebc4fb.png)

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

![スクリーンショット 2021-06-20 21.34.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/adcbeb96-008b-e4f8-bd67-2e15413b91d8.png)

### Logging コンポーネント

下記の順番で記載する

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

### 1. Logging エージェント
[ドキュメント](https://cloud.google.com/logging/docs/agent/logging?hl=ja)から抜粋。

Compute Engine インスタンス上で動作する。AWS EC2 インスタンスにも対応されている [[サポートされる環境](https://cloud.google.com/logging/docs/agent/logging?hl=ja#supported_vms)]
Logging エージェント `google-fluentd` は、fluentd ログデータ コレクタに変更を加えたもの
デフォルトの構成では、Logging エージェントは[デフォルトのログのリスト](https://cloud.google.com/logging/docs/agent/default-logs?hl=ja)にあるログを Cloud Logging にストリーミングする
複数の OS をサポートしている [[サポートされているオペレーティング システム](https://cloud.google.com/logging/docs/agent/logging?hl=ja#supported_operating_systems)]

Compute Engine の VM イメージには Logging エージェントが含まれていないので、下記コマンドでインストールする(Linuxの場合)
※詳細は[ドキュメント](https://cloud.google.com/logging/docs/agent/logging/installation?hl=ja)

```sh: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 エージェント
[ドキュメント](https://cloud.google.com/stackdriver/docs/solutions/gke/managing-logs?hl=ja#logging_defaults)から抜粋

GKE 1.17 以降では、**fluentbit** ベースのエージェントを使用してログが収集される
デフォルトの動作を変更する場合は、[カスタマイズした fluentbit エージェント](https://cloud.google.com/community/tutorials/kubernetes-engine-customize-fluentbit?hl=ja)を使用する

#### 1.2. オンプレミス向け Logging エージェント
[ドキュメント](https://cloud.google.com/solutions/logging-on-premises-resources-with-blue-medora?hl=ja)から抜粋

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

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

##### 1.2.1. BindPlane (Blue Medora)
Blue Medora のドキュメント [Get Started with BindPlane Logs for Stackdriver](https://bluemedora.com/get-started-with-bindplane-logs-for-stackdriver/) を参照

##### 1.2.2. fluent-plugin-google-cloud
カスタムエージェントである [fluent-plugin-google-cloud](https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud) について記載する

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

```sh
gem install fluent-plugin-google-cloud
```

###### 設定

config に [README](https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud/blob/master/README.rdoc#configuration-) にある match ディレクティブに下記を記載する

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

上記に [構成オプション](https://cloud.google.com/logging/docs/agent/logging/configuration#project-_and_monitored_resource-related_configuration_options) を追記することで、
プロジェクトや VM 名などを埋め込める

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

エージェント認証は[ドキュメント](https://cloud.google.com/logging/docs/agent/logging/authorization)を参照。(概要は下記)

- サービスアカウントを作成 ([ドキュメント](https://cloud.google.com/logging/docs/agent/logging/authorization#create-service-account))
- サービスアカウントの秘密鍵のダウンロード・配置 ([ドキュメント](https://cloud.google.com/logging/docs/agent/logging/authorization#copy-private-key))
    - `/etc/google/auth/application_default_credentials.json` に配置する

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

### 2. Logs Explorer

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

詳細は[ドキュメント](https://cloud.google.com/logging/docs/view/logs-viewer-preview?hl=ja)を参照

下記は Logs Explorer 表示例

![スクリーンショット 2021-06-20 21.52.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/bdc5602d-bf73-e357-37fe-3bcd083f550c.png)

使用方法は[Google Cloud ドキュメント：ログ エクスプローラの使用](https://cloud.google.com/logging/docs/view/logs-viewer-interface)を参照。

### 3. Logs Dashboard

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

詳細は[ドキュメント](https://cloud.google.com/logging/docs/view/dashboard?hl=ja)を参照。

下記は Logs Dashboard の画面表示例

![スクリーンショット 2021-06-20 22.16.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/4a248869-a5aa-b503-a79a-00936c19db72.png)


### 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 の画面表示例

![スクリーンショット 2021-06-20 21.58.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/e0155c75-a46b-5ad2-fc48-eb519d6934cd.png)


### 5. Logs Router

[ドキュメント](https://cloud.google.com/logging/docs/routing/overview#log-router)を参照。

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

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

![スクリーンショット 2021-06-20 22.18.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/9e6ccda5-67ed-4329-6481-3e6fd1dcbb72.png)


#### 5.1. Log Sinks

[ドキュメント](https://cloud.google.com/logging/docs/routing/overview#sinks)を参照。

シンクは、ログエントリを保存先(下記画像の sink service [選択できる宛先](https://cloud.google.com/logging/docs/routing/overview#destinations)) へ転送する

![スクリーンショット 2021-06-20 22.23.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/269c4949-9722-795f-2b32-d52a5a4ab966.png)

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

![スクリーンショット 2021-06-20 22.27.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/7de81132-54f7-2064-6921-9d781af54810.png)


### 6. Logs Storage
[ドキュメント](https://cloud.google.com/logging/docs/storage)を参考に下記にまとめる

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

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

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

#### 6.2. Region
ログのリージョンはデフォルト`global`となっている。
ログバケットは、現在(2021.06.20)下記のリージョンが選択可能。[[ドキュメント](https://cloud.google.com/logging/docs/regionalized-logs?hl=ja)]

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

下記は Logs Storage の画面表示例
デフォルトの`_Default`と`_Required`が表示されるのを確認できる (Retention period : 保持期間, Region: デフォルト`global`)
![スクリーンショット 2021-06-20 22.33.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/dd4314b6-a87b-3a8f-c13c-d55a5eea665b.png)


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

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

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

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

#### 1.1. 日本リージョンに保存する Log Bucket を新たに作成し、Log Sink する (短期用 14日)
Log Bukect を作成して転送設定する 
下記、terraform でやる場合の記載例 (google_project.service1 は設定するプロジェクト. filterは _Default から参照)

```tf
# 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 から参照)


```tf

# 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. 確認

下記でログルーターが設定できていることが確認できる (下二行)
![スクリーンショット 2021-07-18 19.30.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/38b2b2bf-868d-523a-373a-0980bb922a29.png)

下記でログストレージ設定ができいることも確認できる (下1行)
![スクリーンショット 2021-07-18 19.32.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/696eb934-e455-ca3a-551b-5d36d93509b9.png)


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

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

```yaml: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 例も記載

```tf
# 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"
}

```

#### 設定

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

```sh
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 向け設定を実施する

```conf:/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 のログを飛ばせるか確認する.)

```conf:テスト設定/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` をリロードする

```sh
systemctl reload td-agent
```

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

```sh
# 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 を入力して、ログを飛ばし、
ログエクスプローラからログが出力できていることを確認できる (下記確認したスクリーンショット)

**オペレーションロギング -> ログ エクスプローラ**
![スクリーンショット 2021-07-18 21.44.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/326183/59d0e6d7-2817-9a80-a409-c01dc1f3cedc.png)



###### 注記
時刻差分が大きいと 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 を利用する方法を別記事で記載したので追記する

https://qiita.com/suzuyui/items/2217a357099130fc7236

## 参考

https://cloud.google.com/logging?hl=ja

https://cloud.google.com/logging/docs/agent/logging/configuration?hl=ja#default_configuration

https://cloud.google.com/logging/docs/view/available-logs?hl=ja

https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud