アラートの嵐で大事なアラートが埋もれていないか？
「運用担当で夜中に呼び出されたことがある人はいませんか？ 実はぼくもあるんです」Datadogの池山氏は緊急対応の経験もあるエンジニアだ。だからモニタリングの課題や重要性をよく理解している。
ありがちなのがアラートの嵐。原因としては、監視する必要ないものまで監視して通知設定していたり、1つのインシデントから連鎖的に起こることまで通知設定していたりなどが考えられる。
アラートが多すぎるなら、あらためて見直すべきだ。監視する必要があるか、通知する必要があるか、過剰な通知設定をしていないか。中には複数の条件を満たすことで通知する意味があるものもある。通知の条件を正しく設定しておかないと、運用管理者が翻弄されてしまいかねない。
もちろん、モニタリングが不十分だとシステム障害に気づくのが遅れてしまいかねない。Webで提供しているサービスがダウンすれば、ビジネスの機会損失につながる。アメリカのECサイトでダウンタイムの機会損失が大きい順に並べるとAmazon、ウォルマート、ザ・ホーム・デポ、ベスト・バイ、コストコ、メイシーズと並ぶ。トップのAmazonだと、1分ダウンしたら22万米ドル（約2420万円）の機会損失となる。
失われるのは機会損失（お金）だけではない。社会的信用、顧客満足度、リピート率なども徐々に失われ、ビジネスにとって痛手となる。池山氏は「ダウン時間そのものを悪と見るのではなく、SLO（サービスレベル目標）からどれだけの損失が発生するかを把握することが大事です。モニタリングで、いち早く問題を発見すること、早く復旧することを目指し、同時にモニタリングの負荷をかけすぎないことも重要です」と説く。
システムを監視するためのツールはこれまでも多く出されてきている。ただしレガシーなシステムを想定したものだと、モダンなシステムと見合わなくなっている。かつては少数のベンダーでプラットフォームを構成していたが、今では多数のOSSやSaaSを併用している。リリース頻度も高まっている。インフラは集約から分散となり、複数のインフラや開発チームがいて、池山氏は「レガシーなモニタリングツールではクラウド時代のスピードとペースに追いつけない」と指摘する。
クラウド時代のモニタリングで重要なことは何か。池山氏は「今日はこれを覚えておいてください」と強調したのが「Cattle, not pets（家畜であり、ペットではない）」。監視するということは家畜を管理することに似ている。家畜は肉や牛乳などを生産する。名前をつけて、家族として愛するペットとは違う。家畜もシステム監視対象も、ビジネスを支えるために適切に管理する必要がある。
そして池山氏がシステムの可視性における三本柱として挙げるのが、トレース、メトリクス、ログ。トレースはサービス間の原因を特定するもので、アプリケーションのスループットやレイテンシーを必要に応じて見る（リクエストベース）。メトリクスはトレンドやパターンを把握するもので、システムやミドルウェアのパフォーマンスを集計などで分析する。ログはインシデントを調査するもので、デバッグなどイベントごとに見る。
クラウド時代のモニタリングサービス「Datadog」の特徴は？
クラウド時代のモニタリングサービス（SaaS）として、2010年にアメリカのニューヨークで生まれたのがDatadogだ。開発者と運用担当者を対象としており、モダンなシステムを想定してモニタリングと分析を行う。
池山氏はDatadogの特徴をいくつか挙げた。「最も気に入っている」と挙げたのがセルフサービスですぐに使えること。SaaSならではの良さだ。この特徴ゆえに価値の実現の速さにも繋がっている。あるECサイトではインストール後1時間で問題を発見し、対応することができたという。使い始めて1時間でDatadogの良さを享受できたことになる。
ほかにもDatadogにインストールできるインテグレーションが250以上あること、チームをまたいだコラボレーションができること、スケーラブルなプラットフォームであることが挙げられる。インテグレーションにはSlackやPagerDutyなどサードパーティとの連携を実現するものもあり、UIから必要なものをインストールできる。
モニタリング対象は大きく分けてメトリクス、イベント、APM、ログがある。タグも重要だ。キーバリュー形式で1つのメトリクスに複数のタグを付けることができるため、フィルタリングやグルーピングに有効となる。
モニタリング対象について詳しく見ていこう。メトリクスはワークメトリクスとリソースメトリクスがある。ワークメトリクスは処理状況を見る。単位時間あたりの処理量、処理が成功したか失敗したか、処理が完了するまでに要する時間などだ。サービスが適切に提供できているかを見極めるには重要だ。
リソースメトリクスはCPUやメモリの使用率、飽和度、内部エラーなどを表す。問題があれば深掘りする必要があるものの、常時監視する必要があるとは限らない。CPUの使用率が高いとしても、慌てる必要はなく、キャパシティプランニングが正しいと見ることもできるからだ。
イベントはリリースやパッチ適用などの変更、アラート、スケーリングなどが記録される。監視というよりは記録であり、トラブルが生じた時に原因究明のヒントにつながることがある。
APM（アプリケーション性能管理）はアプリケーションのスループット、エラー、レイテンシー、トランザクションのトレーサビリティ、サービスマップなどを表す。モダンなシステムではマイクロサービスやコンテナ化が進んでいるため、アプリケーション単位で性能を監視する必要性がある。DevOpsが普及したなか、サービスの可視化や監視効率を高めるには必要な要素だ。
今では各種APMが登場しているが、DatadogのAPMは設定が簡単なこと、メトリクスやログの相関をGUIで実現できること、マイクロサービスの分散トレーシングも可能なこと、OpenTracingにも対応し、対応言語がPython、Ruby、Go、Java、Node.js、.NET、PHPと多数あることが特徴として挙げられる。
ログは分析ワークフローが簡素化できるような工夫がなされている。ログをメトリクスやトレース情報と関係づけることで原因の検索や分析が素早くできるようになっている。またログパターン分析として、ログをクラスタリングしてパターン化することで、ログが埋もれてしまうのを防ぐ。
