えいのうにっき

a-knowの日記です

Stackdriver を触ってみた

Mackerel に始まり先日の Datadog を経て、今日は Stackdriver を触ってみる。 Stackdriver も、モニタリング系の SaaS。当初は AWS 向けのモニタリングサービスとして始まったようだけど、Google に買収され GCP ファミリーに加わり、今ではむしろ GCP 寄りのサービスになっているようす。

Stackdriver も同じくエージェントインストール型。とはいえ、GCP 上のリソースであればある程度のことはエージェントなしで取得できるみたい。現在ベータで、無料で利用できる。

〜 利用開始まで

前回の Datadog でも監視対象にした home.a-know.me は GCE でホストしているということもあり、せっかくなんで、エージェントをインストールしない状態でどこまでのことができるのか、確認してみる。

Stackdriver は Google に買収され、まだ完全に統合はされていないものの、下の画像のように GCP の標準メニューには組み込まれている。

f:id:a-know:20160623180944p:plain

STACKDRIVER の各項目については、以下の様なかんじ。

  • Monitoring
    • メトリックの蓄積・ビジュアライズ・アラートなど。
    • GAE であれば何もせずに可能。
    • GCE でも一部の項目に関しては何もしなくても取得できるが、それ以上になると Stackdriver Monitoring Agent のインストールが必要。
  • Debug
  • Traces
    • Chrome デベロッパーツール・ネットワークタブのようなものの、プログラム内部版。...って、何よそれって感じかもしれないけど、うまくいえない。いわゆる AppStats。
    • こちらも GAE のサポートが基本。
      • API コールを適切にしてやれば、GAE に限らず使えるらしい。)
  • Logging
    • ログを Web コンソール上で見られるようになる
    • ログデータに基づくメトリクスを作成、可視化
    • ログデータに基づくメトリクスを使用したポリシーに基づいてモニタリング
    • GAE であれば特になにもせず取得できるが、それ以外の場合は Stackdriver Logging Agent のインストールが必要。

このように、Stackdriver にはエージェントが Monitoring Agent と Logging Agent の二種類がある。Logging Agent を入れると google-fluentd という本家 td-agent を fork したものが勝手に入り、 (fluentd の conf に基いて、)nginx の各種メトリクスなどを送ってくれる....という作りになっているようだ。

横道に逸れた。先ほどの「Monitoring」を押してみる。

f:id:a-know:20160623181211p:plain

このように、Google ログインを求める画面になる。Stackdriver がまだ完全には統合されていないゆえ、ってかんじだろうか。

↓対象の GCP プロジェクトを選ぶ。

f:id:a-know:20160623181430p:plain

f:id:a-know:20160623181547p:plain

AWS 連携もできることを強調されたが、今回は必要ないのでスルー。

f:id:a-know:20160623181917p:plain

↓以上で初期設定としては終わりっぽい。

f:id:a-know:20160623182048p:plain

Launch monitoring してみると、レポートをメールで受け取るかどうかを聞かれたのちに、

f:id:a-know:20160623182259p:plain

トップ画面と思しき画面が表示される。。いきなりある程度のメトリックが見えている。話が早い。

f:id:a-know:20160623182553p:plain

f:id:a-know:20160623182558p:plain

f:id:a-know:20160623182631p:plain

タイムレンジを切り替えると...

f:id:a-know:20160623182701p:plain

当然かもだけど、Stackdriver と連携するより以前の情報もグラフ化してくれている。GCP として抱えてくれている情報をもとに描画してくれている、ということなんだろう。

f:id:a-know:20160623182822p:plain

画面中ほどにあったプラスマークでグラフの追加ができそうだったので、ポチッとな。

f:id:a-know:20160623182954p:plain

f:id:a-know:20160623183144p:plain

↓選べるリソースタイプ。

f:id:a-know:20160623183304p:plain

↓リソースタイプとして GCE を選んだ場合のメトリックタイプ。

f:id:a-know:20160623183343p:plain

どうも見慣れた項目だなと思ったら、GCP のプロジェクトのトップページで見られるもの↓と同等のようだ。

f:id:a-know:20160623183555p:plain

↓Advanced Option として、任意の値を閾値として補助線を記入できたり、平均か最大値か最小値か、みたいなものも選べる様子。 (Filter は、複数のインスタンスがある場合のフィルタリング、かな)

f:id:a-know:20160623183816p:plain

↓はい。トップページのダッシュボードにグラフの追加ができた。

f:id:a-know:20160623183919p:plain

Monitor Agent を入れたらもっといろいろ取れるようになる、んだろう!

エージェントなしでどこまでできるか確認

さきほどのトップページに、

f:id:a-know:20160623184030p:plain

Monitor Uptime、Set Alerting Policies、Create a Dashboard と、ツアーっぽいものがあったので、それを一つずつやってみる。

まずは Monitoring Uptime

Monitoring Uptime

Monitor UptimeCreate Check を押すと、↓のようなウインドウが。

f:id:a-know:20160623184155p:plain

Uptime とあったので別の想像しちゃってたけど、この設定項目を見るに、どうやら外形監視っぽい。 しかもホストとか自由に指定できるっぽいので、GCP 上に限らない外形監視ができそう。

Advanced Option には、

  • リクエストヘッダの指定
  • ポートの指定
  • レスポンスに含まれる特定テキストの指定
  • カスタムヘッダの指定
  • ヘルスチェック
  • BASIC 認証

といったことも指定できる様子。とりあえず home.a-know.meHTTPS でチェックするポリシーを作ってみた。

f:id:a-know:20160623184254p:plain

一定時間がたつと、↓のようなかんじに。

f:id:a-know:20160623184317p:plain

おけ!!

Set Alerting Policies

Policy name、Condition、Notifications、Documentation、という4項目を設定する必要がある。 Policy name はそのままなのでここでは割愛。

Condition

アラートを上げる条件をここで決める。

f:id:a-know:20160623184542p:plain

条件を設定できる項目は、下記6項目。

  • メトリックの閾値
  • メトリックの変動量
  • メトリックの欠損
  • グループで集約したものの閾値
  • プロセスの死活監視
  • Uptime の監視

↓「メトリックの変動量」は、指定した期間で○% 以上の変動があったら、といったかんじか。

f:id:a-know:20160623184735p:plain

↓「メトリックの欠損」は、指定した期間メトリックが取得できていなかったらアラート、ということだろう。地味に嬉しい気がする。

f:id:a-know:20160623191443p:plain

「プロセス死活監視」と「Uptime の監視」は、まぁそうだよねという感じではあるが、エージェントのインストールが必要な様子。↓

f:id:a-know:20160623185056p:plain

f:id:a-know:20160623185123p:plain

エージェントをインストールしたらまた見てみよう。

Notifications

Email のほか、いくつか選べる様子。

f:id:a-know:20160623185315p:plain

今回はお試しということもあるので、Email で。

Documentation

これは、その監視ポリシーに対する補足説明文のようなものの様子。アラート通知の Email 本文にも含まれるっぽい。Markdown もサポート。

f:id:a-know:20160623185404p:plain

各設定項目については以上。今回は CPU usage に対して、必ずアラートが上がるようにしてポリシーを作成。

f:id:a-know:20160623185520p:plain

できたできた。アラートの通知メールもちゃんときた。↓

f:id:a-know:20160623185626p:plain

トップページの Incidents にもちゃんと出てきてた。↓

f:id:a-know:20160623185707p:plain

Create a Dashboard

そしてツアーの最後の、ダッシュボードの作成。

f:id:a-know:20160623185825p:plain

↑こんなかんじで、「さぁ、どんなグラフでも置くが良い!」的な、まな板の上の鯉的な状態。ためしに Add Chart を押すと↓なかんじ。

f:id:a-know:20160623185923p:plain

これはさっきトップページにグラフを追加したときと同じなので、ここでは細かいところは省略。どんどんグラフをダッシュボードに追加してみる。

f:id:a-know:20160623190019p:plain

うん。すっきりさっぱりしてるね。

各グラフのここ↓を掴むことで、

f:id:a-know:20160623190044p:plain

各グラフは移動させることもできる。ただこれ、今のところは折れ線グラフしか作れないもよう。

あと、グラフを作ってみてわかったんだけど、さっき作った外形監視、

f:id:a-know:20160623190146p:plain

デフォで様々なロケーションからのチェックをしてくれるんだね! 具体的にいうと、下記 6 ロケーション。ここらへんは、さすが Google といったところか。

  • Singapore
  • Iowa
  • Virginia
  • Belgium
  • Oregon
  • Sao Paulo

(......僕のサイト、Sao Paulo からアクセスするとコンスタントに 2 sec 超えだったのか...。。 :sweat_drops: )

エージェントをインストールしてみる

Stackdriver の基本的な操作についてはだいたいこんなかんじかな。ってことで、より多くの・細かいメトリックを取るためにエージェントを入れてみることにする。

今回も前回の Datadog と同様、エージェントのインストールを Chef のレシピを書いてやってやろうと思う。今回も Stackdriver のドキュメントを見ていると下記のような記述があるので、

curl -O https://repo.stackdriver.com/stack-install.sh
sudo bash stack-install.sh --write-gcm

このスクリプトを読み解き、Chef のレシピに落としこむ。

別途 API key が必要なんだけど、それは https://app.google.stackdriver.com/settings/accounts/agent/ で確認できる。

yum repository の登録から、設定ファイルへの API key のセット、エージェントの起動までを行う Chef recipe を作る Pull Request はこちら

で、cook 後、肝心の Stackdriver 側はどうなったかというとー。

f:id:a-know:20160623190341p:plain

選べるメトリックタイプに「AGENT」というカテゴリが増えてる!ヽ(=´▽`=)ノ たくさん増えてるんだけど、 Zombie processes というものもあったりして、おもしろい。

(ちなみに、先ほど書いた 「プロセス死活監視」と「Uptime の監視」は、まぁそうだよねという感じではあるが、エージェントのインストールが必要な様子。 だけど、エージェントインストール後でも無理だった。あと何をしておく必要があるんだろう? わかるかた、ぜひ教えて下さい!)

一歩進んだ設定

今回はやらないんだけど、Stackdriver もプラグイン機構を取っているようす。

Monitoring Third-party Applications  |  Stackdriver Monitoring  |  Google Cloud

見るに、Nginx とか Elasticsearch とか、主だったところは抑えられているようす? でも、2016/06/23 現在で18プラグインというのは、ちょっと少なめかも。

とはいえ、これらのプラグインは、「じゃあ利用するときに別途プラグインをインストールしなきゃいけないのか?」というとそうではなさそうなのが、お手軽でいいところかもしれない。例えば Nginx プラグインであれば、 /opt/stackdriver/collectd/etc/collectd.d/nginx.conf に以下の様なファイルを置いて restart するだけでいいみたい。

LoadPlugin "nginx"
<Plugin "nginx">
  URL "http://local-stackdriver-agent.stackdriver.com/nginx_status"
</Plugin>

あとこれも今回はやらないけど、別途 Logging Agent も入れることでログの確認も Stackdriver で出来る。

先述の通り、Logging Agent を入れると google-fluentd という、本家 fluentd(td-agent)を fork したものが入るようす。おそらく、td-agent 用の conf を追加する(Stackdriver で見たいログ単位で、かな)だけで Stackdriver に送ってくれるんだろう。

アラートが上がるような状況だと、すぐさま各種ログを見たい!ということもあると思うし、そういうときにログも一つのサービスに統合されている、というのはメリットも多い気がする。

懸念事項としてはやはり(正式サービス後の)価格面かな。今でこそ Stackdriver はベータということで無料で使えるみたいだけど、じゃあ正式サービス後もこのログの蓄積と検索の部分まで無料、もしくは据え置きか...?というと、それはあまり現実的ではない気がする。アラートの設定とか外形監視といった細かいところで王者・Google が儲けてこようとすることはないように思うけど。

追記

とかなんとか言ってたら、今後の課金の方向性についてのアナウンスがありましたw すごいタイミング!

Announcing pricing for Google Stackdriver | Google Cloud Blog

おおまかな概要としては、

  • フリープランとプレミアムプランを用意
  • フリープランは、GCP 上のリソースの 主要メトリック(トレース・エラーレポート)と 10GB/月 までのログの蓄積が可能。
  • 以下の様なことは、$8 / resource の課金が必要なプレミアムプランの登録が必要。
    • モニタリングエージェント・ロギングエージェントの利用
    • AWS インテグレーション
    • アラート通知
    • カスタムメトリクス、カスタムロギング
    • など

...というかんじ。

参考サイト

一通り自分で試したあとに下記ブログを見つけたのですが、非常に丁寧に書かれていてとても参考になりました。 :bow:



follow us in feedly