目次
はじめに
第1章 なぜゆえの監視
第2章 Mackerelについて
第3章 Mackerelの導入
第4章 MackerelによるWebシステム監視
第5章 プラグイン開発による対象メトリックの追加
第6章 チェック監視
第7章 アクセスログの可視化によるサービス水準の監視
第8章 URL外形監視によるWebサイトのヘルスチェック
第9章 バッチ処理のロギングと監視
第10章 APIを使用したサービスメトリックの投稿
第11章 コマンドラインツールmkr
第12章 mackerel-container-agentによるコンテナーの監視
第13章 まとめ
あとがき
はじめに
本書は、株式会社はてなが提供するサーバー監視サービスMackerelについて、その特徴と現場で活用するノウハウについてまとめたものです。
この本の想定する読者
・これまでWebサービスにおいてインフラの監視を行っていなかったが、運用する上で監視の導入が必要になり、検討を進めているインフラエンジニア
・Webサービスの監視に興味がある、アプリケーションエンジニア
サポート
本書の内容のサポートについては、以下のサイトで行います。
画面のスクリーンショット等、サービスに関する情報については、執筆時点での最新のものを使用するよう努めています。ですが、継続的にサービス内容の更新が行われていますので、最新のサービス内容と差異が出る場合はご容赦ください。
説明に使用するホストのOSは、注記がない場合はCentOS Linux 8.1 (1911)を使用しています。
ホスト側の動作の検証は、以下のバージョンで行っています。
・mackerel-agent 0.67.1
・mackerel-agent-plugins 0.60.1
・mackerel-check-plugins 0.34.0
表記関係について
Mackerel（マカレル）は株式会社はてなの登録商標です。また、本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。
免責事項
本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。
底本について
本書籍は、技術系同人誌即売会「技術書典4」で頒布されたものを底本としています。
第1章 なぜゆえの監視
平家物語の出だしに「諸行無常の響きあり」という言い回しがあります。どれだけ完璧なサイジングをしたとしても、ITサービスを取り巻く周囲の環境の変化は、サーバーやネットワーク帯域などのインフラのレイヤーに様々な影響を及ぼします。
そして、インフラへの影響は、パフォーマンスの低下やレイテンシーの増大など、サービス品質に影響を与える問題を引き起こします。
ITサービス運用を考えるにあたって、ユーザーは増えるものであり、データは貯まるものであり、アプリケーションの規模は膨らむものです。
現代では、クラウドに代表される仮想化技術の進展により、インフラに関するリソースは以前に比べると、はるかに容易に調達ができるようになってきました。
しかし、インフラにかかるコストと事業の収益性は単純に比例するものではない、ということを考えると、インフラにかかる費用を際限なく計上することも、また非現実的です。
情報処理の世界には「Measure Don't Guess.」（推測するな、計測せよ）や、「計測なくして改善なし」などの格言があります。これらの言葉の根底には、19世紀のフランスの数学者Jules-Henri Poincarの「計測なくして科学なし」という言葉があります。
パフォーマンスチューニングとは、測定した事象と仮説検証に基づく、れっきとしたエンジニアリングの一分野であり、単に「設定値を増やせばいい」というものではありません。ネットワークを通じて結びつく、ITサービスを構成するシステム上の各機器のパラメーターを調整する上で、必要な視点があります。それは、個別の機器におけるパラメーターの変動が、システム全体にどのような影響を及ぼすか、という視点です。
それを知るためには、システムのリソースの使用状況やプログラム実行時のエラーの状況など、サービスの可用性に関連のある項目を時系列に沿って集積し、適切な監視を行う必要があります。
1.1 誰のためのモニタリング
ITサービスの運用にあたっては、開発、インフラ構築、運用など、様々な利害関係者が存在します。その中で運用に関わる主体は、システムを安定して運用することを使命としています。
システムインテグレーションの分野では、開発が完了してカットオーバーされても、ユーザーがいないシステムというものもあります。これは運用の立場からすると、理想的なシステムです。なぜなら、ユーザーがいないシステムは、ユーザーへのサービス提供に影響を及ぼす障害を起こすことがないからです。
これは極端な例ですが、自らのタスクがキューからあふれているシステム運用者は、「システムをいかに使用させないか」という思考パターンに陥ることがあります。
しかし、ITサービスの構成要素としてのシステムは、ユーザーの使用に供するために存在するものです。その意味で、アラートが発生するということは、システムが使われて社会のために役に立っていることの証明です。
DevOpsという概念を広く世に知らしめた「10+ Deploys Per Day」1 では、「Opsの職務は、ビジネスを実現することだ」（Ops' Jobs is to enable the business）と示されています。ITサービス運用の存在意義は、システムの安定運用を通じて、ビジネス価値を実現することと、サービスを取り巻く環境の変化に対応するために、柔軟なインフラ基盤の提供を実現することにあります。
安定したサービス運用の観点では、ITサービス運用はシステムを作る側でなく預かる側であり、運用（インフラ）に仕事がないことは望ましいことです。実際、運用が暇で時間を持て余すくらいでないと、安定運用のための足場づくりは不可能です。しかしながら「システムの使用を促進する」ことと、「自分の仕事を減らす」ことの両立は、言うは易く行うは難しの最たる例です。
システムの安定運用と、運用業務の省力化という二つの観点から、最適化の面で監視を考えてみましょう。この場合に留意すべきことは、監視の項目の粒度は、詳細にしようとすればいくらでも細かくできるということです。
ハードウェアのリソースやOSのモジュールの動作状況、ネットワークの使用状況など、監視する項目は際限なく増やすことができます。発生確率が一定という条件の下では、監視項目が増えることはアラートが発生する回数が増えるということです。
そして発生するアラートを受けるのは、シフトで夜勤をしている、運用に従事する技術者です。アラートを受け取ることから始まるストレスと負のフィードバックは、やがてDevとOpsの対立を引き起こします。
監視をすること自体は目的ではなく、安定したサービス運用のために手段として行うものです。ITサービスを運用する主体はサービスの監視を行いたいわけであって、OSの監視を行いたいわけではないのです。
その際、主に監視の対象となるのは、ユーザーに対するサービス提供が正常かどうかです。ハードウェアやOS、そしてアプリケーションの細かい状態への監視は、それを補完するものです。
1.2 監視に求められるもの
以上のことを踏まえた上で、監視を行うシステムに求められるものを、以下に挙げます。
1.2.1 監視を始めるにあたってのカスタマイズが最小限度であること
仮想化技術の進展により、ひとつのサービスを構成する上での、サーバーやネットワーク機器等の構成要素は増えています。その中で、必要最小限の監視項目を構成するには、カスタマイズによる作り込みの要素が大きいミドルウェアやサービスは適当ではありません。
OSやミドルウェアの詳細なメトリックなど、監視を行う要素はいくらでも細かくすることができます。しかし、ITサービスの構築プロジェクトの納期が短縮の傾向を見せている昨今、詳細な監視項目の作り込みは、構築プロジェクトの大半の期間を監視のカスタマイズで終わらせることになりかねません。
監視項目やアラート発生の閾値など、ITサービスに対する監視レベルを最適化するには、負荷テストや障害テスト、そしてサービスイン後、実際に取得したメトリックの内容からフィードバックを得ることが必要です。
以上の点から、Webサービスの立ち上げ時に監視に求められるものは、最小限度の監視をすばやく立ち上げられることです。その後、監視項目のカスタマイズやプラグイン導入などを、柔軟な形で追加できることが求められます。
1.2.2 機能と学習コストのバランスがとれていること
「学習コスト」という概念は得てして、組織が技術水準の向上に投資をしないことへの正当化として用いられがちです。ですが、ITサービス運用において監視とは「手段」であり、監視の構築と運用のために、組織に監視に対して習熟した専門家を必要とするような状況は本末転倒です。ITサービス運用での業務を最適化する上では、学習コストとコストに対するリターンの観点は必要でしょう。
1.2.3 既定値のバランスがとれていること
先ほどの「最小限度のカスタマイズで使用できること」を、サービスの既定値の視点から見てみましょう。そこでは、カスタマイズを最小限度に抑えるため、セットアップ直後の既定値がバランスの取れたものとなっていることが求められます。
1.2.4 MackerelによるWebサービス監視
以上を踏まえて、本書では、サーバー監視サービスであるMackerelを用いたWebサービスの監視について紹介します。