OCP的常见问题
页面卡顿：
遇到页面卡顿的问题时，首先需要区分是全局性的卡顿，即所有页面都出现延迟或响应缓慢，还是仅限于特定的监控页面。
监控数据看不到:
需要明确是全部数据都无法查看，还是仅限于特定集群的数据，亦或是仅仅一两个特定的监控数据项无法被访问到。
问题排查
因为 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信息。
常用处理方式
- 页面请求 download 和 queue 时间长，可以看客户主机和 ocp 的网络情况，是否打开了实时页面，可以考虑先关闭实时请求页面，并且平时使用的时候注意实时页面开了之后记得关闭。或者优化网络情况。
- 有 fullgc，看下资源使用情况，首先避免资源不够，包括docker的和元数据库两个租户的资源，3.3.0 可以考虑关闭掉不必要的后台任务。
- 采集失败，需要根据具体的日志来分析。
- 如果客户自己处理不了，尽量收集更多的信息，需要把 ocp 的日志，agent 的日志，gc 状态这些信息都搜集下来。
