💫《博主主页》：
🔎 IF Club社区主页__奈斯、
🔥《擅长领域》：擅长阿里云AnalyticDB for MySQL(分布式数据仓库)、Oracle、MySQL、Linux、prometheus监控；并对SQLserver、NoSQL(Redis)有了解
💖如果觉得文章对你有所帮助，欢迎点赞收藏加关注💖
这篇文章主要是整理一下博主在部署以及运维prometheus和Grafana时踩过的那些"坑"😅。从配置到启动，从监控到展示，每一个坑都是博主亲自踩过、实测解决的！
并且这篇"避坑指南"博主会一直更新下去，后续遇到新坑也会同步在这里。看在博主为爱发电🆓 疯狂"填坑"的份上，求个点赞❤️收藏⭐加关注✅方便各位大佬回头抄作业！
prometheus+Grafana全系列文章（实时更新🔥）：
点赞、收藏、加关注，填坑路上不迷路！
目录
一、Prometheus常见问题与解决办法总结：
问题一：
- 描述： 如果安装的Prometheus监控服务器上的时间，和在打开Prometheus的PC电脑上的时间不一致，会在打开Prometheus的时候提示时间误差的信息，但并影响Prometheus采集监控数据。
- 解决办法： Prometheus监控服务器的时间需要为北京时间，同样的访问Prometheus的PC电脑也需要为北京时间。
问题二：
- 描述： Prometheus大面积获取监控数据失败，查看/var/log/messages系统日志记录，有大量的too many open files报错
- 解决办法： 从systemd v230 开始，PAM 和 1imits.conf 对服务进程不再生效，systemd 服务的资源限制优先由systemd 配置控制，而不是limits.conf。这也就导致了在 /etc/security/limits.conf 文件中配置的参数不会对通过 systemctl 启动的服务进程生效，因此 limits.conf 文件中配置的参数只会对通过登录shell启动的用户进程有效(如 SSH 登录后运行命令)和直接在命令行中启动的服务有效(启动命令直接在命令行中执行的，不是通过systemctl服服务启动的)。对于systemd管理的服务(systemctl status service服务）其资源限制由 systemd 自身配置决定，完全忽略 /etc/security/limits.conf 文件中的配置，需要在配置启动参数文件时加上对limited的限制。必须要加上对"打开文件数"的limited限制，不然在Prometheus监控的机器多了的时候会在/var/log/messages系统日志记录大量的too many open files报错。
问题二的复现：通过systemd启动的Prometheus进程，没有应用limits.conf文件配置的案例
1）Prometheus大面积获取监控数据失败，查看/var/log/messages系统日志记录，有大量的too many open files报错
sql[root@app-prod-prometheus ~]# tail -200f /var/log/messages
2）查看Prometheus相关进程打开的所有文件总数：
sql[root@app-prod-prometheus ~]#ps -ef | grep prometheus [root@app-prod-prometheus ~]#lsof -p 4816 | wc -l ###统计这个进程打开的文件总数（包括网络连接、管道、共享库等）。可以看到Prometheus相关进程总共打开了七千+个文件（包括网络连接、管道、共享库等）
3）在limits.conf文件中配置了影响所有用户的软限制和硬限制，但因从systemd v230 开始，PAM 和 1imits.conf 对服务进程不再生效
sql[root@app-prod-prometheus ~]# more /etc/security/limits.conf ### "*"表示影响所有用户的软限制和硬限制
4）在配置启动参数文件时加上对"打开文件数"的limited限制
sql# Sets open_files_limit LimitNOFILE = 65536 ### 每个进程可打开的最大文件数(关键参数，避免"Too many open files"错误) LimitNPROC = 65536 ### 每个用户可创建的最大进程数(影响可启动的并行进程数量)
5）然后通过cat /proc/服务进程PID/limits，查看限制有没有生效，默认Max open files值为4096
sql[root@app-prod-prometheus ~]# cat /proc/4816/limits
二、Grafana常见问题与解决办法总结：
问题一：
- 描述： 如果安装Grafana服务器上的时间，和在打开Grafana的电脑上的时间不一致，那么在仪表盘查看图形化数据时，会出现部分图形化数据显示
No data，直接导致看不到监控数据。- 解决办法： Grafana服务器的时间需要为北京时间，同样的访问Grafana的PC电脑也需要为北京时间。
问题二：
- 描述： Grafana的监控仪表盘和Prometheus的版本是存在兼容性的，如果Prometheus或者Grafana的版本太高或太低会导致监控仪表盘可能获取不到数据。
- 解决办法： 还没有在官网上找到关于Prometheus与Grafana兼容性的对应文档，只能在工作中遇到了再进行总结。目前已知的兼容性问题如下：
- Oracle的监控仪表盘因为Prometheus的版本太高导致仪表盘获取不到数据，
表空间和总览部分显示No data，Grafana的版本为10.4.5，然后将Prometheus从2.47版本替换成2.45版本就没有问题了，原因是因为高版本Prometheus的监控指标项的获取格式变了，从而导致低版本的Grafana抓取Prometheus数据时不兼容。
目前博主踩过的坑有这些，后续也会继续更新到这篇文章上面，希望这篇《踩坑实录》能帮大家少走弯路，看在博主熬夜掉发、为爱发电的份上，记得三连～ 你们的支持，就是我继续"填坑"的动力！❤️