前回のブログでは、我々はパフォーマンステストの話を、私たちは話をしていますか？パフォーマンステストの話を目的と性質があります。パフォーマンステスト、監視、分析およびチューニングは、コアはまた、大部分を占めています。
パフォーマンス分析の目的は、システムのパフォーマンスのボトルネックとリスクの存在を確認することである、パフォーマンスチューニングは、より少ないリソースでより良いサービスを提供することが可能です。キーポイントは、することです関連指標を監視し、負荷を生成します。
初期のテストパフォーマンスの研究のための需要は、準備作業を開始する前に、円滑かつ効率的に行うことができるポストチューニングの監視と分析を確保することです。含める必要があるので、完全な監視システム、？
このブログ、私は実際には仕事だけでなく、指標とツールが含まれており、比較的完全な監視システムを監視する方法について話しています。。。
モニターグレーディングシステムを伝える前に、次の概念を理解することが必要です。
APM（アプリケーションパフォーマンス管理）：アプリケーションのパフォーマンスと可用性の監視と管理。
狭義の中に、アプリケーションインターフェースとエラー性能監視、分散リンクトラッキングコール、ならびに診断のための情報を監視する他の種類（等メモリ、スレッド、）などのアプリケーションを、監視APM単一の指など。
広く APM、また、携帯電話アプリ端監視、ページ終了モニタリング、容器、サーバ監視、およびそのようなコンテナ、データベース、および監視の他の側面のような他のミドルウェアプラットフォームコンポーネントを含む、事故のアプリケーション層の監視に加えました。
監視APM の目的は：主に以下の2つの側面が含まれています。
1、事前に：タイムリーな警告が障害を発見しました。
2、イベント後：場所の問題を追跡するための詳細なデータを提供します。
グレーディングシステムの監視
まず、ミドルウェア監視
ミドルウェアの監視では、主に以下の2つの側面が含まれています。
1、キャッシュ
IOPSは：一般的にコンピュータストレージ性能試験で使用した測定方法を指し、それは毎秒読み取りおよび書き込み時間とみなすことができます。
ヒット数：キャッシュヒット率がパフォーマンス監視の重要な指標であるが、それはキャッシュからデータを読み取るためにパーセントのアプリを指し、高いヒット率、待ち時間のサービスを下げ、より良いパフォーマンス。
接続は：Redisのに作成した接続要求のHTTPキャッシュの数を意味し、最大接続数10,000でした。目的は、キャッシュの負荷が高すぎる雪崩が得られている防ぐために、接続の数を監視することです。
2、メッセージキュー
トピック：トピックのミドルウェアメッセージキュー（カフカ、MQ）は、メッセージタイプを指します。パブリッシュ・サブスクライブ・モデルを使用して、メッセージコンシューマのタイプはに加入して扱います。
QPS：主QPSは、アプリケーションサービスの単位時間当たりの量を要求受信荷重を測定するために使用される秒あたりの要求の数、すなわち、性能試験、。
メッセージの総量：ピーク負荷シフト、パフォーマンスを向上させる目的を達成するために非同期モードで処理されたメッセージのメッセージキュー。しかし、自身の保有のニュースが限定されています。こうしてメッセージを監視メッセージバックログを防止するだけでなく、本質的な部分を監視するの合計量。
第二に、測定された圧力データの監視
1、インデックス
TPS：秒あたりのトランザクション。性能試験では、主にリクエストのサーバ単位時間の能力を測定するために使用されます。
ART：時間の期間、システムの性能を測定する重要な指標である要求を処理するための平均時間を測定するためのサーバーの平均応答時間。
99RT：特定の範囲内の要求の平均応答時間の99％。多くの要因に起因するが、要求分布ムラは時間がかかるので、99％の利用可能性は、RTは、別の次元から、システムのパフォーマンスを測定することができます。
エラー％：エラーレート。もちろん、対応する要求成功率、サービスの成功率があり、これらの指標は、各次元計測システムの視覚的なパフォーマンスすることができます。
2、ツール
JMeterの：Javaのオープンソースのパフォーマンスは、それ自体がサポートしている二次開発は、業界が今より広くツールの負荷を使用していることをコンポーネントの監視の富を提供ツールをテスト。
LoadRunnerは：事業費のパフォーマンステストツール。
第三に、リンク監視
自明リンク監視の重要性、サービス監視のニーズを満たすために、時系列データベースに基づいて監視警報システムを構築するには、我々はより良いシステムの問題を配置支援することができ、さらには自動（初期の）問題を見つけます。
1、インデックス
JVM
2、ツール
ネコ
Zipkin、ピンポイント、skywalking：他の同様のツールがあります。
四、DB監視
主に以下の指標を監視するために、データベースのパフォーマンス・テストを監視します：
CPU：CPUリソースの消費量は、DBがハングアップした場合、すべてのサービスの全体は、それがユーザーにサービスを提供することはできません、指標として重要です。
慢sql：即当前正在执行的耗时比较长的SQL语句，这些是影响DB性能的重要因素。
最大连接数：即DB可支持的同时保持请求连接的数量。
五、日志监控
日志的重要性不言而喻，基本上绝大多数的监控系统都是基于日志来进行聚合展示，排查问题的。最常见的日志监控系统，就是所谓的ELK。
现在共有云服务基本都提供日志服务，比如阿里云的logstore。
六、安全监控
一般性能测试过程中，涉及安全的部分比较少，但数据信息的安全是很重要的。对于中小型企业而言，安全监控，一般都是利用专业的三方厂商工具来进行。
PS：一般安全部门为了更好的监控，会在防火墙和网关之间搭建一层WAF来更好的保障安全，但WAF层会有一定的延时，性能测试，有时候需要关注这一层。
七、API监控
性能测试过程中，无论是前期的流量模型评估还是压测过程中的实时监控，对于API层的监控，都是很重要的。且很多时候，压测报错，都是API的各种问题。
可用性：API能否像它所承诺的提供正常的服务（处理能力）。
正确性：API对用户请求的正确处理表现。
八、业务监控
业务监控的重要性不言而喻，无论是对于数据分析还是服务可用性评级，都是很重要的。以电商系统而言，常见的监控指标有：PV、DAU、每分钟订单量/支付量。
九、客户端监控
这里为什么要提到客户端监控，因为用户端可用才是真正的可用！！！（所谓的可用性，一定是业务/用户可用）
客户端监控主要关注这几项指标：
页面打开速度（测速）
页面稳定性（JS Erro）
外部服务调用成功率（API）
可以通过监控大盘的方式，来多维度的展示相关的监控指标，比如：
十、服务资源监控
服务资源监控，作为性能测试和运维体系中最基本的监控，目的是对系统不间断实时监控，实时反馈系统当前状态，保证服务可用性安全性，保证业务持续稳定运行。
监控主要关注如下指标：
CPU：Total%、Sys%、User%、每个CPU%；
磁盘：读写吞吐率（MBps）、读写次数（次/s）；
内存：Menery%、free-memory、SWAP%；
网络：网卡出/入带宽（kbps）、网卡出/入包量（个/s）、TCP连接状态；
进程：进程端口、Run queue；
Point：上下文切换、运行队列；
本篇博客的主要目的是建立一个较为完善的监控知识体系，文中的示意图都是基于grafana搭建的，内容仅供参考。。。