まず、セクションレビュー
前のコンテンツでは、私がアイデアや関連ツール、あなたのためのパフォーマンス分析の多くの原則を導入しました。しかし、分析の実際の性能に、非常に一般的な現象が明らかに場所のパフォーマンスのボトルネックを取っていますが、トラブルシューティングするサーバーにログインするときにということで
候補者を、しかし、ボトルネックが消えていることがわかりました。または、パフォーマンスの問題は、常に時間から時間に起こるが、法律が発生した見つけることは困難である、再現が困難です。
このようなシナリオに直面したとき、あなたは様々なツールの前で私たちを見つけることが、方法は「失敗」。なぜ？彼らはパフォーマンスの問題の時に有効であることが必要であり、これらのシナリオの事後解析では、我々はほとんど送ることはできませんので、
彼らのパワーアップを果たしています。
次に、どのようにそれを行うには？それを無視？実際には、過去に、多くのアプリケーションは、システムやアプリケーションの問題のパフォーマンスを見つけるために、ユーザーが応答が遅い文句を言うまで待つか、システムクラッシュ後になっています。問題を見つけることが最終的にできたが、どうやら、このアプローチは
、ユーザーエクスペリエンスに深刻な影響ので、望ましくありません。
問題が発生したときに、この問題を解決するために、一緒に監視システム、保健システムとアプリケーションの監視を構築し、戦略のシリーズを定義するために、初めてのアラーム通知が必要です。優れた監視システムは、依頼するリアルタイムシステムの多様性を公開することができるだけでなく、
質問をするだけでなく、状況に応じてより正確に関連したチームのプロセスに問題を報告するには、約ボトルネックのソースを自動的に、これらを監視、分析して検索します。
良い仕事の監視を行うために、コアは、システムとアプリケーションの両方を含む包括的、定量的な指標です。
システムから、監視システムは、我々は、CPU、メモリ、ディスクやファイルシステム、ネットワーク、およびその他のシステムリソースの前に言ったような、全体的なシステムリソースの使用状況をカバーします。
アプリケーションから、CPU、ディスク、このような時間のかかるプロセス実行エラーなどのよりインターフェイスコールの必要性を含むプロセスのI / O、全体的な健康、両方を含む内部アプリケーションの動作状態を、カバーする監視システム、内部メモリ使用量、等の目的でなければならない
内部手続きと動作条件。
今日、私は、Linuxシステムを監視する方法を、あなたを見てみましょう。次のセクションでは、私はあなたのためのアプリケーション監視の考え方を説明していきます。
二、利用法
あなたが監視システムを開始する前に、あなたが最も確かにシステムリソースの使用を記述するための簡単な方法を使用する方法を知りたいです。もちろん、使用量は、様々な資源で収集するために列を学んださまざまなパフォーマンスツールを使用することができます。しかし、忘れてはいけない、
各リソースの性能指標には時間がかかりすぎ、多くの指標を使用するの多くを持つことができ、それ自体が、あなたのためのシステム全体の健全性を確立することは容易ではない、言いませんでした。
ここでは、私はあなたにパフォーマンスの監視（利用彩度とエラー）メソッドのための特別な用途をご紹介します。使用法三つのカテゴリー、すなわち、使用、彩度、およびエラーの数に簡略化され、システムリソースのパフォーマンス、。
- 使用率は、キャパシティサービスのための時間やリソースの割合を表しています。100％の使用量は、排出された容量やサービスのすべての時間を示します。
- 彩度は、通常、待ちキューの長さに関連した、リソース忙しいことを示します。100％の飽和、リソースがこれ以上の要求を受け入れることができないことを意味します。
- エラー番号は、エラーが発生したイベントの数を示します。システムのそれより深刻な問題を示すエラーの数、より多くの。
システムリソースの一般的なパフォーマンスのボトルネックをカバーする指標のこれらの3つのカテゴリが、それほど頻繁にすぐにシステムリソースのパフォーマンスのボトルネックを見つけるために使用します。このように、両方のCPU、メモリ、ディスクやファイルシステム、ネットワークのハードウェアリソース、またはファイル記述子の数、さえのための
接続数、接続の追跡番号および他のソフトウェア・リソース、利用方法がある、あなたはすぐに見つけることができますシステムリソースの種類は、パフォーマンスのボトルネックがありました。
そのため、システムリソースのそれぞれ、どのような一般的な性能指標のために？我々が言っているシステムリソースの様々な原理は、関連するパフォーマンス指標を考えることは困難ではないことを思い出してください。ここで、私は一般的なパフォーマンス指標は、テーブルを描い入れ、
必要なときだから、見ることができます。
しかし、利用方法が唯一のシステムリソースのパフォーマンスのボトルネックを反映するために、コア指標に焦点を当て、これは他の重要な指標と言っているわけではないことに留意すべきです。このようなシステムログ、プロセスのリソース使用率、バッファ使用、および指標の他の種類として、我々はまた、監視する必要があり
、それらを。利用方法のインデックスは、直接システムのリソースのボトルネックを示している。しかし、彼らは通常、補助性能分析として使用されています。
第三に、監視システム
マスター使用方法とパフォーマンス指標を監視する必要が後、次のステップは、これらの指標を保存するための監視システムを確立することであるダウンしてから、これらの状態を監視するに応じて自動的に分析し、約ボトルネックの原因を突き止める;介して、最終的にと警報システムの
システム、関連するチームのプロセスへのタイムリーな報告の問題。
図から分かるように、完全な監視システムは、典型的には、データ収集、データ格納、およびデータクエリの処理、ならびにアラームや他の視覚ディスプレイモジュールから構成されています。だから、監視システムを構築するためにゼロからスタートして、それはシステム工学の多くは、実際にあります
しかし、幸いなことに、今、多くのオープンソースの監視ツールは、例えば、最も一般的なのZabbix、Nagiosは、プロメテウス、というように、直接使用することができますがあります。
ここで、私は、これらのコンポーネントの基本原則を紹介するために、例えばプロメテウスがかかります。以下に示すように、基本的な構造はプロメテウスです。
データ取得モジュールを見てください。左端のプロメテウスターゲットは、オブジェクト収集したデータである、と検索は、これらのデータを収集するための責任があります。あなたはまた、図から見ることができ、プロメテウスは、両方のプッシュをサポートしており、二つのデータ収集モードを引き出します。
- 買収をトリガするために、サーバー取得モジュールによって、モードを引き出します。限り取得対象は、HTTPインタフェースを提供して、あなたは（最も一般的に使用される取得モードである）自由にアクセスすることができます。
- プッシュモード、プッシュ・ゲートウェイ・イニシアチブにより各ターゲット取得が（モバイルアプリケーション取得モードの中で最も一般的である）上に引っ張って、ゲートウェイからサーバによって撮影されたプッシュ指数、（データの損失を防ぐため）。
原因オブジェクトは、通常は動的で監視する必要があるため、プロメテウスも自動的に動的に事前設定オブジェクトを監視する必要が発見することができる規則に従って、サービス発見のための機構を提供します。これは、このような容器プラットフォームとしてKubernetesに非常に有効です。
第2のデータ記憶モジュール。監視データの永続性を維持するために、SSD永続ディスク装置に収集されたデータを担うTSDB（時系列データベース）モジュールフィギュア。TSDBは、時系列データのために設計された
時間インデックスの特性に基づいて、種類のデータベース、および追加の方法で書き込まれたデータの量。
第三のデータクエリー処理モジュールです。ただ、TSDBを述べ、データを格納しながら、実際には、また、基本的なデータクエリおよびデータ処理能力を提供し、これはPromQL言語です。PromQLは単純なクエリ、フィルタリングを提供し、
そして基本的なデータ処理方法をサポートする警報システムと視覚的表示のための基礎です。
第四は、アラームモジュールです。右上のAlertManagerに基づくトリガPromQL言語、構成管理、アラームルールにそうアラームを送信して含め、アラーム機能を提供します。しかし、警告が必要であるが、にもかかわらず、あまりにも多くの場合、アラーム
は明らかに望ましくありません。したがって、のAlertManagerは、パケット、無音抑止または重合グレードを警告、およびアラームの数を減らすために他の手段をサポートしています。
最後のものは、ビジュアルディスプレイモジュールです。プロメテウスのWeb UIはPromQLクエリを実行するためのシンプルなビジュアルインターフェイスを提供しますが、結果はかなり単調示しました。しかし、一度Grafanaと、我々は非常に強力な構築することができます
グラフィカルインターフェイスを。
これらのコンポーネントの上に導入され、あなたは、各モジュールの比較的明確に理解している必要があります。次に、私たちはこれらのコンポーネントコンバインの全体的な機能を理解していきましょう。
例えば、今述べた方法を使用するためには、例えば、私はプロメテウスを使用するには、さまざまなリソースのLinuxサーバのCPU、メモリ、ディスク、ネットワーク、および飽和エラー指標の利用を収集することができます。その後、Grafanaと
PromQLクエリは、あなたが道を示すために、直感的なグラフィカルインタフェースでそれらを置くことができます。
IVの概要
今日、私はあなたが一緒にシステム監視の基本的な考え方を整理取ります。
コアシステムの監視はCPU、メモリ、ディスク、ファイルシステム、ネットワーク・ハードウェア・リソース、ならびにファイル記述、接続の数、接続の追跡番号およびその他のソフトウェアリソースを含むリソース、を使用することです。これらのリソースは、使用によって、法の中核を構築するために使用することができる
エネルギー指標。
使用法三つのカテゴリー、すなわち、使用、彩度、およびエラーの数に簡略化され、システムリソースのパフォーマンス、。これは、3つのカテゴリーのいずれかに時間が高すぎる、対応するシステムリソースが性能ボトルネックが存在してもよい表します。
確立パフォーマンス指標は、メソッドを使用した後に基づくだけでなく、収集、格納、クエリ処理から、アラームと視覚表示と他の一連の完全な監視システム、これらの指標を介してです。あなたはZabbixの、プロメテウスやその他のオープンソースに基づくことができ
、この監視システムを構築するために、監視製品。このように、すぐにさらさシステムリソースのボトルネックが、あなたはまた、歴史的な監視を使用することができ、その後の位置の問題をトレースするだけではなく。
もちろん、システムの監視に加えて、アプリケーションの監視が不可欠である、と私はあなたのために次のレッスンを解体まいります。