アリ雲雲監視を利用してCPUと帯域幅のリアルタイム警告通知を設定する方法

運用保守やシステム管理の技術業務において、クラウドコンピューティングに初めて携わる新人がよく犯す致命的な誤りがあります。

サーバーを購入し、業務システムのデプロイを完了すれば、万事がうまくいったと思い込む

。

ある日の夜中まで、トラフィックが突然急増して帯域幅が詰まったり、あるデッドサイクルのプロセスが直接CPUを100% に押し上げてシステムがダウンしたりして、お客様の電話が爆発した運送業者は慌ててバックグラウンドにログインしてログを調べる。このような「受動消火」の苦痛は、一度でも経験したエンジニアなら誰もが二度と味わいたくないと感じるものです。

実は、Alibaba Cloudには、非常に強力なインフラストラクチャ監視ツールが標準搭載されています。

クラウドモニタリング（CloudMonitor）

。CPUとネットワーク帯域幅のリアルタイム警告通知を合理的に構成すれば、システム指標が取引された最初の数分以内に通知を受けることができ、危機が広がる前に簡単に解決できる。

次に、私は実際の運送の実技経験を結び付けて、手を持ってあなたを連れて効率的でゼロ申告の阿里雲リアルタイム警告システムを構築します。

一、なぜCPUと帯域幅はアラートの「生死ライン」なのか？

クラウドサーバー（ECS）の各種モニタリング指標において、アラート項目は多岐にわたりますが、

CPU使用率

と

送信/受信方向の帯域幅（Bandwidth）

常に核心中の核心である。

CPU使用率：サーバーの計算負荷を示します。CPUが長期的に90% 以上に維持されていると、軽いとHTTP要求の遅延が急増し、重いとシステムOOM (メモリオーバーフロー) または直接カードが停止する。

ネットワーク帯域幅（NetworkOut／NetworkIn）：データ転送の負荷を示します。輸出帯域幅がいっぱいになると (例えば、5Mbpsの帯域幅を買って、4.9Mbpsに走った) 、サーバはパケットロスやネットワーク遅延が発生します外部ユーザーは「webサイトが開かない」または「インタフェースがタイムアウトした」ように見える。

これら2つの指標を厳密に監視すれば、サーバーインフラの故障の90％以上を事前に予測できます。

二、準備作業: 警告通知の「インフラ」

CloudMonitorコンソールでルールを設定する前に、まず「通知チャネル」を設定しておく必要があります。アラートが発生しても適切な受信者が設定されていなければ、どんなに完璧なルールであっても無意味です。

1. クラウド監視プラグインのステータスを確認する

Alibaba Cloudコンソールにログインし、次へ進んでください。

クラウドモニタリング -> ホストモニタリング

。ECSインスタンス上の

アルガスエージェント

プラグインのステータスは次のように表示されます

「実行中」

。プラグインが正常に動作している場合にのみ、クラウド監視はシステム内部のより細かい粒度のメトリクスデータを取得できます。

2.アラーム連絡先と連絡先グループを設定する

左側のナビゲーションバーを順にクリックします

「アラートサービス」→「アラート連絡先」

:

連絡先の作成: 運送業者または開発者の携帯電話番号、電子メールアドレスを入力し、ホッチキスロボット (WebHook) または飛書/企業のマイクロレターロボットをバインドします

。

連絡先グループの作成: 関連する連絡先を同じグループ (「コア運送グループ」や「当直スタッフグループ」など) に移動します。

経験談: ホッチキス/飛書群ロボットにアクセスすることを強くお勧めします。従来のメール (ハングアップしやすい) やメール (嫌がらせでブロックされやすい) に比べて、グループロボットは @ 全員の機能に合わせて緊急時の応答速度が最も速い。

三、実践演習：CPUおよび帯域幅のアラートルールを段階的に設定する

準備ができたら、私たちは正式に警告ルールの作成プロセスに入ります。

1. アラートルール作成画面へのアクセス：コンソールのナビゲーションから。

阿里雲コンソールにログインし、上部の検索欄に「クラウド監視」と入力してアクセスします。左側のメニューバーで順に展開してください

警報サービス

->

アラームルール

、ページ内の

アラームルールの作成

ボタン。

2. 関連リソースと製品を選択し、監視対象を特定します。

製品タイプ: クラウドサーバECSを選択します (共有帯域幅またはSLBの場合は、対応する製品を選択できます)。

リソースの範囲：初期段階ではインスタンスを選択し、監視対象とする主要なサーバーにチェックを入れることを推奨します。サーバ数が多い場合、その後は「アプリケーショングループ」に基づいて統一的に管理することができる。

3.CPU使用率警告ルールを設定する: コア計算指標

「ルールの追加」パネルで、最初のモニタリング指標を追加します。

モニタリング指標：(ECS)CPU使用率（cpu_total）を選択します。

しきい値とレベルの設定: 緊急 (Critical): 連続3サイクル (デフォルト1分) 、CPU使用率 $ \ ge 90 \%$。警告（Warn）：連続3サイクルにわたり、CPU使用率が80%以上です。

通知方法の選択：緊急レベルには電話・SMS・DingTalkにチェックを付ける。警告レベルにはメール・DingTalkにチェックを付ける。

4. ネットワーク帯域幅のアラームルールを設定する：ネットワークスループット指標。

引き続き「ルールを追加」をクリックして、ネットワーク帯域幅に関する指標を設定します

監視指標: (ECS) パブリックネットワーク流出帯域幅 (IntranetOutまたはInternetOut、業務がパブリックネットワークかイントラネットかによって決定) を選択する。

しきい値設定テクニック: 帯域幅アラームは盲目的に比例してはいけません。ECSの実際の構成に合わせてください。たとえば、購入したパブリックネットワークの帯域幅の上限が10 mbpsの場合、警察境界線は警告レベルに設定できます流出速度 $ \ ge 8 \ text{ Mbps}$ (上限に達した $80 \%$)。緊急レベル: 流出速度 $ \ ge9.5 \ text{ Mbps}$ (制限されます)。

5. 通知の送信および適用時間の設定：ルールの作成を完了します。

アラート連絡グループ：先に作成した「コア運用チーム」をチェックしてください。

迷惑防止設定：ルールの適用時間を設定します（例：24時間常に有効）。

高度な構成: アラームの繰り返し頻度を「5分/回」または「15分/回」に設定して、警告嵐の衝撃を避ける。

確認が完了したら、「確定」をクリックしてください。

作成を完了します。

四、アラームがトリガーされた後の検証とトラブルシューティングのロジック

ルールを設定した後、この一連の警告プロセスが有効であることをどのように検証しますか?

1. 検証方法（テストをどのように発動しますか？）

Linuxシステムに標準搭載されているツールを活用して、負荷テストのシミュレーションを行うことができます。

CPU圧力測定: テスト環境でstress -- cpu 2 -- timeout 300sコマンドラインを実行し、CPUを手動でいっぱいにします。

帯域幅の測定: iperf3を使用するか、サーバ内部から外部ネットワークに大きなファイルをダウンロードして、方向の帯域幅を引き上げます。

検証基準: ホッチキス群や携帯電話のメールを観察し、3 ~ 5分以内に阿里雲からの警告通知を正確に受け取ることができるかどうか。

本番環境テスト防犯警告

本番環境での直接的な負荷テストは厳禁です！ アラートの連携検証は、必ずテストサーバー、または新規に作成した仮想インスタンスで行ってください。

2. アラーム発生後のゴールデン3ステップ

CPUや帯域幅の警告を受信したときは、サーバを盲目的に再起動しないでください。次のステップを推奨します

[アラート通知を受信しました]

│

CPU ──> CPU警告 ──> サーバにログイン ──> 「top」/「htop」を実行 ──> 高占有PIDを特定 ──> プロセスログをチェックしたり、異常スレッドを殺したりします

│

└ --> 帯域幅警告 --> コンソールにログイン --> トラフィック監視曲線を見る --> 「iftop'/「nethogs' 」を実行 --> 異常接続IPの識別 --> セキュリティグループのブロックまたは拡張帯域幅の設定

五、企業運営次元の拡張思考: アカウントと資源の規範管理

一連の監視警報システムを構築する過程で、技術配置自体を除いて、多くの企業は無視しがちです。

インフラストラクチャーの基盤資産の安全性とアカウント運用の規範

。

業務規模の拡大に伴い、多くのチームは複数アカウント管理、プロジェクト独立決済または海外業務展開のニーズに直面している。この過程で、関係しているのは

Alibaba Cloudアカウントの購入

アカウントの実名認証と権限の隔離は特に重要です。

権限の最小化の原則: 運送技術者や監視サービスに管理者のグローバルな最高権限を直接割り当てないでください。RAM (アクセス制御) を使用して専用のロールを作成し、クラウドモニタリング (CMS) の読み書き権限のみを付与することをお勧めします。

アカウントアーキテクチャの構築: 複数の環境 (開発、テスト、生産) 隔離が必要な会社に対して、合理的な阿里雲アカウント購入とアーキテクチャ計画はソースからリスクを隔離できる。生産環境の警告はコア運送チームに直接ドッキングし、リングを開発する

国境の警告は具体的な研究開発者に配布され、互いに干渉しないようにし、権利責任を明確にする。

ライフサイクル管理: クラウドサーバECSの継続料金でも、アラームルールの進化を監視するにも、アカウントの下のリソースライフサイクルと強く結びつけなければならない。サーバが解放された場合、対応する警告ルールも同期して整理し、無効な警告ゴミが発生しないようにしてください。

結び

リアルタイム警告は運送次元の仕事量を増やすためではなく、逆にエンジニアに「マイナス」を与えるためである。

合理的でしきい値科学的な阿里雲CPUと帯域幅警告システムを設計したのは、サーバーに24時間パトロールを続けた「警備員」のようだ。指標がすべて正常なときは、安心して寝ることができますリスクが現れたとき、それは最初の時間に最も正確な情報をあなたの手に送って、故障を揺りかごの中で殺すのに役立ちます。

今夜仕事が終わる前に、10分で阿里雲コンソールにログインして、あなたのサーバーの警告ルールが設定されていることを確認してください