監視分野における知識システムの徹底的な探求

＃＃＃導入＃＃＃ 監視は、運用とメンテナンス全体、さらには製品ライフサイクル全体において最も重要な部分であり、障害を事前に検出するためのタイムリーな警告を提供し、問題の追跡と特定のための詳細なデータを事後的に提供します。業界には、選択できる優れたオープンソース製品が数多くあります。オープンソース監視システムを選択することは、時間と労力を節約し、最も効率的なソリューションです。もちろん、監視についてあまり詳しくない友人は、次の記事を読むことで監視システム全体についての理解が深まるかもしれません。 1.監視対象

まず、監視とは何か、監視の重要性、監視の目的を理解しましょう。もちろん、誰もが異なる業界、会社、事業、立場におり、監視に対する理解も異なります。しかし、お金を支払う必要があります。監視への注意：特定の監視テクノロジーを使用するのではなく、企業のビジネスの観点から検討する必要があります。

システムの中断のないリアルタイム監視: 実際には、システムの中断のないリアルタイム監視 (これが監視です);

システムの現在の状態に関するリアルタイムのフィードバック: 特定のハードウェアまたは特定のシステムを監視する場合、現在のシステムの状態が正常か異常か、リアルタイムで確認できる必要があります。または欠陥がある;

サービスの信頼性とセキュリティの確保: 当社の監視の目的は、システム、サービス、ビジネスの正常な動作を保証することです。

継続的かつ安定した事業運営を確保：監視が万全であれば、たとえ障害が発生しても、いち早く障害警報を受信し、速やかに対処することができ、継続的かつ安定した事業運営を実現します。ビジネスの内容;

2. モニタリング方法 モニタリングの重要性とモニタリングの目的を理解したところで、次はモニタリングの方法を理解する必要があります。

監視オブジェクトを理解する: 監視するオブジェクトを理解していますか?たとえば、CPU はどのように動作するのでしょうか。

パフォーマンス ベンチマーク指標: このもののどのような特性を監視する必要がありますか?たとえば、CPU 使用率、負荷、ユーザー モード、カーネル モード、コンテキストの切り替えなどです。

アラームしきい値の定義: 何が障害とみなされ、アラームが必要ですか?たとえば、CPU の負荷はどの程度であると考えられますか? ユーザー モードとカーネル モードがそれぞれどの程度実行されているかなどです。

トラブルシューティングのプロセス: 障害アラームを受信した後、どのように対処すればよいでしょうか?もっと効率的なプロセスはありますか?

3. モニタリングコア 監視方法、監視オブジェクト、パフォーマンス指標、アラームしきい値の定義、および障害処理プロセスの手順について学習しましたが、監視の核となるものは何かを知る必要があります。

問題の発見: システムに障害が発生してアラームが発生すると、障害アラーム情報を受け取ります;

問題の位置付け: 障害メールには通常、特定のホスト障害とその具体的な障害内容が記載されます。アラームの内容を分析する必要があります。たとえば、サーバーに接続できない場合、ネットワークの問題なのか、それとも障害なのかを検討する必要があります。負荷が高すぎます。長時間接続できない場合、または特定の開発によりファイアウォール禁止関連ポリシーがトリガーされた場合など、失敗の具体的な原因を分析する必要があります。

問題の解決: もちろん、障害の原因を理解した後は、障害解決の優先順位に従って障害を解決する必要があります。

問題の要約: 重大な障害を解決した後、将来の再発を避けるために、障害の原因と予防策を要約する必要があります。

4. 監視ツール

次に、自社の業務に適した監視ツールを選択する必要がありますが、ここでは監視ツールを簡単に分類してみます

古い監視ツール:

MRTG (Multi Route Trffic Grapher) は、ネットワーク トラフィック グラフの描画に使用できるソフトウェア セットで、スイスのオルテンにある Tobias Oetiker と Dave Rand によって開発され、GPL に基づいてライセンスされています。 MRTG の最良のバージョンは 1995 年に発売されました。Perl 言語で書かれており、さまざまなプラットフォームで使用できます。データ収集には SNMP プロトコルが使用されます。MRTG は、収集したデータを Web ページを通じて描画し、GIF または PNG 形式で画像を描画します。 Ganglia は、クラスターやグリッドなど、クロスプラットフォームでスケーラブルな高性能分散監視システムです。これは階層化された設計に基づいており、幅広いテクノロジを使用し、RRDtool を使用してデータを保存します。ビジュアルなインターフェースを備えており、クラスタシステムの自動監視に適しています。慎重に設計されたデータ構造とアルゴリズムにより、監視側から監視される側への接続オーバーヘッドが非常に低くなります。現在、数千のクラスターがこの監視システムを使用しており、2,000 ノードのクラスター環境を簡単に処理できます。

Cacti (英語でサボテンの意味) は、PHP、MySQL、SNMP、RRDtool をベースに開発されたネットワーク トラフィック監視グラフィカル分析ツールのセットです。snmpget を通じてデータを取得し、描画には RRDtool を使用しますが、ユーザーはRRDtool の複雑なパラメータ。非常に強力なデータおよびユーザー管理機能を提供し、各ユーザーを指定してツリー構造、ホストデバイス、任意の画像を表示でき、LDAP と組み合わせてユーザー認証を行うことができ、テンプレートのカスタマイズも可能です。履歴データの表示と監視という点では、その機能は非常に優れています。

Cacti は、テンプレートを追加することでさまざまなデバイスの監視を再利用可能にし、カスタマイズ可能な描画機能と強力なコンピューティング機能 (データ オーバーレイ機能) を備えています。

Nagios は、サービスの実行状態とネットワーク情報を監視し、指定したローカルまたはリモートのホストとサービスの状態を監視し、異常アラーム通知機能を提供するエンタープライズ レベルの監視システムです。

Nagios は Linux および UNIX プラットフォームで実行されます。同時に、システム管理者がネットワークのステータス、さまざまなシステムの問題、およびシステム関連のログを表示できるようにする Web インターフェイスが提供されます。

Nagios の機能はサービスの可用性の監視に重点を置いており、監視インジケータのステータスに基づいてアラームをトリガーできます。

現在、Nagios も一定のシェアを占めていますが、Nagios では時代の変化に対応できず、監視ニーズの変化に対応できなくなっており、アーキテクチャの拡張性や使いやすさの向上が求められています。高度な機能は Nagios XI のビジネス バージョンに統合されています。

Smokeping は主に、通常の ping、www サーバーのパフォーマンス、DNS クエリのパフォーマンス、SSH パフォーマンスなどのネットワーク パフォーマンスを監視するために使用されます。最下層も RRDtool でサポートされています. 非常に美しい描画が特徴です. ネットワークのパケット損失と遅延は色と影でマークされます. 複数の画像を重ね合わせることができます. その作者は MRTG や RRDtll などのツールも開発しています.

Smokeping の Web サイトは次のとおりです: http://tobi.oetiker.cn/hp

OpenTSDB はオープン ソースの監視システムであり、Hbase を使用してすべての時系列データ (サンプリングは必要ありません) を保存し、分散型のスケーラブルな時系列データベースを構築します。第 2 レベルのデータ収集をサポートし、永続的なストレージをサポートし、容量計画を実行でき、既存の警報システムに簡単に統合できます。

OpenTSDB は、大規模クラスター (クラスター内のネットワーク デバイス、オペレーティング システム、アプリケーションを含む) から対応するコレクション インジケーターを取得し、それらを保存、インデックス付け、提供することで、Web 化、グラフィックスなどのデータを理解しやすくします。 、など。

Ace 監視ツール:

Zabbix は、複数の収集方法と収集クライアントをサポートする分散監視システムです。専用のエージェントを持ち、SNMP、IPMI、JMX、Telnet、SSH などの複数のプロトコルもサポートし、収集されたデータを保存します。データベースに保存し、分析して整理し、条件が満たされたときにアラームをトリガーします。柔軟な拡張性と豊富な機能は、他の監視システムの追随を許しません。相対的に言えば、その全体的な機能は優れています。上記の各種監視システムを比較した結果、Zabbix は機能の豊富さ、拡張性、二次開発性、使いやすさに優れており、少しの学習で独自の監視システムを構築することが可能です。

Xiaomi の監視システム: open-falcon。 open-falcon の目標は、最もオープンで使いやすいインターネットのエンタープライズ レベルの監視製品を作成することです。

サードパーティ監視ツール:

現在市場には、Monitoring Bao、Monitoring Easy、Tingyun などの優れたサードパーティ製モニタリングが数多く存在しており、多くのクラウド ベンダーも独自のモニタリングを持っていますが、ここでは紹介しません。サードパーティによる監視について学びましょう。自分で行うこともできます。公式 Web サイトにアクセスして相談してください。 (宣伝的な発言は避けてください)

5. モニタリングプロセス

上記で多くのことを紹介しましたが、どの監視ツールが最適ですか? Zabbix、Open-Falcon、LEPUS (データベースの監視専用) など、いくつかのオープンソース監視ツールをお勧めします。

ただし、この記事は依然として Zabbix に基づいて監視システム エコシステム全体を構築しています。

それでは、Zabbix のプロセス全体について話しましょう:

データ収集: Zabbix は、SNMP、エージェント、ICMP、SSH、IPMI などを介してシステムからデータを収集します;

データ ストレージ: Zabbix は MySQL に保存され、他のデータベース サービスにも保存できます;

データ分析: 後で障害を確認して分析する必要がある場合、Zabbix はグラフィックスや時間などの関連情報を提供してくれるため、障害の場所を特定できます。

データ表示: Web インターフェース表示 (モバイル APP、java_php も Web インターフェースを開発できます);

監視とアラーム: 電話アラーム、電子メール アラーム、WeChat アラーム、SMS アラーム、アラーム アップグレード メカニズムなど (どのアラームが利用可能かは関係ありません);

アラーム処理: アラームを受信した場合、重要かつ緊急、重要かつ緊急ではないなど、障害のレベルに応じて処理する必要があります。障害のレベルに応じて、関係者と協力して迅速に対処します。

6. モニタリング指標 監視の方法、目標、プロセス、監視に利用できるツールについて学習しましたが、一体何を監視したいのかと疑問に思う人もいるかもしれません。それから私はここでそれを整理しました:

6.1 ハードウェア監視 初期の頃、私たちはコンピューター室の検査を使用して、ハードウェア機器の光の点滅をチェックして、故障しているかどうかを判断していました。これは非常に人的資源の無駄であり、誰もが知っているように、反復的で非技術的な作業でした。

もちろん、IPMI を通じてハードウェアの詳細を監視し、CPU、メモリ、ディスク、温度、ファン、電圧などのアラームしきい値を設定できるようになりました (監視アラームの内容に対して適切なアラーム範囲を自分で書き込むことができます) )

IPMI監視ハードウェアサービス参考資料

6.2 システム監視

中小企業では基本的にLinuxサーバーばかりなので、システムリソースの使用状況を監視する必要があり、監視システムの基本となるのがシステム監視です。

監視対象の主なオブジェクト:

CPU には、コンテキストの切り替え、実行キュー、使用法など、いくつかの重要な概念があります。

これらは、CPU モニタリングのいくつかの重要な指標でもあります。

通常、各プロセッサの実行キューは 3 を超えてはならず、CPU 使用率の「ユーザー モード/カーネル モード」比率は 70/30 に維持され、アイドル状態は 50% に維持されます。コンテキストの切り替えは必要があります。システムの混雑状況にもよりますが、総合的に検討しましょう。

CPU で一般的に使用されるツールには、htop、top、vmstat、mpstat、dstat、glances などがあります。

Zabbix はシステム監視テンプレートを提供します: Zabbix エージェント インターフェイス

メモリ: 通常、メモリ使用量と SWAP 使用量を監視する必要がありますが、同時に zabbix を使用してメモリ使用量曲線グラフを描画し、サービス メモリ オーバーフローなどを見つけることができます。

メモリ用に一般的に使用されるツールには、free、top、vmstat、glances などがあります。

メモリ使用量: IO はディスク IO とネットワーク IO に分割されます。パフォーマンス チューニングを実行するときにさらに詳細なデータを監視することに加えて、毎日の監視ではディスク使用量、ディスク スループット、ディスク書き込みビジーのみに焦点を当て、ネットワークではネットワーク カード トラフィックも監視します。

一般的に使用されるツールには、iostat、iotop、df、iftop、sar、glances などがあります。

その他のシステム監視には、実行中のプロセス ポート、プロセス数、ログイン ユーザー、オープン ファイルなどが含まれます (詳細については、zabbix 独自の OS Linux テンプレートを参照してください)

6.3 アプリケーションの監視

ハードウェア監視とシステム監視を理解したら、次の操作はサーバーにログインして、サーバーが実行しているサービスを確認することです。これらはすべて監視する必要があります。 アプリケーション サービスの監視も、LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq などの監視システムの重要な部分です。関連サービスは、zabbix を使用して監視する必要があります

サービス監視の詳細な操作プロセスについては、以前に著者が書いたので、ここでは一つ一つ説明しません。

Zabbix はアプリケーション サービス監視を提供します: Zabbix Agent UserParameter

Zabbix が提供する Java モニタリング: Zabbix JMX インターフェイス

percona は MySQL データベース監視を提供します: percona-monitoring-plugins

6.4 ネットワーク監視

全国のユーザーを対象としたECサイトでは、各地やコンピュータルームのネットワーク状況を常に把握しておく必要もあります。 ネットワーク監視は、監視プラットフォームを構築する際、特に複数のコンピューター室があるシナリオで考慮する必要があるものであり、各コンピューター室間のネットワーク状態、コンピューター室および国全体のネットワーク状態に焦点を当てる必要があります。では、このステータス情報をマスターするにはどうすればよいでしょうか?ネットワーク監視ツール Smokeping を使用する必要があります。

Smokeping は、rrdtool の作者である Tobi Oetiker の作品です。Perl で書かれています。主にネットワーク パフォーマンス、www サーバー パフォーマンス、DNS クエリ パフォーマンスなどを監視するために使用されます。描画には rrdtool を使用し、配布をサポートします。複数のエージェントから直接データを収集できます。

同時に、監視ポイントが比較的少ないため、Monitoring Bao、Tingyun、Keynote、Borui などの多くの商用監視ツールを使用することもできます。同時に、これらのサービス プロバイダーは、CDN のステータスの監視にも役立ちます。

6.5 トラフィック分析

Web サイトのトラフィック分析は、運用および保守担当者が習得する必要がある知識です。たとえば、電子商取引会社の場合: 注文元の統計と分析を通じて、特定の Web サイトへの広告投資が期待どおりの成果を上げているかどうかを把握できます。

さまざまな地域からの訪問者の数や、商品の取引量さえも区別できます。

Baidu 統計、Google アナリティクス、ウェブマスター ツールなどは、ページに js を埋め込むだけで済みます。

しかし、データは常に相手の手に渡っており、個人的なカスタマイズは不便であるため、Google は piwik というオープンソースの分析ツールをリリースしました

6.6 ログ監視

通常、システムが実行されると、オペレーティング システムはシステム ログを生成し、アプリケーションはアプリケーション アクセス ログ、エラー ログ、操作ログ、ネットワーク ログを生成します。ログ監視には ELK を使用できます。 ログ監視の最も一般的な要件は、収集、保存、クエリ、表示です。

オープン ソース コミュニティには、対応するオープン ソース プロジェクトがあります: logstash (コレクション) elasticsearch (ストレージ検索) kibana (ディスプレイ)

これら 3 つのテクノロジーを組み合わせたものを ELK スタックと呼んでいます。そのため、ELK スタックは、Elasticsearch、Logstash、および Kibana テクノロジー スタックの組み合わせを指します。

ログ情報が収集されている場合、デプロイメントの更新に例外があった場合、kibana 上ですぐに確認できます。

もちろん、Zabbix を通じてエラー ログをフィルタリングしてアラートを生成することもできます。

6.7 セキュリティ監視

4 層 iptables、7 層 WEB プロテクション、Nginx lua、WAF など、多くの Linux オープンソース セキュリティ製品がありますが、関連するログは最終的に ELK スタックに収集され、さまざまな攻撃タイプがグラフィカルに表示されます。しかし、いつも手間がかかるし、個人的にはあまり効果は高くないと思っています。現時点では、サードパーティのサービスプロバイダーに接続することを選択できます。

サードパーティ ベンダーは、サービス、バックドア、データベース、構成検出、CGI、SMTP、およびその他の種類をカバーする包括的な脆弱性ライブラリを提供します

ホストおよび Web アプリケーションの脆弱性を包括的に検出し、独立したマイニングおよび業界共有と組み合わせて、ゼロデイ脆弱性を即座に更新して最新のセキュリティ リスクを排除します。

6.8 API モニタリング

API の重要性がますます高まるにつれ、提供する API が適切に機能しているかどうかを判断するためにそのようなデータも必要になることは明らかです。
API インターフェイスの GET、POST、PUT、DELETE、HEAD、OPTIONS リクエストを監視します。可用性、正確性、応答時間は 3 つの主要なパフォーマンス指標です

6.9 パフォーマンスの監視

Web ページのパフォーマンス、DNS 応答時間、HTTP 接続確立時間、ページ パフォーマンス インデックス、応答時間、可用性、要素サイズなどを包括的に監視します。
Zabbix は URL モニタリングを提供します: Zabbix Web モニタリング

6.10 ビジネス監視

ビジネス指標監視のない監視プラットフォームは、完全な監視プラットフォームではありません。通常、監視システムでは、重要なビジネス指標を監視し、アラーム通知のしきい値を設定する必要があります。

例: 電子商取引業界:

1 分あたりに生成される注文数;

1 分あたりに登録されるユーザーの数;

毎日のアクティブ ユーザーの数;

毎日行われるプロモーション活動の数;

プロモーション活動に参加したユーザーの数;

プロモーションによってどれくらいのトラフィックがもたらされるか;

プロモーションによってどれくらいの利益がもたらされますか?

など重要なインジケーターをZabbixに追加し、画面に表示できます。

7. 監視と警報

障害アラームを通知するにはさまざまな方法があります。もちろん、最も一般的に使用される方法は SMS、電子メール、SMS アラームです

8. アラームの処理

一般的なアラーム後の障害にはどのように対処すればよいでしょうか? まず、アラーム アップグレード メカニズムを通じて自動的に処理できます。たとえば、Nginx サービスがダウンしている場合、Nginx が自動的に起動するようにアラーム アップグレードを設定できます。しかし、一般的なビジネスで重大な障害が発生した場合、通常は障害のレベルや障害の内容に応じて、運用保守担当者を担当させます。もちろん、ビジネス形態やアーキテクチャ、サービスが異なれば採用する手法も異なる可能性があり、適用できる固定のモデルはありません。

9. インタビューモニタリング

運用および保守の面接では、監視に関する質問がよく聞かれますが、この質問にどう答えるか?この記事では、簡単な答えのアイデアを提供します。

ハードウェア監視。 SNMP を介したルーター スイッチ (その方法については、一部のメーカーと通信できます)、サーバー温度などの監視は、IPMI を介して実現できます。もちろん、ハードウェアがなく、すべてがクラウド内にある場合は、このステップをスキップしてください。

システム監視。 CPU 負荷、コンテキストの切り替え、メモリ使用量、ディスクの読み取りと書き込み、ディスクの使用量、ディスクの i ノードの使用量など。もちろん、デフォルト設定では低すぎるため、アラームが頻繁に発生するため、これらをトリガーで構成する必要があります。

サービスの監視。たとえば、同社が使用している LAMP アーキテクチャ、nginx には独自の Status モジュールが付属し、PHP にも関連する Status があり、MySQL は percona 公式ツールを通じて監視でき、Redis はフィルタリングのための独自の情報を通じて情報を取得します。方法は似ています。または独自のサービスを持ち込みます。スクリプトを使用して、監視するコンテンツやアラームおよびグラフィック機能を実装します。

ネットワーク監視。クラウド ホストであり、コンピューター ルームをまたがっていない場合は、ネットワークを監視しないことを選択できます。もちろん、あなたは私たちがコンピューター室などを隔てていると言いました。ネットワーク関連の監視にはスモーキングを使用することをお勧めします。または、業界には専門分野があるため、ネットワーク エンジニアに直接任せることもできます。

セキュリティ監視。クラウド ホストの場合は、独自のセキュリティ保護の使用を検討できます。もちろんiptablesも使えます。ハードウェアの場合は、ハードウェア ファイアウォールを使用することをお勧めします。クラウドを使用すると、1 日のダウンタイムを引き起こす可能性のある誤動作を回避するための DDoS 対策を購入できます。システムの場合は、権限、パスワード、バックアップ、リカバリなどの基本的な解決策が適切に行われている必要があります。 web Nginx Lua を使用して Web レベルのファイアウォールを実装することもできます。もちろん、統合された Openresty を使用することもできます。

ウェブ監視。 Web監視に関するトピックはまだたくさんあります。たとえば、組み込みの Web モニタリングを使用して、ページ関連の遅延、JS 応答時間、ダウンロード時間などを監視できます。ここでは、これを実現するために、Monitoring Bao または Tingyun という専門的な商用ソフトウェアを使用することをお勧めします。結局のところ、コンピューター室は全国にあります。 （マルチマシンルームの場合は別途ご相談させて頂きます）

ログ監視。 Web の場合は、Nginx の 50x および 40x エラー ログ、および PHP の ERROR ログを監視するために使用できます。実際、これらの要件はコレクション、ストレージ、クエリ、表示にすぎず、オープン ソースの ELKstack を使用してこれを実現できます。 Logstash (コレクション)、elasticsearch (ストレージ検索)、kibana (表示)
ビジネス監視。私たちは多くのことを行ってきましたが、最終的には依然としてビジネスの運営を保証しています。この方法によってのみ、私たちが行っている監視は意味をなすことができます。したがって、ビジネスレベルでの監視には、より重要なビジネス指標（会議で確認する必要がある）を監視するために開発およびディレクターとの会議とディスカッションが必要であり、その後、簡単なスクリプトで実装でき、最後にトリガーを設定できます。

トラフィック分析。通常、ログを分析するには awk sed xxx と多数のツールを使用します。これは、IP、PV、UV をカウントするのにあまり便利ではありません。その後、Baidu Statistics、Google Statistics、および Commerce を使用して埋め込みコードを開発できます。プライバシーを回避するために、piwik を使用して関連するトラフィック分析を行うこともできます。

＃＃＃視覚化。 screen を使用したり、サードパーティのライブラリを導入したりしてインターフェイスを美しくすると同時に、注文量の突然の増減にも注意する必要があります。つまり、トラフィックの大きな波が突然やって来ました。このトラフィックはどこから来たのでしょうか?促進されたのでしょうか、それとも攻撃されたのでしょうか?監視プラットフォームを組み合わせて、さまざまなシステム間のビジネス関係を整理できます。

自動モニタリング。上記で非常に多くの作業を行ったので、当然のことながら、キーを 1 つずつ追加することはできません。これは、Zabbix のアクティブ モードとパッシブ モードを通じて実現できます。もちろん、これを API 経由で行うのが最善です。

要約

より完全な監視システムを本当に実現したい場合、現在のオープンソース ソフトウェアでは十分に満足できず、資格のある企業は Xiaomi のオープンソース Open-Falcon など、独自の監視システムを開発し始めています。 Sensu などの比較的優れたオープンソース監視フレームワークに加え、influxdb や grafana もあり、これらを使用して自社に合わせて監視プラットフォームをカスタマイズできます。

もちろん、私が言ったことは非常に単純ですが、私の経験は限られており、私のアイデアが提供できることは限られています。上記は、モニタリングについて私が共有する方法と経験の一部です。 (年寄りはコメントしないでください)

以上が監視分野における知識システムの徹底的な探求の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。