常见现象
页面很卡：
页面卡顿，需要分辨是所有页面都卡，还是特定的监控页面很卡
监控数据看不到:
需要分辨是否是所有数据看不到，特定集群的数据看不到，还是某一两个监控数据看不到
信息收集
因为 OCP 是一个 web 应用，一般的问题都是反应在页面上的，所以一般排查过程也是从页面上来入手的, 在浏览器中右键，点击inspect element, 打开调试窗口，然后点 Network, 可以看浏览器请求。
页面卡顿:
针对页面卡顿的现象，主要需要分析请求的时间，Queued 的时间表示请求的排队时间，waiting 的时间表示等待的时间，一般是后端的响应时间，download 表示数据下载的时间，OCP 后端的返回结果中也会有响应时间，duration字段表示响应时间。
最需要关心的是 OCP 的响应时间，如果 OCP 的响应时间不长的话，一般后端服务没问题，需要关注其他的方面
如果客户的主机和 OCP 之间的网络条件比较差，而页面请求的监控数据比较多的时候，Download时间会比较久，如果再打开了实时页面，很可能会因为浏览器并发请求的限制，造成请求的排队, 需要考虑解决网络的问题。
如果是 OCP 响应时间长，需要再做详细的分析，根据 OCP 响应结果中的 traceid, 去 OCP 的日志中搜索，可以找到这个请求完整的处理流程的日志, 可以看日志文件中的时间戳，如果两条日志之间的时间差比较大，应该就是耗时的操作。
当 OCP 所有页面都有卡顿的时候，一般要关注 OCP 的 GC 情况，可以通过以下命令来查看，主要关注 full gc 的次数和时间.
jstat -gcutil $pid 1000另外 OCP 的 gc 情况也会记录在 gc.log.0.current 中
数据缺失:
因为 OCP 的监控数据采集和持久化都是后台任务，通过traceid可能查询不到有用的信息，需要查询一些其他的信息，按照一些关键字来进行日志搜索。
- 查找 ocp 的日志
ocp 如果有多个节点，尽量都搜一下。
采集失败，ocp 日志中会有 'collect failed' 的日志，可以作为关键字进行搜索，查找监控线程相关的日志，pool-metric 作为关键字，另外 ERROR 日志也需要关注，特别是写 db 是否有失败的日志。
- 查找 agent 日志
首先找到失败的exporter， ocp 会在metadb表中记录所有的exporter， 如果采集失败多次，status 会变成 inactive，可以首先看哪些是inactive状态的，去对应主机上找日志。
ocp-agent 监控进程的日志在 /home/admin/ocp_agent/log/monagent.log, 可以搜索ERROR信息。
