哨兵系统：（参考）
目的：实现对实例和基本监控项的监控
实际操作：
具体实现这里参考的是redis的哨兵监控
1、通过编辑配置文件来启动哨兵
具体操作是针对配置文件：.conf 文件， 并修改其监控的主数据库信息
eg：
sentinel monitor mymaster 192.168.186.100 6379 1
mymaster是监控的主数据库的名称，可以自定义，将其与 192.168.186.100 绑定即可； 6379 端口号； 1 表示最低通过票数；以DDB一个用例为例
我们这边形式是10.160.247.164:4334:mmusic4
2、启动哨兵
这里截取最后4行的日志信息，学习基本命令
3256:X 09 Mar 07:46:54.142 # Sentinel ID is 285f3e0832faf2c4c94a7ce89c2011fe76beb797
3256:X 09 Mar 07:46:54.142 # +monitor master mymaster 192.168.186.100 6379 quorum 1
3256:X 09 Mar 07:46:54.147 * +slave slave 192.168.186.100:6380 192.168.186.100 6380 @ mymaster 192.168.186.100 6379
3256:X 09 Mar 07:46:54.151 * +slave slave 192.168.186.100:6381 192.168.186.100 6381 @ mymaster 192.168.186.100 6379
+monitor： 哨兵监控的主数据库名称及其 ip地址， 端口号等；
+slave： 表示新发现了从数据库， 显然哨兵发现了两个从数据库；
3、过程监测（日志代码说明）
+sdown：表示哨兵主观认为主数据库服务停止了；
+odown：表示哨兵客观认为主数据库服务停止了；
此时哨兵开始执行故障恢复，挑选一个从数据库， 将其升级为 主数据库， 输出如下内容：
+try-failover： 表示哨兵开始进行故障恢复；
+failover-end：表示哨兵完成故障恢复， 过程复杂， 包括领头哨兵选择，备选从数据库的选择等；
4、最终输出（日志代码说明）
+switch-master： 表示主数据库从 6379 端口迁移到 6380 端口上了；即 6380端口上的redis 服务升级为 主数据库；
+slave ：列出了两个新的从数据库， 包括 6381 和 6379；
故障恢复后， 可以info replication 检查6380 和 6381 上的复制信息；
以上是针对具体实例的一个监听过程，我们这里做的是平台信息汇总
性能测试中最关注的是吞吐量TPS、响应时间、错误率等
响应时间：网络相应时间+程序相应时间
TPS：是软件测试结果的测量单位，一个事务指的是客户向服务器发送开始计时，服务器响应计时结束，以此来计算使用的时间和完成的事务数，使用加权协函数平均来计算客户得分，一般来说系统的吞吐量取决于系统事务最低处理能力的模块的TPS
吞吐量：测试过程中每秒从服务器返回的字节数
PS：
1、TPS标准差/TPS Average>8%,或者<2%则系统存在性能瓶颈
2、当增大系统的压力 ( 或增加并发用户数 ) 时，吞吐率和 TPS 的变化曲线呈正比变化，则系统基本稳定
3、若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，同时 TPS 也趋于平坦，查看系统资源使用，如果资源使用率比较高，则说明服务器硬件资源存在问题，需要拓展硬件或者优化应用。反之，则说明服务器硬件资源不存在问题，查看网络流量，估计网络带宽存在问题。
4、点击率 /TPS 曲线出现变化缓慢或者平坦 , 很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题或者应用问题
Grinder框架的运行机制
console作为worker process和agent process的一个连接，agent与console建立连接，然后传递给worker，worker也和console连接返回的是统计的数据。worker连接的是test code，这里的test code有两种形式，有一种是Grinder自编码脚本，我看了一个实例，主要代码结构是导入模块（import）、导入test（以python字典形式）、日志网址信息等路径设置、定义test runner类（主要包括随机处理test模块、检测http，如果检测异常输出异常文件）；另一种是TCP代理录入生成的测试脚本，这里主要注意的是测试脚本中不含cookie参数，这里需要手动添加，首先客户端通过http request（URL）发送请求，服务器就收请求生成Set cookie报头，通过http header来传递cookie参数，读取参数，结束后服务器传回cookie报头，输出生成结果数据，如果服务器未接受成功通过http post和http get追踪定位错误；最终会输出out log文件，包括data、error和out文件
Grinder的实际操作流程
主要是grinder.properties路径配置，通过java来打开Console、Agent process，Agent process启动后会自动连接控制台，如果控制台没有指定代理进程要使用的测试脚本，代理进程会去读取自己本地的grinder.properties配置文件中指定的脚本执行测试。如果是通过代理生成测试脚本，需要通过java 启动代理，然后进行相应操作生成文件保存为 grinder.py。记录测试脚本后可以通过两种方式运行测试脚本，一是在每个Agent process的本地grinder.properties文件中用grinder.script参数指定要执行的脚本；二是在控制台分发你的脚本到每个Agent process， 然后运行即可
Grinder实际进行测试的操作流程参考
（以上为本人理解，之后实操的时候回补全代码部分理解）
