# Introduction to Alibaba Monitoring System ## 概要 [[Ren Xinchi]]（[[Alibaba Group]] GOC シニアエンジニア）が SREcon18 Asia/Australia（2018-06-06、シンガポール）で発表した、Alibaba の全社モニタリングシステムの設計と運用に関する講演。4 層のモニタリング構造のなかで**ビジネスレイヤ**を最上位に据え、独自 CMDB [[Hammurabi]] でビジネス機能と優先度を管理し、5 つのゴールデンエレメントで障害影響を定量化するアプローチを紹介する。 ## 主要メッセージ - Alibaba は 30 以上の事業部（Taobao、Alipay、Alibaba Cloud、Youku 等）にまたがる数百万台のオンラインサーバを運用し、1,000 万以上のモニタリング項目から数十億のアラームとデータが生成される。 - **4 層モニタリング構造**: (1) インフラストラクチャ層（ネットワーク帯域、パケットロス率、IDC の温度・電力）、(2) システム/アプリケーション層（CPU、JVM、負荷）、(3) ビジネス層（トランザクション数、決済成功率、API 成功率）、(4) 顧客フィードバック層（苦情件数のトレンド）。ビジネス層が最も重要と位置づけられる——顧客影響と直結し「30% の顧客が影響を受けている」のように定量的に表現できるため。 - **[[Hammurabi]]**: ビジネスモニタリング用の CMDB。各事業部の主要ビジネス機能とその KPI を登録し、P1〜P4 の優先度定義（例: Taobao の注文件数が 15% 以上減少 → P1、Alipay のトランザクション/分が 15% 以上減少 → P2）と担当者をマッピングする。アラーム発生時にビジネス影響を即座に確認し、優先度に応じた緊急対応を開始する。 - **5 ゴールデンエレメント**: 総数(total count)、成功数(success count)、成功率(success rate)、応答時間(response time)、失敗数(failure count)。この 5 つのメトリクスの組み合わせで顧客側で何が起きているかをシミュレートできる（例: 総数増加 + 成功率低下 → 一部顧客が障害に遭遇しリトライしている）。 - **次元分析(dimensional analysis)**: データを IDC 別・エラーコード別・クライアント別などの次元に分離し、障害の局所化を支援する。IDC 別分離により「あるデータセンターでのみトランザクションが減少」と特定し、フェイルオーバーを決断できる。 - **ログ標準**: Trace ID、API 名、データパス、エラーコード、結果(S/F)、タグのフィールドを持つ標準フォーマットにより、4 ステップでモニタリング項目を生成する。 - **変更との結合**: 障害の約 70% が変更に起因するため、モニタリンググラフ上に変更情報（黄色のポイント）を重ねて表示し、障害発生の 1〜2 分前に行われた変更を即座に特定、ロールバックの判断を加速する。 ## 映像で確認できる重要点 - ![[_attachments/srecon18-alibaba-monitoring/frame-003.jpg]] frame-003: 4 層モニタリング構造の全体図。左列にインフラストラクチャ・システム/アプリケーション・ビジネス・顧客フィードバックの 4 層、右列に各層のコンテンツとプラットフォームを示す。 - ![[_attachments/srecon18-alibaba-monitoring/frame-006.jpg]] frame-006: ビジネスモニタリングのメトリクスタイプ。5 つのゴールデンエレメント（Total Count、Success Count、Success Rate、Response Time、Failure Count）のフロー図。 - ![[_attachments/srecon18-alibaba-monitoring/frame-010.jpg]] frame-010: 障害対応ワークフロー図。3 段階の構成——(1) ビジネスアラームによる障害発見、(2) ダッシュボードと次元分析による予備分析、(3) 迅速な復旧（ロールバック/フェイルオーバー/デグレーション）。 - ![[_attachments/srecon18-alibaba-monitoring/frame-009.jpg]] frame-009: ビジネスモニタリングのグラフィカル表示。メトリクス推移と変更情報の重ね合わせ、日比較、カスタマイズダッシュボードの画面。 - ![[_attachments/srecon18-alibaba-monitoring/frame-012.jpg]] frame-012: 将来構想の 3 段階。(1) Automation Dashboard（アラーム発生時に関連情報を自動集約したダッシュボードを生成）、(2) Broadcast Fault Location（データ間の接続を構築し根本原因の推薦）、(3) Intelligent Decision（推薦の精度が十分になった段階で復旧操作の自動決定）。 ## 口頭説明・補足 - GOC（Global Operations Center）は中国 2 拠点（杭州・北京）と米国 1 拠点の 3 サイト体制で 7×24 時間監視を提供し、主要障害の 90% を発見する。障害発見時は SMS・電話で関連エンジニアとマネージャーに即時通知し、復旧まで状況を更新し続ける。 - ビジネス層のモニタリングが重視される理由として、障害がアプリケーション層（例: Taobao のコア取引アプリケーション）で発生した場合、ビジネスメトリクス（取引数 50% 減少）を見れば顧客影響が明確だが、システム層のアラーム（CPU 負荷・JVM 異常状態）は大量に発生するものの顧客影響の程度を直接表現しない。 - グラフィカル表示では、数値をクリックすると時系列チャートが表示され、前日・先週・昨年との比較が可能。これにより「今日だけの問題か、毎日起きている問題か」を判別する。 - 事例 1（IDC レベル障害）: 3 つの IDC にまたがるトランザクションのうち 1 つの IDC でのみ異常が発生。トラフィックを他 2 サイトに切り替えるフェイルオーバーにより約 2 分で復旧。根本原因の調査は 1 時間かかったが、その間顧客は影響を受けなかった。 - 事例 2（変更起因障害）: あるサービスの成功率が低下。モニタリンググラフ上の変更ポイントから障害の 1〜2 分前のデプロイを特定し、当該エンジニア（Jack）にロールバックを依頼。ロールバック後にサービス復旧。 - インテリジェントモニタリングについて: ベースライン予測と異常検知を導入し、アラーム精度がベースラインの 20% から 80% に改善した（詳細は前年の同僚の講演で共有済みとのこと）。 - 将来構想: (1) アラーム発生時にデータ間の接続を利用して関連ダッシュボードを自動生成、(2) システムが根本原因の推薦を行う、(3) 推薦精度が十分に高くなったらシステムが復旧操作を自動実行する。 ## 概念・実体への接続 - [[ビジネスモニタリング]]: 本発表の中核概念。ビジネス KPI を顧客影響の代理指標として位置づけ、5 ゴールデンエレメントで統合的に表現する手法。 - [[Hammurabi]]: Alibaba のビジネスモニタリング用 CMDB。ビジネス機能と優先度の登録、アラームとの自動マッピング。 - [[Alibaba Group]]: GOC（Global Operations Center）による全社横断モニタリングの運用体制。 - [[アラート管理]]: ビジネスメトリクスに基づく P1〜P4 優先度定義とエスカレーション。 - [[異常検知]]: 時系列解析によるインテリジェントモニタリング（精度 20%→80%）。 - [[分散トレーシング]]: ログ標準の Trace ID フィールド。 ## 限界・不確実点 - 自動字幕（YouTube en-orig）は中国語話者の英語音声を処理しているため、固有名詞の誤認識が多い（例: Alibaba → "Ali Baba"、Taobao → "Taba"、Alipay → "Ali pay" / "a leap a"、Youku → "yoku"）。固有名詞と数値は公式ページと映像フレームで裏取りした。 - 代表フレームは低解像度（約 320×180px）で、ダッシュボード画面の詳細な数値やラベルは判読困難。グラフの全体的な形状と見出しテキストは確認可能。 - インテリジェントモニタリング（ベースライン予測・異常検知、精度 20%→80%）の詳細手法は本発表では共有されず、「前年の同僚の講演」を参照するに留まる。 - 動画は約 20 分の短いトークであり、Hammurabi の具体的な UI やデータモデルの詳細は示されない。