1.0が出てたのでPrometheusに入門してみた

もう3週間前くらいですが、Pull型という珍しいアーキテクチャの監視ツールである[Prometheus1.0がリリース](https://prometheus.io/blog/2016/07/18/prometheus-1-0-released/)されました。最近は日本でも[Prometheus Casual Talk](http://connpass.com/event/32859/)が開催されるなど導入事例も増えてきたようなので、今後の導入を視野に入れて触ってみました。

# 特徴

自分が見た範囲で気になった特徴としては、以下のようなものがありました。

* Go製
* アラート機能が無償で利用可能(例えばELKスタック使う場合、[Watcher](https://www.elastic.co/guide/en/watcher/current/actions.html)がありますが、利用には有償契約が必要)
* 扱えるのは数値のみ(ログ等で文字列を扱う場合は別のツール等が必要)
* Pull型<br/>
監視ツールはPush型(監視対象側が監視ツールに情報を送る)のものが多いと思いますが、PrometheusはPull型(Prometheusが監視対象の情報を取得する)です。理由は[ここ](https://prometheus.io/docs/introduction/faq/#why-do-you-pull-rather-than-push?)に書いてありますが、ラップトップ等で気軽に監視ツールを実行できること、ターゲットが落ちている場合の判断が楽なこと(Push型だとターゲットがエラーで落ちたのかメンテで落ちたのかの判断が監視ツールにはできない)、ターゲットの状態をブラウザ等から確認できる、といった点が上げられています。ただし、Prometheusにも[Pushgateway](https://prometheus.io/docs/instrumenting/pushing/)という機能があり、Pushすることも可能です。(バッチ処理の結果送信等限られた用途でのみ使うことが推奨されています)

# 使ってみる

一通り機能を確認していきたいと思います。
[前回の記事](http://qiita.com/kiida/items/6dac109dcd063609b064)でdocker1.12で追加されたswarmモードを使ってみたので、今回もswarmモードで構築しましたが、あんまり相応しい例ではなかったと思います。(Prometheus自体とは関係ないので理由は最後に記載)

swarm使ってやる場合はdocker-machinとdockerがインストールされてさえいれば、上記の記事を読まなくても構築できるように書いていますが、それぞれのコマンドがどのような意味か知りたい場合は上記の前回の記事を参照してください。
swarmを使わない場合は適宜docker runとかに読み替えて貰えればと思います。

インフラはDigitalOceanを使います。[こちら](https://m.do.co/c/7be3336a0400)から登録して頂けるとお互いハッピーなので(ry

## Prometheusの構築と自身の監視

まずはswarmのmanagerを作成します。

```bash
# manager用のホストを作成
$ docker-machine create -d digitalocean --digitalocean-image "ubuntu-16-04-x64" --digitalocean-region "sfo1" --digitalocean-size "512mb" --digitalocean-access-token ${DIGITALOCEAN_API_TOKEN} manager
(結果略)

# managerのIPをメモる
$ docker-machine ls
NAME           ACTIVE   DRIVER         STATE     URL                          SWARM   DOCKER    ERRORS
manager        *        digitalocean   Running   tcp://104.131.149.142:2376           v1.12.0

# swarmモードを初期化
$ eval $(docker-machine env manager)
$ docker swarm init --advertise-addr 104.131.149.142

# 以下のような出力が得られるのでworkerを追加するコマンド(1個目)を控えておく
To add a worker to this swarm, run the following command:
    docker swarm join \
    --token SWMTKN-1-12wn17zowr4ysj089mb4s0zijbwexx6w3oucz77k87uwkmxlsu-e9lv6z80x48hx42mxz50t0l6g \
    104.131.149.142:2377

To add a manager to this swarm, run the following command:
    docker swarm join \
    --token SWMTKN-1-12wn17zowr4ysj089mb4s0zijbwexx6w3oucz77k87uwkmxlsu-en1rtjwtlujupv16qqjja9xda \
    104.131.149.142:2377
```

続いてPrometheus用のDockerホストを作ります。

```bash
# Prometheus用のホストを作成
docker-machine create -d digitalocean --digitalocean-image "ubuntu-16-04-x64" --digitalocean-region "sfo1" --digitalocean-size "2gb" --digitalocean-access-token ${DIGITALOCEAN_API_TOKEN} prometheus
(結果略)

# prometheusノードをswarmクラスタに追加
$ eval $(docker-machine env prometheus)
$ docker swarm join \
--token SWMTKN-1-12wn17zowr4ysj089mb4s0zijbwexx6w3oucz77k87uwkmxlsu-e9lv6z80x48hx42mxz50t0l6g \
104.131.149.142:2377
```

以下のような自身を監視する最小限のconfigを作ります。

```bash
mkdir prometheus
vi prometheus/prometheus.yml
```

```bash:prometheus.ymlの中身
global:
  scrape_interval:     15s
  external_labels:
    monitor: 'codelab-monitor'
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']
```

何を設定しているかはラベルから分かると思いますが、詳細は[公式ページ](https://prometheus.io/docs/operating/configuration/)を見て頂ければと思います。

一旦、Prometheusを起動します。

```bash:Prometheusの起動
# 設定ファイルディレクトリをDockerホストにコピー
docker-machine scp -r prometheus prometheus:/opt/

# managerでdockerコマンドを実行するように指定
eval $(docker-machine env manager)

# prometheusサービスをprometheusホストでのみ起動するよう作成
docker service create \
  --replicas 1 \
  --name prometheus \
  --publish 9090:9090 \
  --mount type=volume,source=/opt/prometheus,target=/etc/prometheus \
  --constraint node.hostname==prometheus \
  prom/prometheus
```

これで`http://<prometheus_ip>:9090/metrics`にアクセスすると以下のようなメトリクスの一覧が出てきます。
PrometheusのIPはdocker-machine lsなどで調べてください。

![Screenshot from 2016-08-03 17-54-57.png](https://qiita-image-store.s3.amazonaws.com/0/36003/99d1e015-f339-f13d-cf20-fea7e1c466cf.png)

`http://<prometheus_ip>:9090/graph`からGraphタブまたはConsoleタブを選ぶとそれぞれグラフとコンソールが表示されます。

まずはコンソールタブを選択して、/metricsででてきた一覧から適当にメトリクス名を入力して実行してみます。メトリクスの種類やクエリの書き方等は後述しますが、今回は試しにgo_goroutinesというメトリクスを使ってみました。

![Screenshot from 2016-08-03 22-14-33.png](https://qiita-image-store.s3.amazonaws.com/0/36003/f83f0226-1d8e-30dc-06fd-4ecf774c1bd3.png)

続いてグラフタブを開くとこのようになります。

![Screenshot from 2016-08-03 22-16-57.png](https://qiita-image-store.s3.amazonaws.com/0/36003/565a42db-891d-8133-08eb-053c34e0631d.png)

時間軸等は変更できます。

## 別の監視対象を追加

ここまでだとprometheus自体のメトリクスしか取れていないので、別の監視対象を追加してみたいと思います。

### exporter

OS自体のメトリクスや既存のソフトウェアのメトリクスを取得したい場合は[exporter](https://prometheus.io/docs/instrumenting/exporters/)を使います。MySQLやHAProxy等有名どころのexporterは公式またはサードパーティのものが利用できます。なお、kubernetesやetcd等はPrometheus向けのメトリクスをデフォルトでexposeしているのでexporter不要でメトリクスを取得できます。

今回は例としてシステムのメトリクスを取得する[node exporter](https://github.com/prometheus/node_exporter)を使ってみます。

```bash:node_exporterの起動

# hostネットワークを使うため、swarmではなく通常のdockerコマンドで実行
# manager上で実行
eval $(docker-machine env manager)
docker run -d -p 9100:9100 --net="host" prom/node-exporter

# prometheusノードでも実行
eval $(docker-machine env prometheus)
docker run -d -p 9100:9100 --net="host" prom/node-exporter
```

`http://<対象ノードのIP>:9100/metrics`にアクセスすると先ほどと同様の様々なメトリクスおよびnode exporeterのメトリクスが確認できます。

![Screenshot from 2016-08-04 18-24-09.png](https://qiita-image-store.s3.amazonaws.com/0/36003/a8dcddff-586b-e79a-88a8-f991a2fdc8f7.png)

Prometheusから監視できるようにconfigファイルを以下のように書き換えます。

```bash:prometheus.yml
global:
  scrape_interval:     15s
  external_labels:
    monitor: 'codelab-monitor'
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']
  - job_name:       'node'
    scrape_interval: 5s
    static_configs:
      - targets: ['manager_host_ip:9100']
        labels:
          group: 'manager'
      - targets: ['prometheus_ip:9100']
        labels:
          group: 'worker'
```

configファイル変更時はPrometheusのプロセスにSIGHUPを送るか以下のようなリクエストを送るとリロードできます。ちなみにPOSTですが、configファイル自体を渡すことはできません。([仕様](https://github.com/prometheus/prometheus/issues/1714))

```
# configファイルをホストに送信
docker-machine scp -r prometheus prometheus:/opt/

# curlでリロード
curl -X POST http://prometheus_ip:9090/-/reload
```

監視対象に追加されているはずなので、`http://<prometheus_ip>:9090/graph`のConsoleタブから試しにnode_cpuという名前のメトリクスを確認してみます。

![Screenshot from 2016-08-04 20-08-53.png](https://qiita-image-store.s3.amazonaws.com/0/36003/27ff744a-6c17-df78-1c63-daecf773152c.png)

### クエリの書き方

ここでクエリの書き方を簡単に紹介してみます。
node_cpuを実行した上記のキャプチャにある通り、Elementカラムに様々なラベル付きでnode_cpuの値が表示されているのが分かるかと思います(たとえば、node_cpu{cpu="cpu0",group="worker",instance="192.241.200.47:9100",job="node",mode="idle"})。
この形式はそのままクエリに使えて、例えば
`node_cpu{cpu="cpu0",group="manager",mode="user"}`を実行すると該当のデータのみ取得できます。

![Screenshot from 2016-08-04 20-20-31.png](https://qiita-image-store.s3.amazonaws.com/0/36003/3a750c1e-ff62-ead7-91a7-7a3efe7f6430.png)

ちなみにjobとgroupというラベルは上記のymlファイルで指定したものです。

クエリの書き方の網羅的な説明は[公式ページ](https://prometheus.io/docs/querying/basics/)に載っていますが、例えば以下のように正規表現を使ったり、

`node_cpu{cpu=~"cpu.+",group="worker",mode=~"user|system"}`

以下のように直近5分のデータを表示したり

`node_cpu{cpu=~"cpu.+",group="worker",mode=~"user|system"}[5m]`

直近5分の平均を表示したり

`rate(node_cpu{cpu=~"cpu.+",group="worker",mode=~"user|system"}[5m])`

userとsystemの合計を表示したり

`sum(rate(node_cpu{cpu="cpu0",group="worker",mode=~"user|system"}[5m]))`

色々できます。

そのままグラフタブを開けば該当するデータのグラフが表示されます。

![Screenshot from 2016-08-04 20-51-45.png](https://qiita-image-store.s3.amazonaws.com/0/36003/c5bb773f-529c-f8fb-b883-7a96de1c4070.png)

もちろんexporterは自作もできます。
https://prometheus.io/docs/instrumenting/writing_exporters/

### クライアントを書く

アプリやツール等からメトリクスを取得させたい場合はexporterを書くまでもなくクライアントライブラリを使ってメトリクスを公開することができます。
https://prometheus.io/docs/instrumenting/clientlibs/

Go以外の言語でも書くことができます。

今回はお試しということで以下のような意味のないCounterのサンプルを作りました。Counterの他にもGauge,Summary,Histogramというタイプの[メトリクス](https://prometheus.io/docs/concepts/metric_types/)があります。

ちなみに[ここ](https://hub.docker.com/r/daikikohara/prometheus-client/)にpublishしてあるので以下のプログラムとDockerfileは作らなくてOKです。

```go
package main

import (
	"math/rand"
	"net/http"
	"time"

	"github.com/prometheus/client_golang/prometheus"
)

func main() {
	pushCounter := prometheus.NewCounter(prometheus.CounterOpts{
		Name: "sample_counter",
		Help: "just a simple counter",
	})
	prometheus.MustRegister(pushCounter)

	go func() {
		for {
			pushCounter.Inc()
			time.Sleep(time.Duration(rand.Intn(1000)) * time.Millisecond)
		}
	}()

	http.Handle("/metrics", prometheus.Handler())
	http.ListenAndServe(":9111", nil)
}
```

alpineで動かすのでこんな感じでビルドします。

`CGO_ENABLED=0 go build`

こんな感じのDokcerfileを作ります。

```
FROM alpine:latest
ADD prometheus /
CMD /prometheus
````

このタスクを実行するサービスを作ります。

```
docker service create \
  --replicas 1 \
  --name sample-client \
  --publish 9111:9111 \
  daikikohara/prometheus-client:v1
```

swarmノードの任意のIP:9111/metricsにアクセスするとデフォルトのメトリクスに加えて追加したsample_counterというメトリクスが表示されています。

![Screenshot from 2016-08-05 00-45-03.png](https://qiita-image-store.s3.amazonaws.com/0/36003/263ac757-cb38-617b-6f9c-a7936aacd265.png)

Prometheusの監視対象に追加するには以下のようなセクションを追加し、

```
  - job_name:       'sample'
    scrape_interval: 5s
    static_configs:
      - targets: ['sample-clientが動いているノードのIP:9111']
```

リロードします。

```
docker-machine scp -r prometheus prometheus:/opt/
curl -X POST http://prometheus_ip:9090/-/reload
```

WebUIからグラフも表示できます。

![Screenshot from 2016-08-05 15-32-23.png](https://qiita-image-store.s3.amazonaws.com/0/36003/2b2eb5b0-d761-6b8e-b290-f90790b8407e.png)

## Recording rule

[Recording rule](https://prometheus.io/docs/querying/rules/)を使うとよく使うクエリの結果等を別のメトリクスとして取得できるようになります。これは元のクエリを都度実行するより効率的で、特にダッシュボード等で頻繁に実行されるケースでは有利みたいです。

お試しということで、ローカルのprometheus/prometheus.rulesファイルを以下のような内容で作成します。

```bash:prometheus.rules
sample_rule:node_cpu_user:avg_rate5m = avg(rate(node_cpu{mode="user"}[5m])) by (instance, cpu)
```

ルールの書き方が正しいかは以下のツールでチェックできます。

```bash
$ go get github.com/prometheus/prometheus/cmd/promtool
$ promtool check-rules ./prometheus.rules
Checking ./prometheus.rules
  SUCCESS: 1 rules found
```

prometheus.ymlを以下のように書き換えます。追加したのはevaluation_intervalとrule_filesです。ルールの評価を15秒ごとに行うというものです。

```
global:
  scrape_interval:     15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'codelab-monitor'
rule_files:
  - 'prometheus.rules'
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']
  - job_name:       'node'
    scrape_interval: 5s
    static_configs:
      - targets: ['manager_ip:9100']
        labels:
          group: 'manager'
      - targets: ['prometheus_ip:9100']
        labels:
          group: 'worker'
  - job_name:       'sample'
    scrape_interval: 5s
    scrape_timeout: 3s
    static_configs:
      - targets: ['prometheus_ip:9111']
```

ルールとconfigファイルをPrometheusのホストに送ってリロードします。

```
docker-machine scp -r prometheus prometheus:/opt/
curl -X POST http://prometheus_ip:9090/-/reload
```

設定したルール名でグラフが取得できるようになっています。

![Screenshot from 2016-08-05 18-45-55.png](https://qiita-image-store.s3.amazonaws.com/0/36003/1056119a-3e34-a301-32cc-d163b42ce31c.png)

## Alertmanager

[Alertmanager](https://prometheus.io/docs/alerting/alertmanager/)を使うと様々な条件でアラートの送信ができるようになります。
AlertmanagerはPrometheusとは別のプロセスで、Prometheus上でruleを設定してAlertmanagerにアラートを送信、Alertmanagerが送られてきたアラートを条件に従って様々な通知先に送信する等のハンドリングを行うという挙動になっています。

送信先はemailやSlack等様々なものに対応しています。

ルールも様々なものが設定できます。
[公式ページ](https://prometheus.io/docs/alerting/alertmanager/)で触れられているものだとGrouping(例えばDBが落ちたら発生するエラー等は1つのインスタンスから受信できれば良いので、同じ種類のアラートはまとめる)、Inhibition(あるグループのアラートが既に発生していたら別のアラートは発生させない)、Silence(特定のアラートを一定時間発生させない)といったタイプのルールがあります。

とりあえず今回は[公式ページの例](https://prometheus.io/docs/alerting/rules/)にあるインスタンスがダウンした場合のアラートを試しみてます。送信先はSlackで試してみました。

まずはalertmanager用のディレクトリをローカルに作って、設定ファイルを作成します。

```
mkdir alertmanager
vi alertmanager/config.yml
```

```bash:config.yml
global:
route:
  receiver: main
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
receivers:
- name: 'main'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/your_api_token'
    channel: '#channel_name'
```

次にAlertmanagerを起動します。

```
# alertmaanger用のホストを作成
docker-machine create -d digitalocean --digitalocean-image "ubuntu-16-04-x64" --digitalocean-region "sfo1" --digitalocean-size "2gb" --digitalocean-access-token ${DIGITALOCEAN_API_TOKEN} alertmanager

# swarmクラスタに追加
eval $(docker-machine env alertmanager)
docker swarm join \
--token SWMTKN-1-12wn17zowr4ysj089mb4s0zijbwexx6w3oucz77k87uwkmxlsu-e9lv6z80x48hx42mxz50t0l6g \
104.131.149.142:2377

# 設定ファイルをalertmanagerのホストに送信
docker-machine scp -r alertmanager alertmanager:/opt/

# Alertmanager用のサービスの作成
eval $(docker-machine env manager)
docker service create \
  --replicas 1 \
  --name alertmanager \
  --publish 9093:9093 \
  --mount type=volume,source=/opt/alertmanager,target=/etc/alertmanager \
  --constraint node.hostname==alertmanager \
  prom/alertmanager:latest
```

AlertmanagerノードのIP:9093にブラウザからアクセスして以下のような画面が出来きたらOKです。

![Screenshot from 2016-08-05 20-37-23.png](https://qiita-image-store.s3.amazonaws.com/0/36003/57c36427-f54f-2d57-f3be-3d4f53bebe27.png)

続いてPrometheus側にアラートルールを追加します。prometheusディレクトリに以下のようなファイルを作成します。

```bash:alert.rules
ALERT InstanceDown
  IF up == 0
  FOR 1m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }
```

上記のファイルをprometheus.ymlから参照します。

```bash:該当箇所のみ
rule_files:
  - 'prometheus.rules'
  - 'alert.rules'
```

Prometheusのコンテナ側も設定を変更する必要がありますが、公式のDocker imageではAlertmanagerに接続できないので、以下のようなDockerfileを作成して[こちら](https://hub.docker.com/r/daikikohara/prometheus/)に置きました。

```bash:Dockerfile
FROM prom/prometheus
ENTRYPOINT [ "sh" ]
CMD [ "-c", \
      "/bin/prometheus \
      -config.file=/etc/prometheus/prometheus.yml \
      -storage.local.path=/prometheus \
      -alertmanager.url=${ALERTMANAGER}" ]
```

一度元のprometheusサービスを落としてから上記のイメージを使ったprometheusサービスを実行します。

```bash
# サービスを削除
$ docker service rm prometheus

# 設定ファイルをホストに送信
$ docker-machine scp -r prometheus prometheus:/opt/

# サービスを再作成
$ docker service create \
  --replicas 1 \
  --name prometheus \
  --publish 9090:9090 \
  --mount type=volume,source=/opt/prometheus,target=/etc/prometheus \
  --env ALERTMANAGER="http://alertmanager_ip:9093" \
  --constraint node.hostname==prometheus \
  daikikohara/prometheus:v1
```

おもむろに監視対象のコンテナを一つ落としてみます。

```bash
# manager上のdockerプロセスを確認
$ docker ps
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS               NAMES
57aa0d720403        prom/node-exporter                 "/bin/node_exporter"     2 hours ago         Up 2 hours                              suspicious_keller
9687d44ae859        daikikohara/prometheus-client:v1   "/bin/sh -c /promethe"   7 hours ago         Up 7 hours                              sample-client.1.2zkn3wtvw37f8fiy6xqfhui4n

# node_exporterのプロセスを停止
$ docker stop suspicious_keller
suspicious_keller
```

ここでAlertタブから確認するとPENDINGになっています。

![Screenshot from 2016-08-05 23-23-42.png](https://qiita-image-store.s3.amazonaws.com/0/36003/3a008a6c-d5d5-276c-4b74-1a987df2d7a2.png)

1分以上経過してから再確認するとStateがFIRINGに変わりました。

![Screenshot from 2016-08-05 23-28-41.png](https://qiita-image-store.s3.amazonaws.com/0/36003/32fb7fa3-8d59-87d0-de8a-b84a7f1914e1.png)

Alertmanagerにも通知されています。

(キャプチャ撮り忘れ)

Alertmanager経由でSlackにも通知されています。

![Screenshot from 2016-08-08 00-38-02.png](https://qiita-image-store.s3.amazonaws.com/0/36003/a444c13a-518f-0f64-2c67-8cc02dd9e6d8.png)

## Grafana連携

これまで見てきた通りPrometheus自身にもグラフの機能がありますが、あまりパワフルではないため、[Grafana](https://prometheus.io/docs/visualization/grafana/)と連携することを公式でも推奨しています。[Grafana](http://docs.grafana.org/)は様々なメトリクスを可視化するツールで、Prometheus以外にもInfluxDBやCloudWatch等様々なデータソースに対応しています。

まずはGrafana用のマシンとサービスを作成します。

```bash
# Grafana用のホストを作成
$ docker-machine create -d digitalocean --digitalocean-image "ubuntu-16-04-x64" --digitalocean-region "sfo1" --digitalocean-size "2gb" --digitalocean-access-token ${DIGITALOCEAN_API_TOKEN} grafana

# grafanaノードをswarmクラスタに追加
$ eval $(docker-machine env grafana)
$ docker swarm join \
--token SWMTKN-1-12wn17zowr4ysj089mb4s0zijbwexx6w3oucz77k87uwkmxlsu-e9lv6z80x48hx42mxz50t0l6g \
104.131.149.142:2377

# Grafana用のサービスを作成
$ docker service create \
  --replicas 1 \
  --name grafana \
  --publish 3000:3000 \
  --constraint node.hostname==grafana \
  grafana/grafana

```

GrafanaのノードのIP:3000にアクセスしたらログイン画面が出てきます。

![Screenshot from 2016-08-08 12-01-14.png](https://qiita-image-store.s3.amazonaws.com/0/36003/619e1ed1-feb0-6c48-0ed8-739d5abfa490.png)

今回はデフォルトなのでadmin/adminでログインします。

Prometheusのデータソースを追加するには、

* logoクリック
* Data Sourcesクリック
* Add data sourceをクリック
* Nameに適当な名前を入力
* Defaultにチェック(オプショナル)
* Type をPrometheusに変更
* UrlをPrometheusのURLに変更
* AccessをDirectに変更
* Addをクリック

で追加できます。

![Screenshot from 2016-08-08 12-57-37.png](https://qiita-image-store.s3.amazonaws.com/0/36003/d8702c41-5494-37b9-333a-f3b9a7da4c20.png)

次にグラフを作成するには、

* 左上のlogoクリック
* DashboardsからNewを選択
* 左端のメニューからAdd Panel、Graphを選択
* Queryに適当にグラフにしたいクエリを入力

とすることで作成できます。

![Screenshot from 2016-08-08 12-59-59.png](https://qiita-image-store.s3.amazonaws.com/0/36003/28d47771-2b86-a71b-a9be-8ce679c0d066.png)


Prometheusのコンソールで入力できたものはそのまま入力できます。補完もlookup metricsというところから入力すると機能します。

とりあえず適当なメトリクスでグラフを作り、後は保存するなりすれば、以後は一覧から選択するだけでそのグラフにアクセスできるようになります。

その他グラフ作成の詳細はGrafana自体の機能なので[Grafanaの公式ページ](http://docs.grafana.org/guides/gettingstarted/)でも見てもらえればと思います。

## その他

以下は気になってるけどまだ試せていないので今後試すことができたら追記しようと思います。

* Pushgateway<br/>
最初に書きましたがPushgatewayを使うとPullではなくPushもできるようになります。
* [Consul連携](https://prometheus.io/docs/operating/configuration/#%3Cconsul_sd_config%3E)<br/>
[Consul](https://www.consul.io/)と連携することでConsulから監視対象を取得できるようなので監視対象の増減に伴う設定ファイルの書き換えが不要になりそうなので試してみたいと思っています。
* [Federation](https://prometheus.io/docs/operating/federation/)<br/>
Federationを使うと他のPrometheusのインスタンスからメトリクスの取得ができるようです。スケールさせる場合等に使うようですが、今のところそこまでの規模が必要になることは無さそうなので試すことは無いかもしれません。。。

# 最後に

ということで簡単にPrometheusの使い方を見てみました。
中々面白そうなので機会があれば実戦投入してみようと思います。

ちなみにdockerのswarmモード使いましたが、監視ツールは固定ノードで動かしたいし、監視対象もserviceとして作ってしまうと落ちたことに気付けない([Routing mesh](http://qiita.com/kiida/items/6dac109dcd063609b064#routing-mesh%E3%82%92%E8%A9%A6%E3%81%99)で別のノードからのレスポンスを受け取ってしまう)といったことがあるので、swarmモードの例としては激しく不適切だったかなと思います。ということで、実際に作る場合は普通にcompose辺りを使って立てるのが良いかと思います。