システム監視と同様に、指標を監視するために必要なもの最後に、適用前に決定する最初の必要性を監視するシステムを構築します。具体的には、明確にするために、どのような指標を素早くアプリケーションのパフォーマンスの問題を識別するために使用することができます。
システムリソースの監視、利用方法は簡単かつ効果的であるが、それは監視への応用という意味ではありません。例えば、低くてもCPU使用率でアプリケーションには、パフォーマンスのボトルネックが存在しない説明できないとき。ロックまたはRPCコール、など、遅い応答をもたらすためのアプリケーションであってもよいからです。
そのため、アプリケーションのコア指標は、もはやリソースの使用ではありませんが、リクエスト、エラー率と応答時間。これらの指標は、直接ユーザーエクスペリエンスに関連するだけでなく、全体的なアプリケーションの可用性と信頼性を反映していないだけ。
要求、応答時間と3個の金メダルのインデックスの後のエラーレートの数と、我々はすぐにアプリケーションのパフォーマンスの問題が発生するかどうかを知ることができます。パフォーマンスの問題が発生したのでしかし、これらの指標だけ明らかにまだ十分ではありません、我々はまた、すぐに見つけることができるようにしたい「ボトルネックエリアを。」アプリケーションを監視する場合ので、私の意見では、いくつかの指標以下、それも不可欠です。
最初のアプリケーション・プロセスのリソース使用されるようなプロセスとしては、CPU、メモリ、ディスクI / O、ネットワークなどにかかり。、あまりにも多くのシステムリソースを使用して、低速アプリケーション応答をもたらすか、エラーの数を増やすことは、最も一般的なパフォーマンスの問題の一つです。
第二は、アプリケーション間の状況呼び出すことで、このようなコール頻度、ようにエラー、遅延や数などを、。アプリケーションが分離されていないので、それは他のアプリケーションのパフォーマンスの問題は、性能はアプリケーション自体によって影響される場合に依存します。
第三には、アプリケーションの内部コアロジックの動作であるような時間のかかるプロセスとして、エラーの重要な側面の実装。これは、アプリケーションの内部状態であるので、通常、あなたは詳細なパフォーマンスデータに外部から直接取得することはできません。したがって、これらの指標の設計と開発中のアプリケーションは、その内部監視システムは、状態を実行することができます理解するためにそれを提供する必要があります。
リソース利用指標は、アプリケーション・プロセスを持って、あなたが原因発生し、システムリソースの不足までのパフォーマンスの問題を見つけてすぐにアプリケーションに関連付けられたシステムリソースのボトルネックを置くことができます。
-
アプリケーション間の通話指標を使用すると、すぐに最終的に犯人コンポーネントのパフォーマンスの問題である要求コールチェーンのプロセスを、分析することができます。
-
コア業績内部のアプリケーションロジックと、あなたはさらに行くことができ、内部アプリケーションへの直接アクセスは、最後の位置決めは、パフォーマンスの問題を処理機能リードのどの部分です。
これらのアイデアに基づいて、私は、あなたが構築することができると信じてステータスインジケータを実行しているアプリケーションのパフォーマンスを記述する。そして、監視システム上で私たちにこれらの指標は、（そのようプロメテウス+ Grafanaとして）述べたように、あなたは、関連するチームのプロセスに警報システム、タイムリーな報告の問題によって、一方で、システムの監視を好むことができ、一方、直感的な通過グラフィカルインターフェイス、動的な表示アプリケーションの全体的なパフォーマンス。
また、業務システムのためには、一般的に、複雑な分散型コールチェーンを形成するために、複数の一連のサービスを必要とするだろう。すぐにパフォーマンスのボトルネックに、クロスアプリケーションを見つけるために、あなたはまた、完全なリンクトラッキングシステムを構築するためにZipkin、ジャガールクルト、ピンポイント、およびその他のオープンソースツールを使用することができます。
たとえば、次の図は、ジャガールクルト、コールチェーントレースの一例です。
完全なリンクトラッキングは、問題の根本である部分、リクエスト処理中に、あなたはすぐに見つけることができます。例えば、上記の画像から、あなたは簡単に、これはRedisのタイムアウトによる問題であることがわかります。
全体のリンクの追跡に加えて、あなたはすぐにクロスアプリケーションのパフォーマンスの問題を見つけることができます、だけでなく、あなたがラインシステムトポロジ呼び出しを生成することができます。これらの視覚的トポロジー、（例えばマイクロサービスのような）複雑なシステムを分析するために特に有用です。
ログ監視
あなたはすぐにボトルネックの位置を特定することができ、モニタのパフォーマンス・メトリックは、発生しますが、指標は、多くの場合、十分ではない場合に限ります。たとえば、リクエストパラメータが同じ時間に渡されていない同一のインタフェースは、それは完全に別のパフォーマンスの問題につながる可能性があります。だから、インデックスに加えて、我々はまた、コンテキスト情報のこれらの指標を監視する必要がある、とログは、これらのコンテキストの最高のソースです。
比較のために、
-
インジケータは通常リアルタイムモニタリングに適した時系列的に処理された特定の測定期間の数値データです。
-
ログは、ログメッセージは、クエリとメタアナリシスへのインデックスに検索エンジンの通常の必要性、後に、時点文字列である、完全に異なっています。
ログ監視は、最も古典的な方法はElasticsearch、LogstashとKibanaこれら3つの成分の組み合わせを使用ELKテクノロジ・スタックを使用することです。
以下に示すように、それは古典的なELKアーキテクチャ図です。
これらのうち、
-
Logstash 负责对从各个日志源采集日志，然后进行预处理，最后再把初步处理过的日志，发送给 Elasticsearch 进行索引。
-
Elasticsearch 负责对日志进行索引，并提供了一个完整的全文搜索引擎，这样就可以方便你从日志中检索需要的数据。
-
Kibana 则负责对日志进行可视化分析，包括日志搜索、处理以及绚丽的仪表板展示等。
下面这张图，就是一个 Kibana 仪表板的示例，它直观展示了 Apache 的访问概况。
值得注意的是，ELK 技术栈中的 Logstash 资源消耗比较大。所以，在资源紧张的环境中，我们往往使用资源消耗更低的 Fluentd，来替代 Logstash（也就是所谓的 EFK 技术栈）。
小结
今天，我为你梳理了应用程序监控的基本思路。应用程序的监控，可以分为指标监控和日志监控两大部分：
-
指标监控主要是对一定时间段内性能指标进行测量，然后再通过时间序列的方式，进行处理、存储和告警。
-
日志监控则可以提供更详细的上下文信息，通常通过 ELK 技术栈来进行收集、索引和图形化展示。
在跨多个不同应用的复杂业务场景中，你还可以构建全链路跟踪系统。这样可以动态跟踪调用链中各个组件的性能，生成整个流程的调用拓扑图，从而加快定位复杂应用的性能问题。