はじめに
まず、メトリックとは、
特定のリソースのヘルス、容量またはパフォーマンスに関連する測定。
「引用:モニタリングの概念 のメトリック」
とあり、コンピュート・インスタンスでは https://docs.oracle.com/ja-jp/iaas/Content/Compute/References/computemetrics.htm#Availabl に記載されている、 CPUやメモリの使用率、ディスク、ネットワークのスループットなどが標準で提供されています
しかし、一般的なコンピュートの監視項目としては少ないため、本記事では一般的な監視項目の一つである、ディスク使用率監視を Linux OS に対して行ってみたいと思います
手順概要
- Pythonスクリプトで特定デバイスのディスク使用率を取得する
- OCIのカスタム・メトリックの公開を使用し、独自のメトリックをモニタリング・サービスに公開する
- 取得したディスク使用率を確認する
- メトリックにアラームを設定する
- アラーム通知の確認
ここでポイントとなるのは、 カスタム・メトリックの公開
で、こちらのドキュメントに記載されているように、REST APIを使用して独自のメトリックをモニタリング・サービスに公開することができる機能となります
カスタム・メトリックの注意事項
独自のメトリックを作成出来るカスタム・メトリックですが、ドキュメントには下記の注意事項が記載されています
カスタム・メトリックを定義する場合は、次の点に注意してください:
・カスタム・メトリックが制限を超えないようにします。たとえば、有効なディメンション範囲とカスタム・メトリックの最大ストリーム数に気を付けてください。PostMetricDataを参照してください。
・集計を考慮してメトリックを定義します。カスタム・メトリックは1秒ごとに頻繁にポストできますが(最小頻度は1秒)、最小集約間隔は1分です。
・返される際の制限を考慮してメトリックを定義します。 返されるデータの制限情報には、100,000データ・ポイントの最大値と時間範囲の最大値(レゾリューションによって決定され、間隔に関連しています)が含まれます。MetricDataリファレンスを参照してください。
・カスタム・メトリックを取得する場合、リソース・グループと照合できます。リソース・グループが空白(null)の場合、リソース・グループがないメトリック・データを返します。
また、PostMetricData API にも注意事項があります
・Dimensions per metric group. Maximum: 20. Minimum: 1.
・Unique metric streams. Maximum: 50.
・Transactions Per Second (TPS) per-tenancy limit for this operation: 50.
それぞれに注意事項・制限が有りますが、下記の二つは特に注意が必要ではないでしょうか
- カスタム・メトリックは秒単位で取得(ポスト)させることが可能だが、1分間隔で集約されてしまう
- API呼び出しはテナンシーあたり、50TPSを上限とする
設定
本記事では下記サンプル・スクリプトを毎分実行し、ディスク使用率を公開してみました
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
#!/usr/bin/python3 import sys import os import shutil import subprocess import oci from datetime import datetime def put_metric_data(device) : path = '' try : result = subprocess.run('df | awk \'($1=="' + device + '"){print $6}\'', shell=True, stdout=subprocess.PIPE, encoding='UTF-8') path = result.stdout.replace('\n', '') except Exception as e: sys.exit(1) total, used, free= shutil.disk_usage(path) free_pt = free / total * 100 config = { 'user' : 'ocid1.user.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'fingerprint' : 'XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX', 'key_file' : '/path/to/api_key.pem', 'tenancy' : 'ocid1.tenancy.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'region' : 'ap-tokyo-1', } dt_now = datetime.utcnow() monitoring_client = oci.monitoring.MonitoringClient(config, service_endpoint='https://telemetry-ingestion.ap-tokyo-1.oraclecloud.com') post_metric_data_response = monitoring_client.post_metric_data( post_metric_data_details = oci.monitoring.models.PostMetricDataDetails( metric_data = [ oci.monitoring.models.MetricDataDetails( namespace = 'custom_compute', compartment_id = 'ocid1.compartment.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', name = 'free_space', dimensions = {'host_name': os.uname()[1], 'device_name': device}, datapoints = [ oci.monitoring.models.Datapoint( timestamp = datetime.strftime(dt_now,'%Y-%m-%dT%H:%M:%S.%fZ'), value = free_pt)], resource_group = 'disk_group', )], ) ) if __name__ == '__main__': put_metric_data('/dev/sda1') put_metric_data('/dev/sda3') sys.exit(0) |
1. ディスク使用率の取得
Python の shutil ライブラリを使用して、ディスクサイズ、使用バイト数、空きバイト数を取得し、空き領域率を計算します
2. カスタム・メトリックの公開
PostMetricData APIを使用して公開します
各パラメータにおいて、必須項目は下記となります
- MetricDataDetails.compartmentId
- MetricDataDetails.dimensions
- MetricDataDetails.name
- MetricDataDetails.namespace
- Datapoint.timestamp
- Datapoint.value
※PostMetricData APIのドキュメント中のExamplesを参考にし、コンパートメントIDなどを環境に合わせて変更するだけで、基本的には大丈夫だと思います
ただし、MonitoringClientのservice_endpointはoptionalでconfigパラメータのリージョンで適切なエンドポイントが指定されるとMonitoringClientのドキュメントには記載されていますが、指定しなければうまく接続出来ませんでしたので、各APIのドキュメントを一度はご確認いただきたいと思います
3. メトリック・エクスプローラでカスタム・メトリックの値を確認する
1 2 |
MM=$(date '+%M') dd if=/dev/zero of=/var/tmp/blog/dummy${MM} bs=1M count=2048 |
を5分間隔で実施したところ、ディスクの空き領域が徐々に減少していることが確認出来ます
4. アラームを設定してみる
空き領域が30%を下回った際に、メールで通知するように設定してみました
カスタム・メトリックでも、標準で提供されているメトリックと同様にアラームの設定が可能です
5. アラーム通知の確認
送信されてきたメールはこのようになります
まとめ
カスタム・メトリックを使用することで、標準では公開されていないような値であってもチャートで確認したり、アラームで通知することが可能となります
ただし、注意事項の欄で記載しましたように、API呼び出しの制限や1分単位で集約されてしまうなど、注意が必要となります
特に、API呼び出しはテナント全体での制限となるため、多数のコンピュート・インスタンスを作成されているような環境では、全台数を対象とすることは出来ないかもしれません
しかし、対象インスタンスが少ない場合などでは、ZabbixやHinemosといった監視システムを構築する必要が無いため、非常に有用な手段となるのではないでしょうか