監視データを3つに分類する

Masahiro Hattori 氏：そういう条件があって、いいメトリックがとれたと。では、あとはアラートを設計、監視の設計です。そこまでで、ある程度理想論になってしまうんですが、判断の軸みたいなものをDatadogでは長らく言っています。

それが監視データを分類する考え方なんですけれども、この3つがありまして、左からWork Metrics、Resource Metrics、Eventsです。1つずつご説明します。

監視データでざっくりやって、それをアラート設計していくと、感覚的にどこが重要かというのももちろんありますが、その感覚的なところを補強できるような材料になれば幸いという感じです。

まずWork Metricsを、ドーナツ工場に例えて考えてみます。

工場で5、6個ずつ油から揚がっていって、どんどん砂糖のなかに投げていくとします。その時にドーナツが毎秒5個流れていくとするとそれはスループットで、そのなかの廃棄率とかがあったりするとSucsess、Errorレートになります。それについて、サービスそのものの状況を見るような指標がWork Metricsという感じです。

ですので、どちらかというとApplication Metrics寄りだったり、DBのいわゆるリクエストレートだったりレイテンシというところが、だいたいWork Metricsに当たるところなのかなと思います。

Performanceというのは、ドーナツでいうと毎秒5個揚げられるとか製品化できるとか、毎秒5個だったのが6個になったりですね。

Resource Metricsというのは、CPU使用率、メモリ使用率、ネットワーク利用率みたいなものがAvailability、稼働率やアップタイムみたいなところがResource Metricsになります。砂糖が今どれぐらいあって、どれぐらい使っているかみたいなところです。

最後はEventsです。

そのままドーナツの例でいくと、テレビで紹介されたとかCMが打たれたとか、National Doughnut Dayみたいな大きいイベントがあるのでめちゃくちゃはけるとか、システム上でいうCode ChangesやAlertsが発生しているとか、スケジュールメンテナンスが発生しているとかというのがここに当たります。

ここはいわゆるグラフ化するようなものとは違うんですけれども、メトリックの変化などを説明する材料になってくると思います。

そしてここがキモでして、そういったものをある程度仕分けたら、今度はそこから、各会社さんなりサービスのなかで、それをWork、Resources、Eventsというのを構造化していきます。

こんなにきれいにはいきませんが、例えばサービスのレスポンスやパフォーマンスという指標は、いくつかのDBのリソースに影響を受けていて、そのDBの1つというのはフェイルオーバーしたとかイベントがトップラインで今書いているようなところです。

ただリソースとして書いているDB自体も、DBとしての主要な指標は実はDBにとってはWork Metrics、DB自体の生産性を示すような指標だったりします。

そこに対して2段目、Work、Resources、Eventsと並んでいるのは、DBに対してDBのリソースであるディスクとかになっていくので、そこを構造化していって、どこが一番重要なのかを、できるだけことが起こる前に明らかにしていくことが必要です。

そういう作業までやると、ある程度同じようにアラート、例えばCPU使用率がサチると、それはそれで危ない状況にはなり得るんですけれども、本当に危ないところがどれなのか、全体の認識として共通化しやすいです。少し再帰的な構造みたいな感じなんですが、こういったところをやってもらいます。

こういったかたちでメトリック自体ボーダーにあると言ったあとにこんなことを言っているので、すごい作業になりそうなんですが、全体像としてこういったことを踏まえた上でアラート設計をやっていくと、オオカミ少年は減らせます。実はもう鳴っているだけでスルーしているような、ここでいうとトップじゃなくて最下層のWork、Resources、Eventsだったりすると思うんです。

そのあたりを共通認識としてどこに一番対応しないといけないかを当たりやすくするという感じになります。

平均復旧時間を考える

これをもう少し実務的な話をすると、例えば平均復旧時間（MTTR）みたいなもののメトリックに対して考えます。

例えばMTTRというものがあったとすると、監視ツールとして前半の検知するまでの時間に労力が割かれがちなんですが、解決までの時間、トラブルシュートの時間もすごく重要で、この2つを足したところでサービスとして損失が生まれてくるのでこういう分け方をしますが、まずは検知してアラートを出すというところになるのかなと。

さっきのかたちに戻って、あの構造のなかでどこに問題が発生した時に電話するのかと。

アメリカでは電話のことをページャーと言ったりします。じゃあどういう時に電話を鳴らすのかなんですけれども、左側が症状に対して電話しましょうと。おもにはWork Metricsからわかる、明らかな問題の症状に対して電話しましょう。

右側は分析や調査なんですが、Work MetricsとかResource MetricsとかEventsというのは調査用のデータとして残しておくんですけれども、電話する対象やアラートするものではないと。

いったんここでは言い切る感じなんですが、割と強い意志で分けていくという感じになります。ある程度理想的な部分もあります。

ただ、お子さんをおもちの方だとわかると思いますが、1歳ぐらいの子どもだとけっこうすぐに熱が出たりして、38度ぐらいとかになるんですけれども、お医者さんに行くと、機嫌がよかったらほっといて、みたいなことがよくあります。

大人の場合は悪寒が発生したりすると、これは病院に行かないとまずいとすぐにわかりますが、子どもだとそれがわからないので機嫌が悪くなるという明らかな症状が発生するんですけれども、どちらかというと悪寒が発生する、子どもだったら機嫌が悪くなるというのが左側です。それはすぐに病院に行きましょうと。

誰にアラートを飛ばすか？

右側にあるのは、38度を超えたらすぐに病院に行ったり救急車を呼ぶかといったらそうではないと思うので、本当に今すぐ処置しなければいけないものは何なのか判断を分けましょうと。

ただ、それはかなり理想的な話になりがちです。形式的に理想的な話をしてしまうところがあるんですけれども、もちろんWork Metricsでアラートをするのがわかったら、トップレベルでアラートをしましょう。

でもそこのResource MetricsはやはりどこかのResource Metricsなので、それもアラートしないといけません。

結果的にこれを書いたとしても、全部アラートしないといけないというのが当然の疑問なので、そこに対して、Datadogには誰にアラートするのかいう考え方があります。

Leadershipの人たちの場合は、全社的な緊急事態ですよね。サービスでトップレベルでパフォーマンスが落ちていたら、もうサービスダウンとかだと全員がそれを知って、エンジニアだけではなくて広報とかも動くでしょうし、お客さんの先に行く営業部隊も動くでしょう。

1段階下の部分であれば開発者とか。

その下だとデータベースチームとか、

最後は運用チーム、SREというところ。

ですので、そういうかたちでどこまで、誰にアラートするのかを、ある程度切り分けるための指標になるのがこの構造化の話です。

このように、これからの時代のメトリックの仕組みも考えつつ、それで得られたメトリックをさらに構造的に考えていって、よりオオカミ少年的なアラートをなくしましょうという話でございます。

解決までの時間

ここまでアラートがスマートに決まると、あとは解決までの時間です。

原因分析とか調査、修復というところになるんですけれども、修復のところはすごく個別的な話になるので、いい加減こういうアラートはやめましょう。

とりあえずアラートが来たことだけはわかるアラートみたいな。DBが壊れたということだけがわかって、実際どうしようというのはいろいろ調べないとわからないと。

そこに対して、Datadogではアクショナブルアラートと言ったりしますが、アクション可能なアラートをつくりましょう。

アラートのなかにこれを書く意味なんですが、何が起こったのか、なぜそれが重要なのか、問題箇所を確認して応急手当てがあるとか、分析する時はこれを使いましょうとか、最終的に連絡先とか手順書みたいなところを、こんな感じで書きます。

そうすると、もらったほうの動きとしては全然違いますよね。「コーポレートサイトのレスポンスが3秒を超えています」というのがアラートのタイトルなんですけれども、実際は5秒以上かかっています。

「5秒経つとお客さまが離脱しますよ」という実際の行動まで書いていてわかりやすい。そして直し方として、キャパシティを増やすならダッシュボードでこれを確認してくださいとか、jenkinsジョブを走らせることでリソースを増やせますよとか、もっと分析するんだったらこういうwikiを見て、そのフローを見てくださいとか、行き詰ったら私まで電話してくださいね、みたいな感じでSREのマネージャーさんの電話番号を書くかもしれませんが、そういう使い方をします。

このようにうまく構造的にモニタリングを扱うというかたちで、これから爆発的に複雑化するシステムを、単純にAzure Monitorで大丈夫です、Zabbixと連携させてやりますではなく、もちろんPrometheusでやっていくのでも構わないので、考え方をごろっと変えて、複雑化必須の前提でモニタリングを再考しましょう。

Datadogにおけるサーバー監視デモ

あと3分だけあるので、少しだけその複雑化の1つの解として、タグの何がうれしいのかというところを少しデモします。例えばPrometheusでも同じ考え方なのでいいんですけれども、Datadogならこんな感じというのをお見せします。3分なので超短縮版で。

これはDatadogのホストマップという一番有名な可視化ツールなんですが、一つひとつの六角形がサーバーでして、現在7,000サーバー、ほとんどスポットなんですが、赤いほどCPU使用率が高いです。

タグは何がいいかという話なんですけれども、例えばここでenv:stagingと入れると、7,000台ぐらいから1,000台ぐらいまでステージング環境に絞り込みます。

さらにここでroleというタグを入れると、役割ごとにタグでサーバーを絞り込むと。

今7,000台からタグ2つで50台ぐらいまで絞り込んでいるんです。今までの監視ツールですと、どうしてもサーバー単位で考えるので、サーバーごとのグループとか役割とかサービスという2、3軸ぐらいでしか切り口が持てないんですけれども、とくに流動的なインフラになったり、コンテナ化するとそれが難しくなりますよね。

なので、Datadogでは、Prometheusも確かそうですが、サーバー登録という作業はありません。

Azureでもそうですけれども、クラウドの属性情報を自動的に引っ張ってきてタグにしてしまいます。Chefのroleとかもそうです。

あるいは自分でタグを入れ込むということももちろんできるんですけれども、そういったものを使って柔軟に対象を見ると。

もちろんサーバーだけではなくて、今度はコンテナです。

一つひとつの四角がコンテナです。

例えばここで、タグを検索する画面なんですけれども、kubeと入れるとdeamon_setとかnamespaceとか。

namespaceはあまり数が多くならないと思うので、例えばdeploymentとか入れると、deploymentの単位ごとにコンテナを分けてみますとかという見方です。

仮に例えばこれで、nginx- deploymentでhostと入れると、一応そのサーバーごとに分けて見れたりもします。

もちろんその理由としては、KubernetesとかDockerコンテナの属性情報を、ひたすらタグとして盛り込んでいます。こういったものを使ってもいいですし、エージェントで指定するオリジナルのカスタムタグとかも使って、見たい粒度で見たい場所をバシッととると。

それがタグというメタデータを使う以上は、別にそのサーバーが流動的になろうがオーケストレータでばんばん上げたり下げたりしようが、タグという範囲でくくられているのであれば、自動的にアラートにするし可視化にするし、管理性が全然違います。よいメトリックの3番目ですけれども、タグでフィルタするみたいなところが非常に効いてくるということでご紹介させていただきました。

アラートもこのタグでパチパチと当てていくだけなので、慣れてしまえばある程度簡単にできるところがメリットなんですけれども、このツールならではというところをご紹介させていただきました。

以上になります。ご清聴ありがとうございました。

（会場拍手）

Occurred on , Published at