VPC統計サービス

この記事では、仮想マシンメトリックの収集、処理、保存に使用されるコンポーネントについて説明し、VPCプロジェクトでこれらのコンポーネントを使用する方法の例を示します。



メトリックとその初期処理を取得するには、 OpenStack Ceilometerコンポーネントが責任を負います。



長い間、すべての基本的なテレメトリ機能を提供した唯一のOpenStackコンポーネントでした。



その後、開発者はCeilometer機能をいくつかの製品に分割しました。

• Aodh-アラートサービス。
• Gnocchi-集計された測定値のストレージサービス。
• Panko-イベントに関する情報を保存するサービス。
• Ceilometerは、測定収集サービスです。

AodhとPankoはこの記事の範囲外です。

測定コレクション-OpenStack Ceilometer

Ceilometerは、CPU、RAM、ネットワークインターフェイス、ディスク、温度値の使用に関する測定値をさまざまなソースから収集できます。

• ハイパーバイザーから直接（ KVM 、 Hyper-V 、 XEN 、 VMware ）;
• メッセージキュー（ RabbitMQ 、 ZeroMQ 、 Kafka ）から;
• REST APIを介して他のOpenStackコンポーネントをポーリングすることにより
• SNMPまたはIPMIを使用して機器をポーリングする。

Ceilometerは以前、収集されたディメンション、メトリック、およびリソースを操作するためのAPIも提供していました。 ただし、 OpenStack Ocataのリリース以降、CeilometerのメインバックエンドはGnocchiであったため、対応する機能はこのコンポーネントから削除されました。Gnocchiは、これらすべてのオブジェクトを操作する独自の完全機能APIを備えています。



数年前にOpenStack JunoリリースのCeilometerを使用してみました。



VPCプロジェクトの請求の最初のバージョンでは、レポートを送信しました。レポートは、ユーティリティプログラムと、標準のOpenStack Keystoneトークンを使用して承認されたユーザーの両方が利用できました。



当時のCeilometerの主なバックエンドは、SQLデータベースとMongoDBでした。 残念ながら、6か月使用した後の両方のオプションは負荷に対処するのをやめました。 これは、収集されたデータの構造があまりにもゆるく、インデックス付けできず、詳細すぎるためです。



各ディメンションは、集計や変更なしで元の形式で保存されました。 大量のデータでは、一定期間のサンプリング測定の単純な操作に非常に長い時間がかかり始め、サービスを使用できなくなりました。



2014年にアーキテクチャ上の問題を克服するために、OpenStackのテレメトリサービス開発者チームは、Gnocchiと呼ばれる新しいプロジェクトを立ち上げました。 理由の詳細な説明と選択された解決方法は、Gnocchi-Julien Danjouの主要開発者のブログのレビューノートにあります： OpenStack Ceilometer and the Gnocchi experiment 。

Ceilometerのアーキテクチャ

Ceilometerのアーキテクチャは、図に明確に示されています。



ハイパーバイザーがインストールされている各ホストには、仮想マシンからデータを収集するCeilometer Agent Computeコンポーネントがあります。 この場合、収集されたデータは、メッセージキューを介して中央のCeilometerエージェント通知に送信されます。



物理ホストのロードに関するデータを収集する必要がある場合は、それらにSNMPエージェントをインストールして使用できます。 この場合、データ収集は中央エージェントCeilometer Agent Centralによって実行されます。



処理後、このデータはCeilometer Agent Notification Agentに転送され、選択されたバックエンドに送信されて保管されます。



中央のCeilometer Agent Notificationは、メッセージキューをリッスンすることにより、他のOpenStackコンポーネントに関するイベントを収集することもできます。 これは、サーバー、ディスク、またはポートの作成、変更、または削除に関する情報を追跡および保存する必要がある場合に役立ちます。



最近まで（より正確には、今年2月に行われたOpenStack Ocataのリリース前）、Ceilometer Agent NotificationおよびCeilometer Agent Centralとともに、コントロールホストにもう1つのコンポーネントであるCeilometer Collectorをインストールする必要がありました。



このコンポーネントは使用されなくなりました。 その機能はすべて、Ceilometer Agent Notificationによって実行されます。

Ceilometerのセットアップ

主なCeilometer構成ファイルは次のとおりです。

• ceilometer.conf-すべての基本的なCeilometerパラメーター（ロギング、メッセージキューの使用、認証、Ceilometerプロセスの調整など）を記述するファイル。
• pipeline.yaml-収集する情報と場所を説明するファイル。
• gnocchi_resources.yaml -CeilometerとGnocchiオブジェクトの対応の説明（これについては後で説明します）。

使用可能なすべてのオプションを含むceilometer.confファイルテンプレートは、公式ドキュメントCeilometer Configuration Optionsを使用してダウンロードまたは生成できます。



pipeline.yamlファイルは独立して完成する必要があります。

例：

--- sources: #  - interval: 600 #    () meters: #   - memory.usage #      () - memory.resident # ,      () name: memory_meters #    sinks: #    - memory.sink #    - interval: 600 #    () meters: #   - disk.device.read.bytes #       - disk.device.write.bytes #       name: disk_meters #    sinks: #    - disk_sink #    sinks: #   - name: memory_sink #    (  "memory_meters") publishers: #   ,      - gnocchi:// #    Gnocchi - name: disk_sink #    (  "memory_meters") publishers: #      - gnocchi:// #    Gnocchi (    )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルでは、収集されたデータの変換を追加で指定できます。 たとえば、 memory.usageおよびmemory.residentメトリックの受信値をすべてメガバイトからキロバイトに変換できます。 同時に、これらのメトリックの名前を変更し、測定単位を追加します。



これを行うには、 memory_sinkコンシューマーを次のように編集する必要があります。

 sinks: - name: memory_sink transformers: - name: "unit_conversion" #    unit_conversion parameters: source: map_from: name: "memory\\.(usage|resident)" #   target: map_to: name: "memory.\\1.kilobytes" #   scale: "volume * 1024.0" #    unit: "KB" #    publishers: - gnocchi://
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルの形式およびその他の変換の適用に関する詳細情報は、公式ドキュメント「 データ処理とパイプライン」に記載されています。



次に、Gnocchiプロジェクトについて検討します。これにより、収集した測定値を集計形式で保存し、それらを使用するためのAPIを提供できます。

データストレージ-ニョッキ

Gnocchiプロジェクトは時系列データベースです。

2017年5月上旬に、Gnocchi開発者はこのプロジェクトをOpenStackインフラストラクチャから撤回することを決定したことに注意してください。



コードベースはGitHubに移植されており、 GitHub Issuesメカニズムはバグトラッカーとして使用されています。 主な理由の1つは、GnocchiをCeilometerのバックエンドとしてだけでなく、他のソリューションに適したより普遍的な製品として位置付けることです。 たとえば、Gnocchiリポジトリには、既にCollectdからデータを保存するためのプラグインとGrafanaでグラフ化するためのプラグインが既にあります。



Gnocchiのデバイスと機能をより詳細に検討してください。

ニョッキアーキテクチャ

ニョッキは、2つの主要なコンポーネントで構成されています。

• データを保存および更新するためのAPI （たとえば、Ceilometerから、または手動で）、および集約データの受信。
• Metricdは、受信したばかりでまだソートされていないデータを処理し、選択したストレージ（ Ceph 、 Redis 、 OpenStack Swift、またはローカルファイルシステム）に正しい形式で保存するデーモンです。

バージョン3.1から、Gnocchiは処理済みデータと生データ用のさまざまなタイプのストレージのサポートを導入しました。 この分離により、「ホット」な非集約データを高速ストレージ（たとえば、Gnocchiバージョン4.0でサポートされたRedisなど）に配置し、データをより信頼性の高いスケーラブルなバックエンド（たとえば、Ceph、 Gnocchiの最初のバージョン）。



Gnocchiでは、直接的なデータストレージに加えて、メトリックインデックスとそのメタデータが格納されているSQLデータベースも必要です。 これにはMySQLまたはPostgreSQLを使用できます。 Gnocchiは、独自のアプローチを使用して測定値を保存します。これは、リストされているすべてのテクノロジーが時系列の形式でデータを保存する機能を提供しないためです。

Gnocchiにデータを保存する

新しいデータを受信すると、値は元の形式で保存されません。 代わりに、作成されたアーカイブポリシーに従って、ユーザーが選択したメソッド（この例ではメソッドの最小、最大、平均）を使用して集計され、指定された精度（この例では3600秒）で保存されます。



python-gnocchiclientコンソールクライアントを使用してアーカイブポリシーを作成できます。 たとえば、3つの集約メソッド（最小、最大、平均、およびデータの格納方法の2つの定義）を含むmemory_policyというポリシーを作成します。 最初の定義では、7日間にわたって1時間の精度でデータを保存するとしています。 2番目の方法では、1年間1日の精度でデータを保存します。



さらに、バックウィンドウの値が72であることを示します。これにより、現在作成されているメトリックだけでなく、何らかの理由で古いメトリックも72日以内保存できます。

 controller:~# gnocchi archive-policy create memory_policy \ > -b 72 \ > -m min -m max -m mean \ > -d 'granularity:1h,timespan:7d' \ > -d 'granularity:1d,timespan:365d'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

応答として、作成されたポリシーの説明を取得します。

 +---------------------+-------------------------------------------------------------------------+ | Field | Value | +---------------------+-------------------------------------------------------------------------+ | aggregation_methods | max, min, mean | | back_window | 72 | | definition | - points: 168, granularity: 1:00:00, timespan: 7 days, 0:00:00 | | | - points: 365, granularity: 1 day, 0:00:00, timespan: 365 days, 0:00:00 | | name | memory_policy | +---------------------+-------------------------------------------------------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

定義に対してポイントも自動的に計算されていることに注意してください。 この値は式によって計算されます：

ポイント=タイムスパン/粒度



保存されたメトリックの値が占める場所を計算する必要があります。

Gnocchi開発者は 、次の式を使用して必要な場所を計算することをお勧めします。

サイズ（バイト単位）= 8 *ポイント*集計方法



情報は常に圧縮形式で保存されるため、指定された式は最悪の場合の場所の計算です。 この式を使用して、memory_policyアーカイブポリシーのスペース量を計算できます。 最初の決定（7日間で1時間の精度）では、4032バイトを取得します。

4032（バイト）= 8 * 168 * 3



そして、2番目の定義（年間を通して1日の精度）の場合、8760バイトが得られます。

8760（バイト）= 8 * 365 * 3



取得した値は、 memory_policyポリシーに従って保存された1つのメトリックの使用済みスペースを反映しています。

たとえば、2000個の仮想マシンのmemory.usageとmemory.residentの2つのメトリックの収集を開始する場合、以下が必要です。

2000 * 2 * 4032（バイト）= 16.128 MB（7日間）

2000 * 2 * 8760（バイト）= 35.04 MB（1年間）

ニョッキのリソース

Gnocchiに保存されるすべてのメトリックは、いくつかのリソースを参照します。 リソースは、複数のメトリックを含むことができる抽象オブジェクトであり、このリソースのタイプで説明されている追加のフィールドを持つこともできます。

オブジェクトメトリック-リソース-リソースタイプの関係は次のようになります。



たとえば、タイプinstance_memoryのリソースのセットがあります 。 このタイプの各リソースには、 memory.usageおよびmemory.residentメトリックが含まれます 。

2000台の仮想マシンからメトリックを収集すると、 instance_memoryリソースの数も2000になります。

このようなリソースの場合、追加情報、たとえば、仮想マシンが実行されているハイパーバイザーのホスト名、または仮想マシンの作成元のオペレーティングシステムイメージ（ OpenStack Glanceサービスに格納されている）の識別子を格納すると役立つ場合があります。



consoleコマンドを使用して、 instance_memoryリソースタイプを作成します 。 説明されている追加のhost 、 image_refフィールドを指定して、ホスト名とイメージ識別子を保存し、 ホストフィールドを必須にします。

 controller:~# gnocchi resource-type create instance_memory \ > -a host:string:true:min_length=0:max_length=255 \ > -a image_ref:string:false:min_length=0:max_length=255
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

応答として、作成されたリソースタイプの説明を取得します。

 +----------------------+-----------------------------------------------------------+ | Field | Value | +----------------------+-----------------------------------------------------------+ | attributes/host | max_length=255, min_length=0, required=True, type=string | | attributes/image_ref | max_length=255, min_length=0, required=False, type=string | | name | instance_memory | | state | active | +----------------------+-----------------------------------------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、 instance_cpuおよびinstance_diskリソースタイプを作成します 。 最初のフィールドにはinstance_memoryと同じ追加フィールドがあり、2番目のフィールドにはディスクが接続されているサーバーの識別子を示すinstance_idフィールドがあります 。

 controller:~# gnocchi resource-type create instance_cpu \ > -a host:string:true:min_length=0:max_length=255 \ > -a image_ref:string:false:min_length=0:max_length=255 +----------------------+-----------------------------------------------------------+ | Field | Value | +----------------------+-----------------------------------------------------------+ | attributes/host | max_length=255, min_length=0, required=True, type=string | | attributes/image_ref | max_length=255, min_length=0, required=False, type=string | | name | instance_cpu | | state | active | +----------------------+-----------------------------------------------------------+ controller:~# gnocchi resource-type create instance_disk \ > -a instance_id:uuid:true +------------------------+--------------------------+ | Field | Value | +------------------------+--------------------------+ | attributes/instance_id | required=True, type=uuid | | name | instance_disk | | state | active | +------------------------+--------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、作成されたリソースタイプを使用してCeilometerメトリックのGnocchiへの保存を開始する方法を理解しましょう。

Ceilometer + Gnocchiの構成

CeilometerがバックエンドとしてGnocchiの使用を開始するには、次のものが必要です。



1. meter_dispatchersオプションをceilometer.confファイルに追加します。

 [DEFAULT] meter_dispatchers = gnocchi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. CeilometerメトリックとGnocchiリソースタイプの対応を記述し、リソースタイプの追加フィールドも示すgnocchi_resources.yamlファイルを作成します。

 --- resources: - resource_type: instance_memory #      metrics: - 'memory.usage' #       - 'memory.resident' #        attributes: host: resource_metadata.instance_host #      image_ref: resource_metadata.image_ref #      - resource_type: instance_disk #      metrics: - 'disk.device.read.bytes' #        - 'disk.device.write.bytes' #        attributes: instance_id: resource_metadata.instance_id #   id   - resource_type: instance_cpu #      metrics: - 'cpu_util' #       attributes: host: resource_metadata.instance_host #      image_ref: resource_metadata.image_ref #     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ceilometerを起動すると、データの収集とGnocchiへの送信が開始されます（ ドキュメントに従って構成されている場合 ）。



次のコマンドを使用して、新しいデータの処理ステータスを監視し、選択したストレージに集計形式で保存できます。

 controller:~# gnocchi status +-----------------------------------------------------+-------+ | Field | Value | +-----------------------------------------------------+-------+ | storage/number of metric having measures to process | 93 | | storage/total number of measures to process | 93 | +-----------------------------------------------------+-------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の結論では、Gnocchi-metricdが93個のメトリックに分散した93個の測定を処理することがわかります。



このコマンドを使用すると、Gnocchi-metricdコンポーネントが着信メトリックを処理するかどうかを監視できます。



処理速度は、Gnocchiメトリックプロセスの数と選択したデータウェアハウスのパフォーマンスに直接依存します。

集約された情報を表示する

受信した測定値を処理して保存すると、Gnocchiのリソースと測定値にアクセスできるようになります。



instance_memoryタイプでリソースを導出し、出力を3つのリソースに制限し、リソース自体の識別子、そのタイプ、仮想マシンのホスト名、およびイメージの識別子の4列のみを表示します。

 controller:~# gnocchi resource list --type instance_memory --limit 3 --column id --column type --column host --column image_ref +--------------------------------------+-----------------+-----------+--------------------------------------+ | id | type | host | image_ref | +--------------------------------------+-----------------+-----------+--------------------------------------+ | 945ad3cc-2617-4b19-a681-5a1cb96d71e1 | instance_memory | compute00 | 3456e843-b7fe-42be-8c4c-0c7d1c2d09c7 | | e33c895f-e38a-4f8e-be07-8fe0d7c8275f | instance_memory | compute02 | 27bbfeb7-0706-4d11-bb59-f98d6b08dc1c | | 023fed66-3fdd-43b6-b02e-325da55b62cc | instance_memory | compute04 | f0f5e0aa-4615-462e-8340-b8258aae90e2 | +--------------------------------------+-----------------+-----------+--------------------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リソース945ad3cc-2617-4b19-a681-5a1cb96d71e1のメトリックとタイプの列を表示します。

 controller:~# gnocchi resource show --column metrics --column type 945ad3cc-2617-4b19-a681-5a1cb96d71e1 +---------+-------------------------------------------------------+ | Field | Value | +---------+-------------------------------------------------------+ | metrics | memory.resident: f56b76ad-5ce8-49fe-975f-6e5da412df31 | | | memory.usage: aa757f46-52b9-40de-898c-524dfe29b7bc | | type | sel_instance | +---------+-------------------------------------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メトリックaa757f46-52b9-40de-898c-524dfe29b7bcを測定するための平均値を、 2017年8月25日の12:00から18:00の間隔で、1時間の精度で見てみましょう。

 controller:~# gnocchi measures show --aggregation mean --granularity 3600 --start 2017-08-25T12:00 --stop 2017-08-25T18:00 aa757f46-52b9-40de-898c-524dfe29b7bc +---------------------------+-------------+---------------+ | timestamp | granularity | value | | +---------------------------+-------------+---------------+ | 2017-08-25T12:00:00+00:00 | 3600.0 | 2231.75 | | 2017-08-25T13:00:00+00:00 | 3600.0 | 2238.66666667 | | 2017-08-25T14:00:00+00:00 | 3600.0 | 2248.58333333 | | 2017-08-25T15:00:00+00:00 | 3600.0 | 2259.08333333 | | 2017-08-25T16:00:00+00:00 | 3600.0 | 2240.41666667 | | 2017-08-25T17:00:00+00:00 | 3600.0 | 2249.66666667 | +---------------------------+-------------+---------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

集約された情報は、コンソールユーティリティだけでなく、REST APIを使用して取得できます。 いくつかの例を見てみましょう。



2017年8月28日から24時間の精度で、タイプinstance_memoryのリソースのmemory.usageメトリックの値を取得します。

 controller:~# curl -XGET \ > -H 'Content-Type: application/json' \ > -H 'X-Auth-Token: KEYSTONE_TOKEN' \ > 'controller:8041/v1/resource/instance_memory/684f5b56-2c06-485a-ae1a-66ab5c4175fb/metric/memory.usage/measures?start=2017-08-28&granularity=86400' \ > | python -m json.tool [ [ "2017-08-28T00:00:00+00:00", 86400.0, 2645.9444444444443 ], [ "2017-08-29T00:00:00+00:00", 86400.0, 2671.625 ], [ "2017-08-30T00:00:00+00:00", 86400.0, 2681.5438596491226 ] ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホストフィールドの値が「compute19」で2017年8月29日以降に作成されたinstance_memoryタイプのリソースを検索します。

 controller:~# curl -XPOST \ > -H 'Content-Type: application/json' \ > -H 'X-Auth-Token: KEYSTONE_TOKEN' \ > 'controller:8041/v1/search/resource/instance_memory \ > -d '{ > "and": [ > { > "=": { > "host": "compute19" > } > }, > { > ">": { > "started_at": "2017-08-29" > } > } > ] > }' \ > | python -m json.tool [ { "created_by_project_id": "99288fd3d178459f808c1e8bc2cf9e49", "created_by_user_id": "7dd0582d38aa471bbe8995f63a1293a9", "creator": "7dd0582d38aa471bbe8995f63a1293a9:99288fd3d178459f808c1e8bc2cf9e49", "ended_at": null, "host": "compute19", "id": "9052e237-ad17-47be-8aa5-10aacbf6717f", "image_ref": "e12ef13d-783c-4030-9251-ad2c8e270453", "metrics": { "memory.resident": "365db8ce-f4f7-4e59-ac9f-03dcdfe81195", "memory.usage": "084157b7-09d3-45e7-a869-fad62062025a" }, "original_resource_id": "9052e237-ad17-47be-8aa5-10aacbf6717f", "project_id": "99288fd3d178459f808c1e8bc2cf9e49", "revision_end": null, "revision_start": "2017-08-30T20:35:19.214598+00:00", "started_at": "2017-08-30T20:35:19.214577+00:00", "type": "instance_memory", "user_id": "7dd0582d38aa471bbe8995f63a1293a9" } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

compute19ホストで実行されている仮想マシンについて、最大1時間の精度でmemory.residentメトリックの最大値による集計を取得します。 メトリックはプロジェクト識別子によって体系化されます：

 controller:~# curl -XPOST \ > -H 'Content-Type: application/json' \ > -H 'X-Auth-Token: KEYSTONE_TOKEN' \ > 'controller:8041/v1/aggregation/resource/instance_memory/metric/memory.resident&aggregation=max&granularity=3600&groupby=project_id' \ > -d '{ > "=": { > "host": "compute19" > } > }' \ > | python -m json.tool [ { "group": { "project_id": "eef577b17cfe4432b7769d0078dbb625" }, "measures": [ [ "2017-08-29T09:00:00+00:00", 3600, 735 ], [ "2017-08-30T11:00:00+00:00", 3600, 949 ] ] }, { "group": { "project_id": "b998dbbb9b02474c9dc49ffc289eae8c" }, "measures": [ [ "2017-08-29T09:00:00+00:00", 3600, 612 ], [ "2017-08-30T11:00:00+00:00", 3600, 642 ] ] } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

REST APIのその他の使用例は、 公式ドキュメントに記載されています 。

VPCサービスの統計

現在、 VPCサービスで説明されているコンポーネントを使用しています。



ユーザーは、仮想マシンの次のメトリックを使用できます。

• CPU使用率、％（ cpu_util ）;
• RAM使用量（MB 単位 ）（ memory.usage ）。

ドライブ指標：

• 読み取りおよび書き込みのバイト数/ c（ disk.device.read.bytes 、 disk.device.write.byte s）;
• 1秒あたりの読み取りおよび書き込み要求の数（ disk.device.read.requests 、 disk.device.write.requests ）。

ネットワークインターフェイスのメトリック：

• 着信および発信トラフィックのビット数/ c（ network.incoming.bits 、 network.outgoing.bits ）;
• 1秒あたりの着信および発信トラフィックのパケット数（ network.incoming.packets 、 network.outgoing.packets ）。

すべてのデータは、REST APIまたはGnocchiコンソールクライアントを介して、またはサーバーコントロールパネルの組み込みグラフの形式で受信できます。

CPU使用率グラフ

RAM使用量グラフ

ディスク負荷グラフ

ネットワークインターフェイスの負荷チャート

おわりに

この記事では、OpenStackオブジェクトに関する統計を収集、保存、表示するための2つのコンポーネントを調べました。



ご質問があれば、コメントしてください。



独自のデータを作成できるサービスとしてgnocchiを試してみたい場合は、それについてお問い合わせください。



CeilometerまたはGnocchiを使用して自分の経験を共有していただければ幸いです。