はじめに
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
- Log Sinks
- Logs Storage
- Log Bucket
- Region
1. Logging エージェント
ドキュメントから抜粋。
Compute Engine インスタンス上で動作する。AWS EC2 インスタンスにも対応されている [サポートされる環境]
Logging エージェント google-fluentd は、fluentd ログデータ コレクタに変更を加えたもの
デフォルトの構成では、Logging エージェントはデフォルトのログのリストにあるログを Cloud Logging にストリーミングする
複数の OS をサポートしている [サポートされているオペレーティング システム]
Compute Engine の VM イメージには Logging エージェントが含まれていないので、下記コマンドでインストールする(Linuxの場合)
※詳細はドキュメント
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 保存先の作成、保存設定
- 日本リージョンに保存する Log Bucket を新たに作成し、Log Sink する (短期用 14日)
- 日本リージョンに保存する Log Storage を新たに作成し、Log Sink する (長期保存用 180日)
- オンプレ VM に fluentd から Logging へ取り込み
- オンプレ VM への td-agent インストール
- plugin のインストール
- 設定
- ログ表示確認
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も)
---
- 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 向け設定を実施する
<match **>
@type google_cloud
project_id PROJECT_ID
zone asia-northeast1
vm_id VM_ID
vm_name VM_NAME
</match>
ここでは下記で設定してテストする (/var/log/secure のログを飛ばせるか確認する.)
<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 を利用する方法を別記事で記載したので追記する
参考