Nightingale滴滴夜莺监控系统入门（四）--聊聊夜莺的后端储存

Nightingale滴滴夜莺监控系统入门（四）—聊聊夜莺的后端储存

1-默认版本

默认是使用夜莺的两个组件来实现：TSDB+INDEX

TSDB实际上使用的是老牌的图形数据库rrdtool，记录ts和value，有很多老牌的监控使用比如Cacti；INDEX是索引模块，夜莺把监控metric记录在这里，查询数据的时候是通过索引去查询；

存储目录分别对应
TSDB:/home/n9e/data
INDEX:/home/n9e/.index

[root@n9e data]# tree
.
└── 8011
    ├── 00
    │   └── 008eda9f02684c8e39c600da1d70c0d3_GAUGE_30.rrd
    ├── 03
    │   └── 0390f9f1acaf9d6856ead184fdbce879_GAUGE_30.rrd
    └─── 04
        └── 0449c36de47cbf0c000b1f441cc62b30_GAUGE_30.rrd
[root@n9e .index]# tree
.
└── db
    ├── endpoint
    │   └── 192.168.21.216
    └── nid
        ├── 15
        ├── 16
        └── 17

优点：

• .rrd文件是新增metric就被新建了，且文件大小不会随数据增多而增加，新数据是被插到环形图里；利于后期维护，避免磁盘不足数据无法写入的情况；
• 新数据保存在内存中，可以设置保存近N个时间内的数据存在内存，提高查询效率；
• tsdb会降采样，老数据会有归档策略；
• 时序数据库的使用肯定是比zabbix这种还在用关系型数据库的监控要高效的多；

缺点：

• 对磁盘IO要求较高，滴滴内部用的是NVME的固态；
• 多节点时，index支持集群部署，但是全量索引；

tsdb也支持多集群多写，index+tsdb的这种形式是经过滴滴，小米这些公司生产验证过，稳定性还是可以的。

2-M3DB

从3.X版本以后，夜莺开始支持M3DB，而且也是被强烈推荐

M3DB是UBER开源出来的，m3在uber声称存储了66亿监控指标，有点牛皮。

2-2 安装M3DB

安装单节点的m3

1，下载夜莺团队打包好的压缩文件
[root@n9e home]# wget https://s3-gz01.didistatic.com/n9e-pub/tarball/m3dbnode-single-v0.0.1.tar.gz
[root@n9e home]# tar -zxf m3dbnode-single-v0.0.1.tar.gz
[root@n9e home]# cd m3dbnode-single

2，执行安装脚本
[root@n9e m3dbnode-single]# bash scripts/install.sh

3，安装速度很快，接下来新建数据库，耗时较长
[root@n9e m3dbnode-single]# curl -X POST http://localhost:7201/api/v1/database/create -d '{
  "type": "local",
  "namespaceName": "default",
  "retentionTime": "12h"
}'

4，安装完以后查看placement，为了方便查看，使用jq来格式化，没有安装的请yum install -y jq来完成，需要提前设置好EPEL源。
[root@n9e n9e]# curl http://localhost:7201/api/v1/placement | jq .
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  5523    0  5523    0     0   528k      0 --:--:-- --:--:-- --:--:--  539k
{
  "placement": {
    "instances": {
      "m3db_local": {
        "id": "m3db_local",
        "isolationGroup": "local",
        "zone": "embedded",
        "weight": 1,
        "endpoint": "127.0.0.1:9000",
        "shards": [
          {
            "id": 0,
            "state": "AVAILABLE",
            "sourceId": "",
            "cutoverNanos": "0",
            "cutoffNanos": "0"
          },

····

可以看到shards都是处于AVAILABLE状态

2-3 切换夜莺的后端存储

修改transfer文件

backend:
  datasource: "m3db"  # 选择 m3db 为索引和存储源
  m3db:
    enabled: true  # 开启 m3db
    name: "m3db"
    namespace: "test"
    seriesLimit: 0
    docsLimit: 0
    daysLimit: 7                               # 查询时的最大时间限制
    # 读写数据时一致性检查的等级，请参考官方文档
    # https://m3db.github.io/m3/m3db/architecture/consistencylevels/
    writeConsistencyLevel: "majority"          # one|majority|all
    readConsistencyLevel: "unstrict_majority"  # one|unstrict_majority|majority|all
    config:
      service:
        # KV environment, zone, and service from which to write/read KV data (placement
        # and configuration). Leave these as the default values unless you know what
        # you're doing. 请与m3.dbnode 的配置保持一致
        env: default_env
        zone: embedded
        service: m3db
        # 以下是 etcd 的配置
        etcdClusters:
          - zone: embedded
            # 单机版的话，endpoints这部分一定要配置为127.0.0.1的
            endpoints:
              - 127.0.0.1:2379
            # 单机版不需要搞证书，单机版的etcd是内嵌在m3dbnode里的，把tls相关的这4行注释掉
            #tls:
             # caCrtPath: /opt/run/etcd/certs/root/ca.pem
             # crtPath: /opt/run/etcd/certs/output/etcd-client.pem
             # keyPath: /opt/run/etcd/certs/output/etcd-client-key.pem

修改monapi

indexMod: transfer # 新增 indexMod 配置
logger:
  dir: logs/monapi
  level: INFO
  keepHours: 24
...

修改judge

query:
  indexMod: transfer # 新增 indexMod 配置
  connTimeout: 1000
  callTimeout: 2000
  indexCallTimeout: 2000
...

重启三个模块

[root@n9e n9e]# ./control restart transfer judge monapi

修改nginx配置，这里只修改为索引从transfer查询

...
location /api/index {
    proxy_pass http://n9e.transfer;
}
...

重启nginx

[root@n9e n9e]# nginx -s reload
[root@n9e n9e]# systemctl restart nginx

切换完成以后，TSDB和INDEX两个组件就可以停止运行了。

集群部署可以查看夜莺官网

2-4 M3DB的优缺点

优点：

• 对硬盘IO要求没那么高了，普通机械硬盘也能抗比较大的量
• 存原始数据，不降采样了，追问题的时候更方便，当然了，存储的数据时长就变短了，相同硬盘空间大小，比如原来rrd可以存1年的历史趋势数据，m3可能只能存1个月
• 扩容非常方便，直接加m3dbnode即可，index+tsdb的方案使用migrate配置，扩容不易
• 容灾更好了，可以设置3副本，如果集群部署了3台机器，挂掉一台机器完全没有影响
• 索引避免了原来index+tsdb的单点容量问题，原来index虽然是可以部署为集群，但是集群里每个节点都是全量索引

劣势：

• 硬盘空间占用大，毕竟存储原始数据嘛，一般生产环境建议存1个月，再久也尽量不要超过3个月，当然了，要监控的设备比较少，部署m3的机器硬盘又比较大，那另当别论
• 内存占用比较多，一般配置是最近两个小时的数据要缓存在内存里，所以比较吃内存，好在内存现在也便宜了，一台机器动不动128G、256G的。

3 influxdb、opentsdb

在transfer.yml配置文件里可以看到，夜莺其实还支持influxdb、opentsdb这些时序数据库作为后端储存，有兴趣的小伙伴可以试一试。

导航: Nightingale滴滴夜莺监控系统入门（一）–夜莺简介
导航: Nightingale滴滴夜莺监控系统入门（二）–单机部署夜莺
导航: Nightingale滴滴夜莺监控系统入门（三）–夜莺页面功能说明
导航: Nightingale滴滴夜莺监控系统入门（五）–采集功能