APIの見える化 - Prometheus/Swagger

APIエコノミーにおける監視の課題

「SQL実行が失敗すると、DBサーバのエラーログを検知し、パトランプが鳴り、さらにはメールにて開発担当者に通知される」――皆さんもそんな現場を見聞きしたことがあるでしょう。システムの円滑な運用には、システムの異常を「即座に検知」することは欠かせません。

エラー監視のみならず、リソース監視と呼ばれるサーバのメモリやディスクといったリソースが枯渇し、システムが停止するのを未然に防ぐ、いわば「予兆検知」も必要な要素です。

DBサーバ単体のSQL処理は早いのに、WebAPサーバのスレッド処理の待ちにより処理時間が長期化する。サーバ単体での問題だけでなく、「サーバ間」の要素が絡み合ったケースもあるため、システムのどこに問題があるのかをさまざまな解析手順により明らかにしていきます。例えば、Tera Term画面を何枚も並べ、各サーバのログをタイムリーに眺めつつ、OracleのAWRやTomcatのスレッドダンプを確認するといった作業があります。

クラウド化、マイクロサービス化が進展するシステムでは、「システム間」「API間」の連携に伴う問題が発生するケースもあり、こういったケースに対応する新しい監視方法が求められます。

Prometheusを使ったAPIの監視

システムの運用に必須の監視ツールはIBM TivoliやHP OpenviewやNTTデータのHinemosなど、さまざまなものがありますが、今回はPrometheusをご紹介しましょう。

PrometheusはGoogleの監視ツールのBorgmonに影響を受けて作成された監視ツールです。オープンソースでインストールが簡易であり、動的にサーバの数が変化するクラウドやAPIを駆使したシステムに適した監視ツールとして注目が集まっています。

Prometheusをインストールしてみましょう。「DOWNLOAD」をクリックし、OSに合わせてPrometheusをダウンロードします。

以下の通り、解凍するのみでインストール完了です。

$ tar xvf prometheus-1.5.2.darwin-amd64.tar
x prometheus-1.5.2.darwin-amd64/
x prometheus-1.5.2.darwin-amd64/consoles/
x prometheus-1.5.2.darwin-amd64/consoles/aws_elasticache.html
x prometheus-1.5.2.darwin-amd64/consoles/aws_elb.html

prometheusのフォルダに移動し、prometheusコマンドにて起動します。

$ cd prometheus-1.5.2.darwin-amd64
$ ./prometheus -config.file=prometheus.yml
INFO「0000」 Starting prometheus (version=1.5.2, branch=master, revision=bd1182d29f462c39544f94cc822830e1c64cf55b)  source=main.go:75
INFO「0000」 Build context (go=go1.7.5, user=root@a8af9200f95d, date=20170210-14:44:53)  source=main.go:76
INFO「0000」 Loading configuration file prometheus.yml     source=main.go:248
INFO「0000」 Loading series map and head chunks...         source=storage.go:373
INFO「0000」 0 series loaded.                              source=storage.go:378
INFO「0000」 Starting target manager...                    source=targetmanager.go:61
INFO「0000」 Listening on :9090                            source=web.go:259

実際にPrometheusを操作する前に、起動時に指定したprometheus.ymlを確認してみましょう。

「global」にてジョブ共通設定を行います。データの抽出及び評価間隔を15秒にしています。「prometheus」ジョブを定義し、自分自身である「http://localhost:9090/」を監視対象にしています。

$ cat prometheus.yml
# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'codelab-monitor'

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: 'prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: 「'localhost:9090'」

それでは、先ほど起動したPrometheusを操作します。ブラウザから「http://localhost:9090/」にアクセスします。

Prometheusの特徴の一つであるクエリを体感してみましょう。

「Expression」テキストボックスにメトリクスの一つで、Prometheus自身の情報を出力した「prometheus_target_interval_length_seconds」を入力し、「Execute」をクリックします。

「Graph」ビューに切り替えると以下の通り時系列のデータが表示されます。

Grafanaとの組み合わせ

Prometheusによる監視の一歩進んだ形として、Grafanaとの組み合わせがあります。

dockerコマンドによりGrafanaをインストールおよび起動します。

$ docker run -d --name=grafana -p 3000:3000 grafana/grafana
Unable to find image 'grafana/grafana:latest' locally
latest: Pulling from grafana/grafana
43c265008fae: Pull complete
c2ab838d4052: Pull complete
e8a816c8f505: Pull complete
Digest: sha256:05d925bd64cd3f9d6f56a4353774ccec588586579ab738f933cd002b7f96aca3
Status: Downloaded newer image for grafana/grafana:latest
c784cb65e1acd114375a45fccf904b04bd963e299d39f2673b9847ea93ba3406

ブラウザから「http://localhost:3000/」にアクセスします。UserおよびPasswordに「admin」を指定し「Log in」をクリックします。

Home Dashboard画面が表示されました。GrafanaではDashboardに対してPanelと呼ばれるグラフなどの情報を配置します。

「Add data source」をクリックし、表示する情報源のデータを設定しましょう。

以下の通り設定し、「Add」をクリックします。

データソースが追加されました。

「Dashboards」タブにて「Import」ボタンをクリックし、ダッシュボードとしてインポートします。

インポートが完了し、以下の画面が表示されます。

「Grafana」アイコンをクリックし、「Dashboards」-「Home」をクリックします。

Home DashboardにPrometheus Statsダッシュボードが追加されています。「Prometheus Stats」をクリックし、Prometheusのデータを確認します。

Prometheusの複数のクエリ実行結果が並んで表示されています。冒頭にも記載の「Tera Term画面を何枚も並べ、各サーバのログをタイムリーに眺め」相当のことがGrafanaのダッシュボード一つで実現可能となります。

Tera Term画面に一つ一つログインして、該当のログをTailコマンドで表示する作業の煩わしさから解放されるのはもちろん、そういった操作に不慣れな担当者でも扱えます。

なお、前述のPrometheusで表示したグラフと同等のものは「Scrape Duration」に表示されています。

Swaggerを利用したドキュメンテーション

「Androidのアプリから叩いているサーバのAPIが機能追加されたために、3日間かけてテストして終わったと思ったら、いつのまにかさらなる仕様変更が入っていた」「APIのインタフェースを定義するドキュメントの仕様に従ってアクセスしたら、実は実装との乖離があり、うまく動かなかった」

このようにAPIプロバイダとAPIコンシューマ間の悩みはさまざまです。APIエコノミーを作るにあたり、このようなことを起こさないためにも、API間のインタフェースを記述したAPIドキュメントが必要となってきます。また、ドキュメントと実装との整合性をとる作業は必須となります。

Swaggerは上記課題の解決のアプローチを提供します。SwaggerはOAI(Open API Initiative)が採用しているREST APIを構築するためのオープンソースのフレームワークです。OAIは、2015年11月に米Microsoftや米Googleなどによって結成され、Swaggerを用いてAPIの標準化を推し進めています。

SwaggerはSwagger Specを中核におき、以下のようなツール群で構成されます。Swaggerに関する詳細は拙著「Swagger入門 - 初めてのAPI仕様管理講座」をご参照ください。

*　　*　　*

今回はPrometheusを使ったAPIの監視方法と、Swaggerを使ったドキュメンテーションについて紹介しました。前回紹介したZipkinにてAPI依存関係を、Kibanaを使ってログの見える化をすることができ、APIの見える化技術が出揃ってきた印象があります。システム開発の要件などに合わせ、一つでも二つでも導入を検討してみてはいかがでしょうか

次回はAPI Managementを紹介します。せっかく作ったAPI群をどう管理していけば良いかについて、理解を深めていただきます。