0x00 唠叨

遇见了、记下了,后面或许会遇见;经历过的事件只记下了标签、这里或许是个解答题
部分问题会因使用版本或场景解决方案不一,仅供参考 如有雷同 纯属我剽;

0x01 Prometheus 问题

升级 Prometheus

大致时间 2017Q3 当时 Prometheus 出了 2.0,tidb-ansible 默认部署 1.8 的版本
2.0 版本有一些我也不知道的优化(迷信新版本肯定有提升);然后尝试在 1.8 上升级新版本遇见的故事

Prometheus 升级方案比较简单,和 TiDB 相同都是由 golang 语言开发和静态编译的 binary,替换新的 binary 文件然后重启服务即可生效。然我没看官方文档的亏,替换后升级失败;向 GitHub repo 学习后发现 1.8 和 2.0 底层 openTSDB(官方自称,资料查询是 levelDB 进化而来 ) 时序数据库不兼容了,也就是 2.0 版本无法读取和写入 1.8 版本生成的数据。哎…… 数据不过渡啊、更换目录后折腾发现配置文件还有部分不兼容

1
2
3
4
time="2017-08-08T15:38:30+08:00" level=info msg="Starting prometheus (version=1.5.2, branch=master, revision=bd1182d29f462c39544f94cc822830e1c64cf55b)" source="main.go:75"
time="2017-08-08T15:38:30+08:00" level=info msg="Build context (go=go1.7.5, user=root@a8af9200f95d, date=20170210-14:41:22)" source="main.go:76"
time="2017-08-08T15:38:30+08:00" level=info msg="Loading configuration file /tidb-data/tidb/deploy/conf/prometheus.yml" source="main.go:248"
time="2017-08-08T15:38:30+08:00" level=error msg="Error opening memory series storage: found existing files in storage path that do not look like storage files compatible with this version of Prometheus; please delete the files in the storage path or choose a different storage path" source="main.go:182"
  • TiDB ansible 部署历史版本
    • Prometheus 1.6
    • Prometheus 1.8
      • 1.8 与 2.0 数据不兼容
    • Prometheus 2.0 配置文件与 1.8 版本部分不兼容
      • 新增 Prometheus tsdb-admin-apis 功能,该功能在 devops 平台中有较好的扩展性
      • 告警配置文件 alert.rule 格式该为 yml

监控数据异常

有一套数据量比较大的 TiDB 集群,大概 80 * TiKV、10 * TiDB、3 * PD 部署在 60 台物理机上,某天巡检发现监控数据出现了些问题;不定期出现几分钟的无数据状态。查看日志发现下面日志信息:

1
2
3
4
5
6
7
8
time="2017-10-24T10:08:30+08:00" level=warning msg="Storage has entered rushed mode." chunksToPersist=107071 maxChunksToPersist=524288 maxMemoryChunks=10485
76 memoryChunks=1139421 source="storage.go:1660" urgencyScore=0.8663654327392578

time="2017-10-24T10:05:39+08:00" level=info msg="Storage has left rushed mode." chunksToPersist=108398 maxChunksToPersist=524288 maxMemoryChunks=1048576 mem
oryChunks=1121866 source="storage.go:1647" urgencyScore=0.6989479064941406

time="2017-10-24T10:05:45+08:00" level=warning msg="Storage has entered rushed mode." chunksToPersist=112409 maxChunksToPersist=524288 maxMemoryChunks=10485
76 memoryChunks=1268143 source="storage.go:1660" urgencyScore=1

界面展示为数据短暂断崖式下降,日志中打印 Storage has entered rushed mode. 信息;通过这些信息在网上冲浪,发现 GitHub Prometheus 有一些类似的问题

根据一顿胡聊聊理解,大致说从各节点上获取到的数据无法在短时间内刷写到磁盘上,然后导致临时存放在内存中的数据超时丢弃了。辣么还要研究下怎么这么个现象……

继续探索 Prometheus 的 storage 相关的参数,看有什么方案

未完待续

启动速度慢

  • Prometheus 启动后,发现网页无法打开,查看日志后,发现 Prometheus 启动后一直在 GC

    • Prometheus 2.0 与 1.0.8 底层存储格式不一致,这个在 2.0 后续版本上有一些优化,但数据量超过 500G 启动速度还是直线下降
    • 一般是修改参数后重启进程,官方文档提示可以使用 kill -SIGHUP PID 用来重新加载配置文件、或者使用 2.1 版本上的 admin api 功能
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    
    [tidb@Jeff scripts]$ ./run_prometheus.sh
    level=info ts=2018-04-17T03:04:31.495865947Z caller=main.go:220 msg="Starting Prometheus" version="(version=2.2.0, branch=HEAD, revision=f63e7db4cbdb616337ca877b306b9b96f7f4e381)"
    level=info ts=2018-04-17T03:04:31.495932795Z caller=main.go:221 build_context="(go=go1.10, user=root@52af9f66ce71, date=20180308-16:40:42)"
    level=info ts=2018-04-17T03:04:31.495952002Z caller=main.go:222 host_details="(Linux 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 Jeff (none))"
    level=info ts=2018-04-17T03:04:31.495966987Z caller=main.go:223 fd_limits="(soft=1000000, hard=1000000)"
    level=info ts=2018-04-17T03:04:31.498497082Z caller=main.go:504 msg="Starting TSDB ..."
    level=info ts=2018-04-17T03:04:31.498536225Z caller=web.go:382 component=web msg="Start listening for connections" address=:9090
    level=info ts=2018-04-17T03:05:52.153499505Z caller=main.go:514 msg="TSDB started"
    level=info ts=2018-04-17T03:05:52.153580197Z caller=main.go:588 msg="Loading configuration file" filename=/data1/deploy/conf/prometheus.yml
    level=info ts=2018-04-17T03:05:52.177873304Z caller=main.go:491 msg="Server is ready to receive web requests."
    level=info ts=2018-04-17T03:05:57.320867461Z caller=compact.go:394 component=tsdb msg="compact blocks" count=1 mint=1523923200000 maxt=1523930400000
    level=info ts=2018-04-17T03:06:03.658563096Z caller=head.go:348 component=tsdb msg="head GC completed" duration=227.952838ms
    level=info ts=2018-04-17T03:06:06.403176186Z caller=head.go:357 component=tsdb msg="WAL truncation completed" duration=2.74453888s
    level=info ts=2018-04-17T03:06:06.666573558Z caller=compact.go:394 component=tsdb msg="compact blocks" count=3 mint=1523901600000 maxt=1523923200000
    
  • 查看 metrics 数据目录大小

    1
    2
    3
    
    du -sh *
    
    89G prometheus2.0.0.data.metrics
    
  • 查看 Prometheus 具体版本信息

    • 查看官方 changelog 信息,在 Prometheus 2.0.2 对启动速度有优化
    1
    2
    3
    4
    5
    
    [tidb@Jeff deploy]$ ./prometheus --version
    prometheus, version 2.2.0 (branch: HEAD, revision: f63e7db4cbdb616337ca877b306b9b96f7f4e381)
      build user:       root@52af9f66ce71
      build date:       20180308-16:40:42
      go version:       go1.10
    

监控数据清理

  • 节点下线后,metric 由残留数据
    • 第一种方案:
      • 停止 Prometheus 与 Push Gateway 服务,然后删除 Prometheus 的所有监控数据,然后启动两个组件。
    • 第二种方案:
      • 人工修改 metric ,按个过滤掉所有已经被下线的节点信息
      • histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket{instance!="6a5114505e5f_4000”}[1m])) by (le, instance))
    • 第三种方案:
      • Prometheus > 2.1 版本以上,使用 Prometheus admin-api 功能,删除指定 instance 或指定 series 信息
      • 此处 instance 等于一个 TiDB-server 进程,series 等于 TiDB-server 某一个监控项
        • 删除指定 series & instance & job 信息,如不指定 instance & job ,会删除所有 instance 的 tidb_server_handle_query_duration_seconds_bucket series。
          • curl -XPOST -g 'http://172.16.10.65:9090/api/v1/admin/tsdb/delete_series?match[]=tidb_server_handle_query_duration_seconds_bucket{instance="10.0.1.4:20181",job="tikv"}'
        • 删除指定 instance 下所有的 series 信息
          • curl -X POST -g 'http://172.16.10.65:9090/api/v1/admin/tsdb/delete_series?match[]={instance="10.0.1.4:20184",job="tikv"}'
        • 按照官方手册,删除 series 可选手动清理存储空间
          • curl -XPOST -g 'http://172.16.10.65:9090/api/v1/admin/tsdb/clean_tombstones'

0x02 Grafana 问题

Grafana 忘记密码

重新部署

一般情况 Grafana 公司不会重度使用监控自带的鉴权系统,所以仅做监控展示的 Grafana 的 sqllite 里并木有神马数据。重新部署一套监控然后添加 Prometheus 数据源是最简单的方式
比较烦人的是那些 dashboard 需要重新导入,而 tidb-ansible 会自动化导入那些默认的 dashboard、那些后期修改的就没办法了
适合执行力度快的同学

  • 删除 Grafana 目录下数据,dashboard 二次自定义将会丢失
  • 执行 ansible-playbook deploy.yml --tags=grafana 部署
  • 执行 ansible-playbook start.yml --tags=grafana 启动

暴力重置 Grafana db

该方式与上述方案结果相同,会丢失 dashboard 信息

  1. 停止 Grafana
  2. 找到 grafana.ini 文件,并将 grafana.ini 文件中 admin_password 修改为 admin
  3. 删除掉 grafana.db 文件;文件默认在 {{deploy_dir}}/data.grafana/grafana.db
  4. 重启 Grafana 服务
  5. 可选步骤 // 通过 tidb-ansible 脚本导入 dashboard
    • 只有当前 Grafana 是通过 tidb-ansible 部署时才可使用
    • 执行 ansible-playbook start.yml --tags=grafana 导入
  6. 可选步骤 // 手动导入 dashboard
    • 登陆 grafana ui ,添加监控数据源,如 Prometheus
    • 登陆 grafana ui ,选择 import dashboard

Grafana ctl 工具

  • 官方文档 链接,此方法仅适用于 4.1 以上版本
  • 首先找到 grafana db 文件
  • 直接修改 grafana db
    • grafana-cli admin reset-admin-password …
    • grafana-cli admin reset-admin-password –homepath “/usr/share/grafana” newpass

sqllite 修改数据库

使用 sql lite 工具修改 Grafana.db ; 执行以下步骤会强制将 Grafana 管理员密码重置为 admin

  1. 停止 Grafana 服务

  2. 通过 grafana.ini 配置文件找到 grafana.db 实际目录

    • 通过 find / -name "grafana.db" 查找,需要确保是 grafana.ini 文件中引用的
    • ini 文件默认在 {{deploy_dir}}/opt/grafana/conf/grafana.ini
    • db 文件默认在 {{deploy_dir}}/data.grafana/grafana.db
  3. 通过 sqllite cliet 链接数据库修改密码

    1
    2
    3
    4
    5
    6
    7
    8
    
    # sqlite3 {{deploy_dir}}/data.grafana/grafana.db
    
    sqlite> select salt, password from user;
    pyaUhfDzYg|54c7d1ce2eeaa6000bd84407d0f8ab4663dfa575e0a326bc70dc5cab4b864f6677b21879dbf5e33427c88f9160f744b625bf
    
    sqlite> update user set password = '59acf18b94d7eb0694c61e60ce44c110c7a683ac6a8f09580d626f90f4a242000746579358d77dd9e570e83fa24faa88a8a6', salt = 'F3FAxVm33R' where login = 'admin';
    
    sqlite> .exit