GCP for Stackdriver 設定マニュアル

## 概要
Stackdriverを使用してGCE(Google Compute Engine)へ基本的な監視設定を行う手順を説明していきます。
[Stackdriverの公式ドキュメント](https://cloud.google.com/stackdriver/docs/)がかなり難解なため、Stackdriverの前提知識が薄い方も理解できる内容で記載していきたいと思います。


なお、本記事はDebian系 or RHEL系のLinuxが稼働しているGCEを想定して記載しております。

今回は基本的な監視設定の解説となりますが、Stackdriverはより応用的な活用をすることでクラウドネイティブな監視ツールとしての威力を発揮します。

## 目次
- <b>1. Stackdriverとは</b>
- <b>2. Stackdriverの監視方針</b>
- <b>3. Stackdriverの起動方法</b>
    - 3-1. Stackdriver Monitoringの起動方法
    - 3-2. Stackdriver Loggingの起動方法
- <b>4. Stackdriver Agentの利用</b>
    - <b>4-1. Stackdriver Monitoring Agent</b>
        - 4-1-1. インストール方法
        - 4-1-2. Stackdriver Monitoring Agentの停止方法
    - <b>4-2. Stackdriver Logging Agent</b>
        - 4-2-1. インストール方法(構造化ロギングオフ)
        - 4-2-2. インストール方法(構造化ロギングオン)
        - 4-2-3. Stackdriver Logging Agentの停止方法
- <b>5. Stackdriver Monitoringのアラート設定</b>
    - <b>5-1. GCEのCPU使用率(user)監視</b>
        - 5-1-1. Conditionに設定するパラメータ
        - 5-1-2. Conditionの各パラメータの説明
        - 5-1-3. 通知先の設定
        - 5−1−4. ポリシー本文の設定
        - 5-1-5. ポリシー名の設定
        - 5-1-6. 発報テスト
    - <b>5-2. URLへのUptimeCheck</b>
        - 5-2-1. Uptime Checkに設定するパラメータ
        - 5-2-2. Uptime Checkの各パラメータの説明
        - 5-2-3. Conditionに設定するパラメータ
    - <b>5-3. GCEのプロセス稼働数監視</b>
        - 5-3-1. Conditionに設定するパラメータ
        - 5-3-2. Conditionの各パラメータの説明
        - 5-3-3. 発報テスト
- <b>6. Stackdriver Loggingのアラート設定</b>
    - <b>6-1. ログベースの指標標の作成</b>
        - 6-1-1. ユーザー定義（ログベース）指標に設定するパラメータ
        - 6-1-2. ユーザー定義（ログベース）指標に設定するパラメータの説明
        - 6-1-3. 作成したユーザー定義（ログベース）指標のフィルターを編集
    - <b>6-2. ユーザー定義（ログベース）指標をアラートとして設定</b>
        - 6-2-1. Conditionに設定するパラメータ
    - <b>6-3. 発報テスト</b>
- <b>7. アラートの無効化</b>

## 1. Stackdriverとは
Googleが2014年に買収したクラウド監視サービス。
Googleによる買収前はAWSを主としてモニタリング監視サービスを提供していたが、
Googleのサポートにより、AWSのモニタリング監視を継続しつつ、GCPのモニタリング監視も可能となった。

## 2. Stackdriverの監視方針
<b>Stackdriver Monitoring</b>ではインスタンスのリソース使用率監視やUptimeCheck(URLへの死活監視や、GCEへのポート死活監視)、GCE上のプロセス稼働数などで監視を実現します。

<b>Stackdriver Logging</b>ではGCP/OS/MWのログを監視し、特定の文言でフィルターをかけた指標とよばれるメトリックを作成します。そのメトリックをStackdriver Monitoringでアラート化し監視を実現します。

## 3. Stackdriverの起動方法
### 3-1. Stackdriver Monitoringの起動方法
GCPのコンソール画面へ移動し、メニューからモニタリングをクリックする。
![monitoring.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/fe01740b-8c6e-d8dc-487e-d3a3d37408cd.jpeg)
Stackdriver Monitoringのコンソール画面が表示される。
![Dashboard_-_Monitoring_Overview.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/941d7a9f-fe4b-c99f-887e-463a2178fe9c.jpeg)

### 3-2. Stackdriver Loggingの起動方法
GCPのコンソール画面へ移動し、メニューからLogging⇛ログビューアをクリックする。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/2451bc20-f603-1f7c-7875-ded72eb1d4f7.jpeg)
Stackdriver Loggingが収集したログのエントリが表示される。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform_と_新構成本番環境_-_【トップゲート】ZIGExN様_共有_-_Google_ドライブ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/6b25b4a3-8424-5644-7757-e3736f7ac9bc.jpeg)

## 4. Stackdriver Agentの利用
Stackdriver Agentにはそれぞれ、
<b>Stackdriver Monitoring Agent</b>
<b>Stackdriver Logging Agent</b>
がある。Agentをインストールすることによって詳細な監視設定(メトリックの指定)が可能となる。
### 4-1. Stackdriver Monitoring Agent
collectd ベースのデーモン。プロセス名は<b>stackdriver-collectd</b>。
インストールすることにより、GCEのリソース使用率をより詳細に取得することができる。
さらにサードパーティ製アプリケーション(Apache web serverやnginx,memcachedやMySQLなど)のモニタリングが可能となる。

サードパーティ製アプリケーションのモニタリングをするには、各アプリケーションのプラグインのインストールが必要となる。
https://cloud.google.com/monitoring/agent/plugins/?hl=ja

#### 4-1-1. インストール方法
```bash
curl -sSO https://dl.google.com/cloudagents/install-monitoring-agent.sh
sudo bash install-monitoring-agent.sh

#必要に応じて
sudo rm install-monitoring-agent.sh
```

#### 4-1-2. Stackdriver Monitoring Agentの停止方法
```bash
#プロセスを停止
systemctl stop stackdriver-agent

#自動起動を無効化
/sbin/chkconfig stackdriver-agent off
```

### 4-2. Stackdriver Logging Agent
fluentd ベースのデーモン。プロセス名は<b>google-fluentd</b>。
インストールすることにより、syslogや各種MWログ(apache,nginx,jenkins,mongodb,solrなど)を収集可能となる。

[デフォルトで対象となるミドルウェア](https://cloud.google.com/logging/docs/agent/default-logs?hl=ja#custom_types)の場合、ログの出力場所を変更していなければ自動でログが取得される。

またStackdriver Loggingには構造化ロギングと呼ばれるものが存在し、
通常はログの出力はtextPayloadで行われますが、構造化ロギングを有効にするとjsonPayloadでログが格納されます。
どのような利点があるかというと、例えばBigqueryのテーブルへログを格納する際にカラムがより詳細に作成されるため、SQL文によるログの操作がより柔軟になります。


#### 4-2-1. インストール方法(構造化ロギングオフ)
```bash
curl -sSO https://dl.google.com/cloudagents/install-logging-agent.sh
sudo bash install-logging-agent.sh

#必要に応じて
sudo rm install-logging-agent.sh
````

#### 4-2-2. インストール方法(構造化ロギングオン)
```bash
curl -sSO "https://dl.google.com/cloudagents/install-logging-agent.sh"
sudo bash install-logging-agent.sh --structured

#必要に応じて
sudo rm install-logging-agent.sh
````

#### 4-2-3. Stackdriver Loggig Agentの停止方法
```bash
#プロセスを停止
systemctl stop google-fluentd

#自動起動を無効化
/sbin/chkconfig google-fluentd off
```

## 5. Stackdriver Monitoringのアラート設定
今回は以下のアラートを設定していきます。

<b>GCEのCPU使用率(user)監視
URLへのUptimeCheck
GCEのプロセス稼働数監視</b>

### 5-1. GCEのCPU使用率(user)監視
Stackdriver Monitoringコンソールの左メニューから<b>alerting</b>を選択しさらに<b>Create a Policy</b>をクリックします。
![alert.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/ff9a970c-e7b8-b298-982a-7fbafcc25cd2.jpeg)
ポリシー作成画面へと遷移します。
![Create_Policy.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/9997941c-b955-7dce-0962-b2ca1a12a804.jpeg)
各項目の対応は画像内の赤字の通りです。

Stackdriver Monitoringのアラート設定単位は<b>Policy</b>です。Policyは各ワークスペースに最大で 500 個作成できます。
Policyの中に複数の<b>Conditions(条件/アラート)</b>を設定します。
１つのPolicy内にConditionsは最大で6個登録できます。

Policyがインシデントと判断される条件の指定は以下となります。

OR: 
=> いずれかの条件が満たされている。

AND: 
=> 各条件が 1 つ以上のリソースによって違反されている。異なるリソースが各条件にそれぞれ違反している場合も含む。

AND_WITH_RESOURCES: 
=> すべての条件が同じリソースによって違反されている（このオプションは、Monitoring API を使用して作成する条件でのみ使用できます）。もちろん1つのPolicy内に1つのConditionsのみ設定することも可能です。

では<b>Add Conditions</b>をクリックし、実際にアラートを設定して行きましょう。

Add ConditionsをクリックするとCondtionの作成画面へと遷移します。
![condtion.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/63599fa2-ac27-1956-7978-f9e84f92cedf.jpeg)
各項目の対応は画像内の赤字の通りです。

ここでは以下をパラメータとして設定します。

#### 5-1-1. Conditionに設定するパラメータ

<b>Conditon名：</b>
GCE VM Instance - CPU utilization for user above 80%

<h3>■Target</h3>
<b>Find resource type and metric：</b>
<b>Resource type：</b>
GCE VM Instance
<b>Metric：</b>
CPU utilization
※CPU utilizationは2つあるので、Metricが<b>agent.googleapis.com/cpu/utilization</b>のものを選択

<b>Filter：</b>
cpu_state = "user"

<b>Group By：</b>
user_labels.name

<b>Aggregator：</b>
mean

<b>Advanced Aggregation：</b>
<b>Aligner：</b>
mean
<b>Alignment Period：</b>
1m
<b>Secondary Aggregator：</b>none
<b>Legend Template：</b>

<h3>■Configuration</h3>
<b>Condition triggers if：</b>
Any time series violates
<b>Condition：</b>
is above
<b>Threshold：</b>80(%)
<b>For：</b>1minute

![スクリーンショット 2019-07-10 14.57.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/0159fc2c-3502-7fa4-deec-8ac97f18d340.png)
![スクリーンショット 2019-07-10 14.58.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/978a229b-2271-af0c-3b81-66635aef4c96.png)

ここまで完了したら<b>save</b>をクリックし保存する。


#### 5-1-2. Conditionの各パラメータの説明
<h3>■Target</h3>
<b>Find resource type and metric：</b>
<b>Resource type：</b> Metricの大まかな分類(GCE_VM InstanceやBigquery Datasetといった粒度)
<b>Metric：</b>実際にアラート設定する項目(CPU utilizationなど)

<b>Filter：</b>
Metricを適用させる対象、何も設定しないと全インスタンスが対象となる。
GCEの場合はネットワークタグやインスタンス名単位でフィルターが可能
Filterは複数設定することが可能で複数設定した場合はAND条件となる。

[公式ドキュメント](https://cloud.google.com/monitoring/alerts/target-metric-selector#filter-option)

<b>Group By：</b>
SQL文のgroupby句と考え方は一緒。
プロジェクトIDやゾーン、インスタンス名などを指定可能。

[公式ドキュメント](https://cloud.google.com/monitoring/alerts/target-metric-selector#groupby-option)

<b>Aggregator：</b>
値の集計方法。minやmaxなどはそのままの通り。
通常の監視ツールの概念と全く違うものは```**th percentile```のもの。

これは値が100個あるとして、小さい順に並べ替える。
99thの場合は下から99番目に小さいの値を採用するというパラメータ。
50thの場合は50番目に小さい値を採用する。

**th percentileの使い分けとしては
99thの場合、外れ値を除外しつつ集計した中で最大の値を取得したい場合に有効となる。
95thの場合、外れ値が多数ある場合に有効。
50thの場合、大体の平均を取得したい場合に有効。
5thも存在するが、個人的な主観として殆ど使用しないと思われる。

ここの値の指定はユーザーが入力できるようになると柔軟性も高まる。今後のアップデートに期待。

[公式ドキュメント](https://cloud.google.com/monitoring/alerts/target-metric-selector#aggregation-option)

<h4>Advanced Aggregation</h4>
<b>Aligner：</b>
AlignerはAggregatorで取得した値を、指定した時間と指定した集計方法で再集計するパラメータ。
Alignerの詳細は[こちらの記事](https://qiita.com/taisho6339/items/e491216d549e84dd7322#align)で詳しく説明されております。

[公式ドキュメント](https://cloud.google.com/monitoring/alerts/target-metric-selector#alignment)
<b>Alignment Period：</b>
値を収集する時間間隔(ポーリング間隔)。分単位で指定。
<b>Secondary Aggregator：</b>
複数の時系列で集計が表されている場合に時系列をさらに集計する。
<b>Legend Template：</b>=> グラフの時系列の説明をカスタマイズ

<h3>■Configuration</h3>
<b>Condition triggers if：</b>
メトリクスの名前, メトリクスのラベルそれぞれの値, Monitored Resourceの３つでグルーピングした一意の値でアラートのトリガーとなる条件を指定

Any time series violates 
=> （一つでも）測定値が閾値を超えた場合に 

Percent of time series violates 
=> 測定値が指定の閾値（％）を超えたら 

Number of time series violates 
=> 測定値が指定の閾値の回数を超えたら 

All time series violate 
=> （全ての）測定値が指定の閾値を超えたら 

<b>Condition：</b>
Thresholdの値がどのように変動したらトリガーとなるのかを指定

CPU(user)の使用率が80%以上の場合はThresholdが80%でConditionはIs aboveを設定

Is above
=> 閾値を上回ったら

Is below
=> 閾値を下回ったら

Increases by
=> (前回取得した値から)閾値分増加したら

Decreases by
=> (前回取得した値から)閾値分減少したら

Is absent
=> 値が取得できない場合

<b>Threshold：</b>閾値として設定する値。
<b>For：</b>閾値としてThresholdの値が継続する時間。most recent valueの場合はThresholdの値となった瞬間にインシデントと判断されます。
1minuteの場合は、Thresholdの値が1分間継続した場合にインシデントと判断。

#### 5-1-3. 通知先の設定
![通知.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/6a359d45-4b1a-a501-fa93-eca87e0b528f.png)

アラートの通知先にはEmail, Slack, Webhookなどを設定可能。
詳細な設定方法は[公式ドキュメント](https://cloud.google.com/monitoring/support/notification-options)を参照。

今回は通知先をEmailで設定していきます。
Notification Channel Typeをクリックし<b>Email</b>を選択。
![Create_Policy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/6a40e042-8cfb-4c14-1803-b0f573ccf756.png)

Emailアドレスの入力欄が表示されるので、通知先として設定したEmailアドレスを入力し、<b>Add Norification Channel</b>をクリックし反映させる。
![Create_Policy2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/e054d454-183f-d236-0b58-320efa473380.png)

#### 5−1−4. ポリシー本文の設定
![docu.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/39f8a826-2a72-5929-9136-cc77955f5074.png)


アラートメール(メッセージ)内の<b>Policy documentation</b>に任意の文言を設定可能。
![_ALERT__GCE_VM_Instance_-_solr-024012_-_CPU_load_Average__1m__150__on_kuruma-0623_GCE_VM_Instance_-_kengo_makita_topgate_co_jp_-_株式会社トップゲート_メール.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/b3ccf80a-9d10-7b3b-aef3-973b8b7badfc.png)

基本的にどのサーバからどのような事象が発生したのか、が理解できる内容を記載。
ここには変数を設定することも可能で、${policy.name}といった形式で記載する。

どの変数が対応しているかは[公式ドキュメント](https://cloud.google.com/monitoring/alerts/doc-variables#doc-vars)を参照。

今回は<b>host1のCPU使用率が80%を超過しました。</b>を設定する。
![スクリーンショット 2019-07-12 10.25.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/d3101582-5176-928a-c643-9cd80638dbde.png)


#### 5-1-5. ポリシー名の設定
![name.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/21228faa-f3fd-b728-e308-2667e8fd3c85.png)

Policy名はアラート数など状況に応じて命名規則を定めるのがよいです。
今回はConditionと同じ名前とします。
![スクリーンショット 2019-07-10 16.24.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/2112628d-4c01-0291-757c-34a90b34a29d.png)

ここまで設定したら、<b>save</b>をクリックしPolicyを保存します。
![Edit_Policy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/a40baa09-e74b-4f54-c00c-df1ca75b04be.png)

Policies一覧に追加されます。これで設定完了となります。
![いちらん.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/bd740bb7-eabf-006d-27d3-a5a0d8517350.png)

#### 5-1-6. 発報テスト
実際にアラート対象となるGCEにsshログインし、CPU(user)負荷をあげてみましょう。

```bash
sudo yum install -y stress
stress -c 1 -q &

#停止方法
jobs
fg #stressコマンドのjob番号
Ctrl + C キーを入力
```

![mail.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/bf35ff77-bad4-f6c1-09d2-c239604ffc04.png)
設定した内容でアラートとなっていることが確認できる。


### 5-2. URLへのUptimeCheck
ここではPolicy内の説明と発報テストは割愛し、URLへのUptimeCheckのConditionの説明を行います。

UptimeCheckは先にUptimeCheckの設定内容をMetric化し、そのMetricをCondition内で指定する流れとなります。

<b>Uptime Checks</b> => <b>Uptime Checks Overview</b>をクリック。
遷移先の画面の右上、<b>Add Uptime Check</b>をクリック。
![uptime.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/3a3bffb3-5fd6-a99a-1f7f-63a7ec2de64b.png)

Uptime Checkの作成画面が表示される。
![スクリーンショット 2019-07-10 17.05.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/39994eba-a186-f49a-ede9-72c00e1c270a.png)


#### 5-2-1. Uptime Checkに設定するパラメータ
※今回は弊社HPの https://www.topgate.co.jp/gcp/ に対してUptime Checkを行います。

<b>Title：</b>uptime check - www.topgate.co.jp

<b>Check Type：</b>HTTPS

<b>Resource Type：</b>URL

<b>Hostname：</b>www.topgate.co.jp

<b>Path：</b>/gcp

<b>Check every：</b>1 minute

![スクリーンショット 2019-07-10 17.21.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/e610a6fb-efa3-7957-c82f-cc8628b9c18d.png)

#### 5-2-2. Uptime Checkの各パラメータの説明
[公式ドキュメント](https://cloud.google.com/monitoring/alerts/uptime-checks?hl=ja)に詳細な説明の記載があります。

#### 5-2-3. Conditionに設定するパラメータ
<b>UPTIME CHECK</b>タブを選択
![Create_Policy3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/c03f93ae-d289-e1a8-5126-a7825098c591.png)

<b>Condition名：</b>uptime check - www.topgate.co.jp

<h3>■Target</h3>
<b>Metric：check passed</b>
<b>Resource Type：</b>Uptime Monitoring Url
<b>Uptime check id：</b>uptime check - www.topgate.co.jp

<h3>■Configuration</h3>
<b>Condition triggers if：</b>Any time series violates
<b>For：</b>1 minute

![スクリーンショット 2019-07-10 18.17.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/a5e9a37f-7328-aa89-6e13-a1af2877a061.png)

### 5-3. GCEのプロセス稼働数監視
ここではPolicy内の説明は割愛し、Process health内のConditionの説明と発報テストを行います。

<b>PROCESS HEALTH</b>を選択。
![プロセス.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/7d5b84bf-c63b-317b-9c62-eadbce654ff5.jpeg)

#### 5-3-1. Conditionに設定するパラメータ
<b>Condition名：</b>GCE VM Instance - Process Health Nginx

<h3>■Target</h3>
<b>Resource Type：</b>Single:GCE VM Instance
<b>Instance：</b>host1
<b>Command Line：</b>Contains:nginx
<b>Command：</b>
<b>User：</b>

<h3>■Configuration</h3>
<b>Condition triggers if：</b>Any time series violates
<b>Condition：</b>is below
<b>Threshold：</b>1
<b>For：</b>most recent value

![スクリーンショット 2019-07-12 10.39.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/a952d062-dea5-6282-c777-12591de9223d.png)
![スクリーンショット 2019-07-12 10.39.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/401994b4-bad3-8d32-9f9d-0444cf2d81ed.png)


#### 5-3-2. Conditionの各パラメータの説明
<h3>■Target</h3>
<b>Resource Type：</b>対象はインスタンスグループか、インスタンス単体か、すべてかを指定。またEC2かGCEかを指定する。

<b>Command Line：</b>プロセス名。Command Line, Command, Userに共通する文字列照合条件のパラメータは以下の通り。

Equals: （指定した文字列）と一致する
Contains: （指定した文字列）を含む
Starts with: （指定した文字列）で始まる
Ends with: （指定した文字列）で終わる
Regex: （指定した文字列）の正規表現（*、?等）に一致する

<b>Command：</b>プロセス名。Command Lineと同じ動作をするが、Command Line, Commandのどちらも設定した場合それぞれの値が含まれる(AND)プロセスが対象となる。

<b>User：</b>プロセスの実行ユーザー

ここまで入力して<b>Apply</b>をクリックすると入力した設定値の現在のサーバ状況がグラフに表示される。
![スクリーンショット 2019-07-11 11.50.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/7776b812-0c95-3410-0716-fc8f1409227b.png)

#### 5-3-3. 発報テスト
Nginxサービスを停止させます。

```bash
#nginxが稼働していることを確認
sudo systemctl status nginx

#nginxサービスを停止
sudo systemctl stop nginx

#nginxが停止したことを確認
sudo systemctl status nginx
```

アラートメールが受信された。
![_ALERT__GCE_VM_Instance_-_Process_Health_Nginx_on_sandbox-kengomakita_sendgrid_-_kengo_makita_topgate_co_jp_-_株式会社トップゲート_メール.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/6dca273a-3be7-4879-c170-b5b0f1c9afd9.jpeg)


## 6. Stackdriver Loggingのアラート設定
Stackdriver Loggingでは、ログベースの指標という機能でGCPログや、Stackdriver Logging Agentが収集したOSログのログ内で、特定の文言でフィルターをかけて指標にすることが可能です。指標をMetricとしてStackdriver Monitoringでアラート化することができます。[公式ドキュメント](https://cloud.google.com/logging/docs/logs-based-metrics/?hl=ja)

ログベースの指標には<b>システム（ログベース）指標</b>と<b>ユーザー定義（ログベース）指標</b>があり、

<b>システム（ログベース）指標</b>はStackdriver Logging によって事前定義されています。特定の期間内に発生したロギング イベントの数が記録されます。

<b>ユーザー定義（ログベース）指標</b>はユーザーによって作成され、特定のフィルタに一致するログエントリの数をカウントするか、一致するログエントリ内の特定の値を追跡します。

今回はユーザー定義（ログベース）指標で、CentOS7上でOOM KillerによってKillされたプロセスのログを指標として作成し、その指標をアラート化する設定を行います。

### 6-1. ログベースの指標の作成
Stackdriver Loggingコンソール画面で<b>ログベースの指標</b>をクリックし、<b>指標の作成</b>をクリックする。
![ログの指標_-_sandbox-kengomakita_-_Google_Cloud_Platform.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/c9955baa-5bd7-35d7-52d1-982e92625ae4.jpeg)

指標作成エディタが表示される。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/961c3193-ded5-3c03-3b34-55610675d6d2.jpeg)

#### 6-1-1. ユーザー定義（ログベース）指標に設定するパラメータ
Syslogに出力されたOOM KillerによるプロセスKillのログは、Stackdriver Loggingで以下の様に出力されます。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/c776900a-9993-0301-a1ce-a0d4b7b0bd59.jpeg)

この <b>Out of memory: Kill process</b> を含むログを指標として作成しアラート化していきます。

<b>名前：</b>killed-prosess
<b>説明：</b>OOM Killer Kiled Prosess
<b>ラベル：</b>
<b>単位：</b>1
<b>タイプ：</b>カウンター

#### 6-1-2. ユーザー定義（ログベース）指標に設定するパラメータの説明
<b>名前：</b>プロジェクトのログベースの指標で一意の名前を選択します。
<b>説明：</b>指標を説明します。
<b>ラベル：</b>（省略可）ラベルごとに [アイテムを追加] をクリックして、ラベルを追加します。
<b>単位：</b>カウンタ指標では、空白のままにするか、数字「1」を挿入します。
<b>タイプ：</b>カウンタ

### 6-2. 作成したユーザー定義（ログベース）指標のフィルターを作成
指標作成エディタ画面で、ログ検索欄の右端のプルダウンメニューをクリックし、<b>高度なログフィルターに変換</b>をクリックする。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/a89f2874-41c7-abf9-f9b9-846ae9ee1f85.jpeg)

フィルター入力ボックスが表示されるので、フィルター条件を入力する。
![ログビューア_-_sandbox-kengomakita_-_Google_Cloud_Platform.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/ab07cf0c-7c81-6565-08c3-a3ce0eae4ac7.png)


#### 6-2-1.フィルターに入力する条件。

```json
resource.type="gce_instance"
labels."compute.googleapis.com/resource_name"="host1"
jsonPayload.message:"Out of memory: Kill process"
```
※構造化ロギングをオフにしている場合は、<b>jsonPayload.message:</b>を<b>textPayload:</b>にする。
ここで<b>=(イコール)</b>とすると全文一致となり、<b>:(コロン)</b>は部分一致となる。

<b>指標を作成</b>をクリック。

<b>ユーザー定義の指標</b>内の一覧に作成された指標が表示される。
![ログの指標_-_sandbox-kengomakita_-_Google_Cloud_Platform1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/3c79bf26-31ad-eee6-7d6c-858b89fd9448.jpeg)

### 6-2. 指標をアラートとして設定
Stackdriver MonitoringのコンソールからPolicy作成画面を開く。

<b>Metric</b>が選択された状態で、<b>Find resource type and metric</b>の検索欄に<b>kill</b>と入力。先程作成した指標のが表示されるので<b>killed-prosess</b>をクリック。
![Create_Policy1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/e141b718-13db-08db-b0ce-7872444ddaec.jpeg)

#### 6-2-1. Conditionに設定するパラメータ
<b>Conditon名：</b>GCE VM Instance - Killed-Prosess

<h3>■Target</h3>
<b>Find resource type and metric：</b>
<b>Resource type：</b>logging/user/killed-prosess
<b>Metric：</b>

<b>Filter：</b>

<b>Group By：</b>

<b>Aggregator：</b>

<b>Advanced Aggregation：</b>
<b>Aligner：</b>delta
<b>Alignment Period：</b>1m
<b>Secondary Aggregator：</b>none
<b>Legend Template：</b>

<h3>■Configuration</h3>
<b>Condition triggers if：</b>Any time series violates
<b>Condition：</b>is above
<b>Threshold：</b>0
<b>For：</b>most recent value

※<b>Aligner</b>をdeltaにすることで1分前に取得した状態からの差分を次に取得する値として集計する。

### 6-3. 発報テスト
では実際にメモリに負荷をかけて、OOM KillerによってプロセスをKillさせましょう。

```bash
free -b
#stress: FAIL:~got signal 9 のエラーメッセージが表示されるまで繰り返す
stress -m 1 --vm-bytes 上記コマンドのavailable列の値 --vm-hang 0 -q &

#停止方法
jobs
fg #stressコマンドのjob番号
Ctrl + C キーを入力
```

アラートメールが受信された。
![_ALERT__GCE_VM_Instance_-_Killed-Prosess_on_sandbox-kengomakita_sendgrid_-_kengo_makita_topgate_co_jp_-_株式会社トップゲート_メール.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/db6c1c3c-c091-bab2-617d-df1a3ae3b7c6.jpeg)


## 7. アラートの無効化
Stackdriver Monitoringコンソールの左メニューから<b>Alerting</b> => <b>Policies Overview</b>を選択。
![スクリーンショット_2019-07-11_18_02_09.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/3e25ecc9-115b-83dc-407d-2a1d598512d2.jpeg)

Policyの一覧が表示される。<b>Enabled</b>が青くなっているのが有効になっている。
無効化したいアラートのEnabledをクリックし灰色になれば無効化される。
![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3237343037382f33303364633939372d326434352d306534302d303134362d3335646537393435356662632e6a706567.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274078/1fe94a18-e336-0b77-d9ca-c5b2719ba9bf.png)