本文主要关注的是数据库端的安全接入认证和访问可行性验证，因为越来越多的数据安全事故，个人或公司逐步对数据或机器安全性要求都比较关注，所以监控系统在页面管理、用户管理、客户端指令执行、数据库等都需要注意安全性。

同时本文的VM集群的数据来源是以prometheus为例，请跟进实际部署或使用的需要将prometheus换成其他的数据源。

1、 框架一

nginx的稳定性和易用性早已被实践证明其可靠性还是很高的，同时我已在nginx框架下测试了其在高数据量下验证了其比较低的资源占用率，所以本框架以nginx为安全接入管理口，统筹负责认证，数据写入、数据查询、负载均衡等。

考虑到后续数据库端同时要给prometheus端、页面展示端和各api接口操作使用，所以在安全验证上使用了用户名和密码的验证方式，支持多个用户名和密码。已验证可行性框架设计如下图所示：

 

VictoriaMetrics集群nginx victoriametrics 集群部署_负载均衡

 

  

2、 框架二

本框架中我们使用了VM自身具有的工具程序：vmauth，其具有安全接入认证，数据写入、数据查询的功能。在数据量为每秒50万+ 的情况下（每秒查询4000 metric，查询15分钟时间段内）vmauth的资源占用率比较低（逻辑cpu 24个）：cpu 1%-2.3%，不占用内存。

Vmauth只支持用户名和密码的验证，且用户名不可重复(写入时一个用户、读取时一个用户)，同时只支持远程写入或读取一个指定的IP或URL，个人觉得这是其比较遗憾之处，认证方式和读写都只是一对一的（不过vmauth也在逐步随着vm升级而更新中）。

已验证可行性框架设计如下图所示：

 

VictoriaMetrics集群nginx victoriametrics 集群部署_用户名_02

此时promethues中的远端写配置为： 

remote_write:
- url: "http://x.x.x.x:8427/api/v1/write"
  name: vm
  queue_config:
    max_samples_per_send: 20000
    max_shards: 100000
    capacity: 5000
  basic_auth:
     username: hao
     password: 888

grafana上的配置
http://x.x.x.x:8427

总结：结合两个框架，功能上虽然都可以实现我们的需求，但是考虑到要做成高可用的集群使用：nginx集群或vmauth集群，也为了后续集群设计中对外提供统一的访问IP或接口，个人觉得还是使用nginx更好些，因为vmauth集群搭建时不仅要设计有其他程序实现负载均衡还需考虑其自身框架设计的能够支持多读、多写（存储集群高可用，高可靠设计时会保证数据的可靠性），这势必会增加更多模块的依赖性和关联；而nginx其本身可支持负载均衡，只需要再设计其高可用即可。所以我觉得还是第一个框架比较跟有优势。