オブザーバビリティにおけるAI活用

# オブザーバビリティ時代の監視
### 従来型IT監視手法
従来型ITインフラの監視は、応答有無を判断条件として例えば３回連続応答が無ければ障害と判断していました。リソースモニタリングは、CPU利用率やディスク残り容量などに閾値を設定して、その閾値を超過したときだけアラート通知していました。

### モダンな監視手法
オブザーバビリティ時代の昨今では、監視やリソースモニタリングで計測した連続的なデータとして、その状態の変化を観測します。時系列で連続するデータは、例えばURL応答時間を観測して、応答時間がだんだん遅くなることを検出することが可能です。つまり、ユーザーのWEB画面の表示がだんだんと遅くなる状態変化を見つけます。別の例では、プロセスあるいはプログラムコードのなにかの原因でURL応答が遅くなり、やがてWEBシステムが停止する前に状態の変化に気付くこと、そして障害になる前に原因を取り除くことが大切です。
分かりやすい障害事例として、ログローテーションをせずに大量のログをディスクに保存して、ついにはディスク容量100%にログを書き込んでしまい、アプリがログを書き込めずにプロセスが応答しなくなってしまう障害。ディスク容量が80%超過したらアラート通知という設定も可能ですが、ディスク容量がいつもと何か異なるときにアラート通知するという設定も可能です。

### Datadog監視SaaSでのAI活用
Datadogは、従来型IT監視もできるし近年のモダンな監視もできます。その上、セキュリティ監査やユーザー視点のアプリもモニタリングできます。そんなDatadog監視機能は、いつもと違う異常（Anomaly）と予測（Forecast）による状態の変化を観測することもできます。

# 前提
GCPの仮想サーバー(Compute Engine)に、Datadogエージェントをインストール済み

# ディスク容量の異常検知（Anomaly）
ディスク容量の増減傾向を検知できることを検証してみる。

### モニタリングの初期設定
Anomal
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/9e48e9c6-baff-549d-ef89-afa7116a0bc2.png)

``` 
avg(last_15m):
anomalies(avg:system.disk.total{*}, 'agile', 2, 
direction='both', 
interval=60, alert_window='last_15m', 
count_default_zero='true', seasonality='weekly', timezone='utc') >= 1
```

### 定常時
ディスク容量の増減は無い。一定量をキープ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/0c6558ef-e934-4e24-988c-4c7ed646380e.png)

### 異常な操作をしてみる
DDコマンドで1GBの大きなファイルを2つ作ってみる。

```
dd if=/dev/zero of dummy_file bs=1024k count=1000
```

### モニター画面
ディスクサイズが増加したことが分かる。通常枠（レンジ）を示す灰色のゾーンを超過した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/db44da8a-a58f-464e-17f2-f908f895af65.png)

### アラート・メールが届いた（Trrigered）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/9648b19a-1cc0-e390-c9bc-b555832ba173.png)

### ダッシュボードにもアラート表示
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/143072ad-0872-cf7e-0bb0-7f4e5631ad02.png)

### テストデータを削除して定常に戻す
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/307cddd8-53a3-9a9c-cb44-52ab0389950b.png)

### Recoveredメールが届く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/f0506750-027b-7ac2-a7f8-f6c60b1b9bf3.png)

# URL応答モニタの異常検知（Anomaly）
DatadogのUC Monitoringに、URL応答を検査するSynthetics Testsがある。

### モニタリングの初期設定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/8356d985-9a68-84f8-03dc-0e83860bd62c.png)

```
avg(last_4h):
anomalies(sum:synthetics.http.response{env:gcp}.as_count(), 'agile', 2, 
direction='both', 
interval=60, alert_window='last_15m', 
count_default_zero='true', seasonality='daily', timezone='utc') >= 1
```

### 定常時
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/46f7c267-2697-cd16-d7df-7c70d88e2279.png)

### 異常な操作をしてみる
プログラムコードを書いて応答時間をわざと遅くしたかったけれど時間かかりそうだったので、apacheプロセスを止めることで代用します。

```
$ sudo systemctl stop apache2
```

### モニター画面
URL応答時間が通常枠（レンジ）を示す灰色のゾーンを超過した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/65fc48f4-834e-b5b7-2abc-c6a4d2ba8859.png)

### アラートメールが届いた（Triggered）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/74681ce5-43ff-2ff0-c4b5-51764a57b864.png)

### WEBサービスを再起動して定常に戻す

```
$ sudo systemctl start apache2
```

### Recoveredメールが届く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189936/6a082578-c61e-f709-73c4-a7423f21d28f.png)


# まとめ
- 異常検知（Anomaly）を使ってみた
- ディスク残り容量は、予測検知（Forecast）を使ってみるべきだった。間違えた。
- アラート通知がメールで届いた（復旧時もメールが届く）
- 折れ線グラフなど推移を可視化できた
- エラートラッキングとかコンポジットとか未だ使ったことがない機能がある
- 他にも多くの監視・観測の機能があるので使ってみたい
- 【注意点】異常検知（Anomaly）は異常な状態が長く続くとそれ自体が定常時となり復旧アラートも届くので勘違いしないようにモニター画面で確認した方がよい。