Oracle Cloud 監視入門
- コレはなんの記事？
- お前誰よ
- 今回の監視対象
- 監視システムを作ろう
- まとめ
コレはなんの記事？
この記事は、JPOUG Advent Calendar 2020 - Adventar の18日目の記事です。
17日目はおおの たかしさんの記事『Oracle Databaseバージョンアップ後の性能劣化で試したい暫定対処 | アシスト』でした。
私もかつては OracleDBA だった時代があり、サポートには大変お世話になりました。 ただ、『『サポートからの回答待ちです』一辺倒だけではなく、自分でも調査・仮説検証が出来るエンジニアになれ』と先輩によく言われました。
そんなエンジニアになるためのヒントとして素晴らしい記事でした。
今回私がお伝えしたいのは DB から打って変わって、Oracle Cloud 上に作った Web システムを監視することになった場合、
- まず、どこから見れば良いのか
- どうやって見れば良いのか
という事を実例を交えて紹介していきたいと思います。
お前誰よ
現在、株式会社ウィルゲートでインフラエンジニアとして、自社サービスのインフラ運用をメインに日々ぼんやりしてます。
色々な組織形態があるかと思いますが、私は主にインフラの人≒運用の人な世界線で生きてきました。
最近社内勉強会用に書いたこちらの資料の評判が良かったので、
今回は調子に乗って Oracle Cloud 上の Web システム監視のチュートリアルを書きたいと思います。
これからクラウド上に作ったシステムの監視を始めたい方への、何かの参考になれば幸いです。
今回の監視対象
監視対象のシステム構成
Oracle Cloud には Always Free というサービスがありましてですね、なんと
- 2つのOracle Cloud Infrastructure Compute VM、ブロック・ストレージ、オブジェクト・ストレージ、アーカイブ・ストレージ、ロード・バランサとデータ・エグレス、監視と通知
- Oracle Application Express（APEX）やOracle SQL Developerなどの強力なツールを含む、2つのOracle Autonomous Database
がずっと無償で提供されます！
今回ももちろんその範囲内で構成しております。全て Oracle Cloud 上に構築した Web システムです。
ロードバランサ（以下 LB ）と、仮想マシン（以下 VM ）が１つずつのシンプルな構成です。
VM には NGINX と php-fpm を入れて、以下のような php を置いております。
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>テストサイト</title> </head> <body> <font size="7" color="#00ff00"> <?php $text = array( "おすぎです！", "ピーコです！", ); $count = count($text); $random = rand(0, $count - 1); echo $text[$random]; ?> </font> </html>
さらにはちゃんとドメインをとって、外部公開しています。
アクセスするたびに自分がおすぎなのかピーコなのかを再確認できるサイトなんですが、今年中には閉鎖します。
Oracle Cloud エージェント
Oracle Cloud の VM には、作成時に Oracle Cloud エージェント を有効にしています。
以下の画面にチェックを入れるだけでエージェントがインストールされて、OSの詳細なメトリクスを確認することが出来ます。
実際にOSにログインして確認してみると、 oracle-cloud-agent というサービスの起動を確認できます。
[opc@osugi ~]$ systemctl status oracle-cloud-agent
● oracle-cloud-agent.service - Oracle Cloud Infrastructure agent for management and monitoring
Loaded: loaded (/etc/systemd/system/oracle-cloud-agent.service; enabled; vendor preset: disabled)
Active: active (running) since 日 2020-12-06 01:32:46 GMT; 2min 32s ago
Docs: https://docs.cloud.oracle.com/iaas/
Main PID: 1776 (agent)
CGroup: /system.slice/oracle-cloud-agent.service
├─1776 /usr/libexec/oracle-cloud-agent/agent
├─1808 /usr/libexec/oracle-cloud-agent/plugins/bastions
└─1830 /usr/libexec/oracle-cloud-agent/plugins/gomon/gomon
12月 06 01:32:46 osugi systemd[1]: Started Oracle Cloud Infrastructure age...g.
12月 06 01:32:46 osugi agent[1776]: 2020/12/06 01:32:46 osName:CentOS Linu...:7
12月 06 01:32:46 osugi agent[1776]: 2020/12/06 01:32:46.618165 logger.go:3...og
12月 06 01:32:48 osugi sudo[1845]: oracle-cloud-agent : TTY=unknown ; PWD=...nd
Hint: Some lines were ellipsized, use -l to show in full.
監視システムを作ろう
どこから監視したらいいのか
監視対象のシステムは出来ました。では監視しましょう！
とはいえ、「どこから監視したら良いのか」と悩む方も少なくないでしょう。
そういう場合はまず
- そのシステムの利用者は誰なのか
- 利用者から見て「正常に動いてる状態」とはどういう状態か
を考えましょう。
今回は世界に向けた Web システムなので、『利用者は世界中の人』です。
その人達から見て正常に動いてる状態は、『Web アクセスが正常に行えるか』です。
かといって世界中の人に監視をお願いするわけにもいきません。
そこで外形監視ツールの登場です。
システムの外部（今回だと oracle cloud の外側のネットワーク）から Web アクセスをし、
を定期的にチェックしします。
今回外形監視に使うツールは、site24x７ を使います。
無償プランでも５サイトまで外形監視をすることが出来ます。
必要最低限の監視ならコレで十分かもしれません。
しかし今回の構成で言うと、LB を監視することで
- 実際にどのくらいのアクセスが来てるのか
- 来たアクセスを正常に、遅滞なく処理できているか
ということを確認でき、さらに VM を監視することで
- システムリソースを使い切っていないか
- サーバの I/O が処理待ちになっていないか
を確認することが出来ます。
Oracle Cloud のコンソール画面で LB や VM のメトリクスを確認できます。
コレでも十分に綺麗なのですが
といった課題があります。
そこで LB や VM の監視には、 OSS の データ可視化ツール Grafana を使います。
Grafana を使うことで以下のようなダッシュボードを作成できます。 上段が LB で、下段が VM です。
ただし、 Grafana はデータの可視化ツールなのでそれ単体では何も監視できません。
Oracle Cloud には Monitoringサービス というのがあり、クラウドの各リソースのメトリクスを Web ブラウザや API を通じて取得することが出来ます。
今回は Grafana から Oracle Cloud の API を叩いてメトリクスを取得し、可視化します。
監視システムの構成
今回の監視システムの概要は以下のようになります。
長々と書いてしまいましたが、監視対象は Oracle Cloud 上に作った 「https://headtonirvana.dev/」 という URL の Web システムで、
監視システムは
を使います。
Oracle Cloud の 外形監視 を site24x7 で実現する
それでは外形監視から始めましょう。
site24x7 にユーザ登録します。作成してもいいですし、他サービスのアカウントとも連携できます。
ログイン後は Web サイト監視の追加画面で監視したい URL を設定しましょう。 あとは基本的にデフォルトのままでいいです。
しばらく待つと監視が始まり、以下のような画面になります。とても簡単。
Grafana から Oracle Cloud を監視できるようにする
Grafana のインストール
今回は VM に Grafana をパッケージからインストールします。
VM の OS は Ubuntu 20.04 LTS です。
こちらの公式手順どおりに行います。
リポジトリを登録し
sudo apt-get install -y apt-transport-https sudo apt-get install -y software-properties-common wget wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
インストールします
sudo apt-get update sudo apt-get install grafana
そして起動
sudo systemctl daemon-reload sudo systemctl start grafana-server sudo systemctl status grafana-server sudo systemctl enable grafana-server.service
ブラウザで <IPアドレス>:3000 にアクセスして、grafanaの画面が出れば成功です。
Grafana で監視するためのユーザとグループ作成
次は Oracle Cloud のコンソールから行います。
Grafana で OCI を監視するための専用ユーザを作ります。
このユーザを使って Grafana から各メトリクスを取得します。 システムへの変更権限は不要なので、読み取り権限だけのユーザを作成します。
まずはグループの作成です。コンパネ画面から、「アイデンティティ」→「グループ」と進み、「グループの作成」を押下します。
今回は以下のように設定します。
- 名前：gp-grafana
- 説明: grafanaでの監視用グループ
次はグループに適用するポリシーの作成です。コンパネ画面から、「アイデンティティ」→「ポリシー」と進み、「ポリシーの作成」を押下します。
- 名前：policy-grafana
- 説明：grafanaでの監視用ポリシー
- コンパートメント：<監視対象を作成したコンパートメント>
ポリシー・ビルダーはカスタマイズ（拡張）を押下し、以下の値を入力してください。
Allow group gp-grafana to read metrics in tenancy Allow group gp-grafana to read compartments in tenancy
最後にコンパネ画面から、「アイデンティティ」→「ユーザ」と進み、「ユーザの作成」を押下します。
以下のように、IAM ユーザを作成します。
作成したユーザの詳細画面から『ユーザーをグループに追加』を押下し、先ほど作成した『gp-grafana』グループに追加しましょう。
Oracle Cloud を監視するためのプラグインを入れる
この作業は Grafana サーバで行います。
デフォの Grafana では Oracle Cloud の API を叩けないので、プラグインを入れます。
こちらのプラグインを使います
似たようなプラグインで、 Oracle Cloud Infrastructure plugin for Grafana | Grafana Labs というのがあるのですが、 こちら DEPRECATED （非推奨）になっていて、上記プラグインを使ってねと書いてあるので素直に従いましょう。 ぶっちゃけこちらのプラグインでは、現在動きません。
インストールは簡単です。以下のコマンドで簡単に入ります。
grafana-cli plugins install oci-metrics-datasource
しかし、これでおしまいではありません。 今回の監視サーバは Oracle Cloud の外部にあり、 API を叩くには認証が必要です。
認証のために、 Oracle Cloud をコマンドで操作するツール OCI CLI をインストールします。
VM に OCI CLI をインストールする
公式手順に沿って行います。
bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"
終わったらバージョンを確認しましょう
oci -v
次に、Oracle Cloud のコンソールから以下を確認し、メモ帳などに保存しておきましょう。
- 先程作った Grafana ユーザーのOCID
- 「アイデンティティ → ユーザー」と遷移し、ユーザの詳細画面から確認。（ocid1.user.oc1..aaaaaaa......みたいなやつがそうです）
- 接続するOracle CloudのテナントのOCID
- 「管理 → テナンシ詳細」と遷移し、て何子の詳細画面から確認（ocid1.tenancy.oc1..aaaaaaa....みたいなやつがそうです）
サーバに戻って、 OCI CLI のセットアップをしましょう。
oci setup config
選択肢は基本的にデフォで大丈夫です。 先程メモしたOCIDを間違わずに入力しましょう。
セットアップが終わったら、作成された鍵ファイルの中身をメモ帳にコピーしておいてください。
cat ~/.oci/oci_api_key.pem
次は Oracle Cloud のコンソールに先程メモした鍵を登録します。
「アイデンティティ → ユーザー → APIキー」と遷移し、ユーザの詳細画面の 「APIキーの追加」を押下し、先程メモしたキーの中身を貼り付けます。
無事に保存できたら VM に戻ります。もう少しですよ！
以下のようにコマンドでリージョンの一覧が出たら CLI のセットアップは成功です。
$ oci iam region list --output table +-----+----------------+ | key | name | +-----+----------------+ | AMS | eu-amsterdam-1 | | BOM | ap-mumbai-1 | | CWL | uk-cardiff-1 | | DXB | me-dubai-1 | | FRA | eu-frankfurt-1 | | GRU | sa-saopaulo-1 | | HYD | ap-hyderabad-1 | | IAD | us-ashburn-1 | | ICN | ap-seoul-1 | | JED | me-jeddah-1 | | KIX | ap-osaka-1 | | LHR | uk-london-1 | | MEL | ap-melbourne-1 | | NRT | ap-tokyo-1 | | PHX | us-phoenix-1 | | SCL | sa-santiago-1 | | SJC | us-sanjose-1 | | SYD | ap-sydney-1 | | YNY | ap-chuncheon-1 | | YUL | ca-montreal-1 | | YYZ | ca-toronto-1 | | ZRH | eu-zurich-1 | +-----+----------------+
プラグインが Oracle Cloud の API を使えるようにする
最後の手順です。 Grafana が Oracle Cloud の API を使えるようにしましょう。
セットアップした設定を grafana ユーザも使えるようにします。
sudo cp -r .oci /usr/share/grafana sudo chown -R grafana:grafana /usr/share/grafana
次に config を編集し、key ファイルの PATH を変更します。
sudo vim /usr/share/grafana/.oci/config
以下のようにしましょう。
key_file=/usr/share/grafana/.oci/oci_api_key.pem
ここまで出来たら、 Grafana の UI にログインしましょう。
Configration → Data Sources と遷移し
Add data source を押下し
下の方にある、Oracle Cloud Infrastructure Metrics を Select します。
設定画面で、先ほどコピーしておいたテナントの OCID を設定し、リージョンは監視対象を作成したリージョン（私はap-tokyo-1）、environment は local で大丈夫です。
そして左下の Save & Test を押下し、以下のように 「Data source is working」と表示されれば成功です！
失敗しちゃう場合はコピーしたファイルのパーミッションや鍵の場所などを確認してください。
やっとダッシュボード作れますよ奥さん！
Grafana でダッシュボードを作る
コレで準備完了！実用的で格好いいダッシュボード作りましょう！
先程は
しかし今回の構成で言うと、LB を監視することで
- 実際にどのくらいのアクセスが来てるのか
- 来たアクセスを正常に、遅滞なく処理できているか
ということを確認でき、さらに VM を監視することで
- システムリソースを使い切っていないか
- サーバの I/O が処理待ちになっていないか を確認することが出来ます。
と書きましたが、もうちょっと具体的に話しましょう。
RED Method と USE Methoｄ という考え方があります。
RED Method と USE Methoｄ
まず RED Method は
の頭文字をとったもので、
上記の記事では
サービスに関わる誰もがエラー率、リクエスト率、そしてそれらのリクエストのレイテンシの分布を理解する必要があります。 サービス監視の観点に一貫性を持たすことができ、開発側が意図していないコードのへの問い合わせも行えます。 RED Method はユーザの満足度を示す優れた指標です。 エラー率が高い場合、それは基本的にユーザーに影響があり、ページ読み込みエラーが発生します。 表示時間が長いとWebサイトの表示が遅くなります。これらは、意味のあるアラートを作成し、SLA を測定するための優れた測定基準です。
と紹介されてます。
そしてさらにオライリーが出版している『入門 監視』には、監視のデザインパターンとして以下のような考え方が紹介されています。
まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところです。 Apache のノードが何台動いているか、ジョブに対していくつのワーカが使用可能かが使用可能と行ったアプリケーションの実装の詳細をユーザは気にしません。
最も効果的な監視ができる方法の一つが、シンプルに HTTP レスポンスコード（特に HTTP 5xx 番台）を使うことです。 その次として、リクエスト時間（レイテンシとも言う）も有益です。 このどちらも『何が』問題なのかは教えてくれませんが、『何かが』問題で、それがユーザに影響を与えていることは分かります。
とあります。
RED Method はユーザに何が起きているのかを監視するために有益な、監視の指標だということが分かります。
次に USE Method は
- Utilization (リソースがどのくらいビジーだったかの割合)
- Saturation (キューの長さなどの、各リソースの仕事量)
- Errors (エラーイベントが起きた数。messageログなど)
の頭文字で、リソース内部の状況を把握するのに適しています。
なので今回は、ユーザに近い LB を Red Method で監視し、 VM を USE Method で監視します。
そうすることで、例えばアクセスが急増した時に LB のリクエスト数と VM の CPU 使用率の相関を確認でき、 障害原因の調査や今後のリソース増強へのヒントに使うことが出来ます。
Oracle Cloud の LB を Red Method で監視する
公開されている LB のメトリクス情報を元に、どのメトリクスを監視するか考えてみましょう。
それぞれ、以下のメトリクスで良さそうです。
- Rate (単位時間あたりのリクエストの数)
- HttpRequests
- Errors (その中でのエラーの数)
- HttpResponses502
- HttpResponses504
- HttpResponses5xx
- Duration (リクエストをさばくのにかかってる時間)
- ResponseTimeHttpHeader
それでは作っていきましょう！
Create → Dashboard と進みます
ダッシュボード作成画面になるので、 「Add new panel」を押しましょう
これが panel の作成画面です。ここでクエリを作成してグラフを作っていきましょう。
まずは HttpRequests です。単位時間あたりのリクエスト数を可視化しましょう。
以下のように設定すると、グラフが出てくるはずです。
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_lbaas |
| Resourcegroup | NoResourceGroup |
| Metric | HttpRequests |
| Aggregation | max() |
| Window | 1m |
| Resolution | auto |
Panel の名前はわかりやすくし、 Description の部分には監視しているメトリクスの説明を入れると忘れた頃に見ても安心です。
あとは Save を押してダッシュボードの名前を設定してみましょう
4つのメトリクスが出てきてると思いますが、これはロードバランサ自体と、バックエンド・セットというバックエンドのサーバへのヘルスチェックなどを定義した論理エンティティのメトリクスが表示されています。 そして、Oracle Cloud の LB はデフォルトで冗長化されてるので4つのメトリクスが表示されているというわけです。
次はエラーの数です。まずグラフの種類は 「Stat」を選択しましょう。
Display の Calculation は Max にしておいて下さい
そして以下のように設定すると、
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_lbaas |
| Resourcegroup | NoResourceGroup |
| Metric | HttpResponse502 |
| Aggregation | max() |
| Window | 1m |
| Resolution | auto |
こんな画面が出てくると思います。6個もあるのは
- LB の http リスナー
- LB の https リスナー
- バックエンド・セットの リスナー
が冗長化されてるからです。
コレ以外にも504エラーの数もみたいので、クエリを複製してちょっと中身を変えましょう。
クエリの右上の部分に Duplicate query ボタンがあるので押してみましょう
クエリが複製されるので、合計2つ作って
- HttpResponse502
- HttpResponse504
それぞれが表示されるようにしてみましょう
複製したクエリの、以下の部分を変更しましょう
| 項目 | 設定値 |
|---|---|
| Metric | HttpResponse504 |
こんな画面ができしましたか？
「表示がちょっと多いな」と感じた方は、 Dimensions でコンポーネントをフィルタリングしてみましょう。
次は処理にかかった時間 Duration ですね。
以下のようにクエリを作りましょう。
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_lbaas |
| Resourcegroup | NoResourceGroup |
| Metric | ResponseTimeHttpHeader |
| Aggregation | max() |
| Window | 1m |
| Resolution | auto |
時間がわかりやすいように、縦軸に単位を付けましょう
オプションの Axes → Left Y → Unit で milliseconds(ms) を選択します。
あとはタイトルと説明を書いて保存
ダッシュボードに戻って、画面に収まるようにグラフの幅を調整しましょう。
コレで Red Method の完成です！
Oracle Cloud の VM を USE Method で監視する
公開されている VM のメトリクス情報を元に、どのメトリクスを監視するか考えてみましょう。
それぞれ、以下のメトリクスで良さそうです。 今回の構成では、messageログの監視といった方法を使ったエラーイベントが検知できないので Error は見ません。
- Utilization (リソースがどのくらいビジーだったかの割合)
- CpuUtilization
- MemoryUtilization
- Saturation (キューの長さなどの、各リソースの仕事量)
- NetworksBytesIn
- NetworksBytesOut
それでは先程の要領でグラフを作ってみましょう。
Namespace と Metriｃ が変わってることに注意です。
- CpuUtilization
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_computeagent |
| Resourcegroup | NoResourceGroup |
| Metric | CpuUtilization |
| Aggregation | max() |
| Window | 1m |
| Resolution | auto |
- MemoryUtilization
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_computeagent |
| Resourcegroup | NoResourceGroup |
| Metric | MemoryUtilization |
| Aggregation | max() |
| Window | 1m |
| Resolution | auto |
- NetworksBytesIn/Out
Aggregation が rate になっていることに注意して下さい
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_computeagent |
| Resourcegroup | NoResourceGroup |
| Metric | NetworksBytesIn |
| Aggregation | rate() |
| Window | 1m |
| Resolution | auto |
| 項目 | 設定値 |
|---|---|
| Region | <監視対象があるリージョン> |
| Compartment | <監視対象があるコンパートメント> |
| Namespace | oci_computeagent |
| Resourcegroup | NoResourceGroup |
| Metric | NetworksBytesOut |
| Aggregation | rate() |
| Window | 1m |
| Resolution | auto |
またネットワークのグラフは受信と送信が混ざらないように、送信のグラフを反転させてます。
やり方は以下のように、 Out という文字列のあるメトリクスデータをY軸反転させます。
あとは単位もつけてあげましょう
あとはダッシュボードに戻って大きさを揃えて出来上がりです。
ダッシュボード設定
ダッシュボード上部から、ダッシュボードのセッティングを行えます。
名前とかタグの設定ができるんですけど、今回お伝えしたいのが Graph Tooltip です。
- Default
- Shared crosshair
- Shared Tooltip
から選べるんですが、この設定で各パネルにある値を関連付けて確認しやすくなります。
画面で比較してみましょう
- Default だと、マウスオーバーで1つのパネル上の値を確認できます
- Shared crosshair だと、時間軸を赤い棒が各パネルに表示されます
- Shared Tooltip だと、時間軸を赤い棒と、そのときの値が各パネルに表示されます
違いが分かりましたでしょうか？
個人的に好きなのは Shared crosshair です。「この時にはアクセスが多くて、CPU使用率も高かったんだな」ていうのが直感的に分かって、 Shared Tooltip だと画面の情報がちょっと多い感じがするので。
こういうダッシュボードを定期的に共有して、「アクセスが多い時にサーバのリソースを使い切ってるのでサーバを増やしましょう」とか「このままユーザ数が増えていくとリソース不足が懸念されるので、来季の予算増やしましょう」みたいな話ができるようになると思います。
まとめ
クラウドの登場を期に SRE や DevOps、 SLA 、 SLO などの用語や概念が広まったり生まれたりして、運用界隈は新しい情報が多いです。
その中でも私が好きな言葉に「Nines don’t matter if users aren’t happy.（数字の９をいくら並べても、ユーザがハッピーじゃなきゃ意味ないよ）」というのがあります。
この辺の記事が原点ぽい？
T シャツなんかも売ってます。
T シャツの話はよくて、その記事の中ではシステム稼働率とかで9の数字をいくら並べても不幸な目に合うユーザは居るわけで、ユーザのために本当に必要なものを見極めて優先度を付けて監視しましょう。 絶対に気にしないとダメなものを定義しましょう。
みたいなことが書いてあります。
クラウド、仮想化、コンテナ化で抽象度のレイヤは高度かつ複雑になってきました。今回の構成でも、見ようと思えば紹介した量の何倍もの情報を見ることができるわけで、監視の重要性とは裏腹に「何したら良いの？」と戸惑う方も多いのではないのでしょうか。
今回紹介したような RED/USE Method のような考え方で優先度を付けて監視できると、幸せなユーザが増えるかもしれませんね。
最後までお読み頂きありがとうございました。
明日の 12月19日は Naotaka Shinogi さんです。よろしくおねがいします！
