jvm监控的必要性
如果遇到jvm问题，我们一般考虑查看jstat，jconsole查看基本信息，例如jvm各个空间的使用比率，还要gc次数，gc时间等等。在排除错误的时候，我们也发现jstat开启的时候，一般会后面加个定时打印的时间，先观察一段时间。不同时间的数据需要做对比。不对比的话，根本不知道整个jvm运行的情况，例如gc次数是什么频率的增长，gc的时间是什么情况。所以我们需要一个方案把数据可视化。这样才能很好的分析问题。
常见方案
jconsole
如果特别短期的话，我们就使用jconsole。里面有一段时间的展示结果，但是数据不会保存很久。适合问题特别明显的时候。
apm
apm监控更为专业，不单单是jvm的，会有物理机的信息，调用栈，以及异常等等。相对数据很全面，商业的有oneapm，听云等等。开源的有pinpoint，skywalking等。由于是完整的一套监控方案，所以一般都比较重，依赖的存储往往是hbase,es等。其实主要是一个长期的分析。
prometheus
prometheus本身其实是监控存储的一套方案，大家可以把数据存储到prometheus，而且他无缝衔接k8s。由于他是时序数据库，所以存储的数据是有限的，只有metric的数据，并没有方法去存储堆栈等等。也因此，他的搭建其实最方便，一般用用存个几天的数据做做监控，他是特别快速的方案。
jmx exporter
现在已经有开源的方案采集jmx的指标到prometheus。
这个方案是一个javaagent的实现方案，采集jvm的jmx数据，他提供一个端口，prometheus可以抓取这个端口里的数据。
他需要配置一个数据转化的配置文件，主要是把jmx的数据按照一定的规则转化成你自己组织的数据形式。不过这个配置文件开源已经有很多组件的实现了，一般不需要自己写，除非有一些扩展，例如需要增加一些额外的信息，例如想区分两个集群的数据，我们就可以加label来区分。
启动的话在jvm进程加入如下参数
-javaagent:/jmx_prometheus_javaagent.jar=9100:jmx_exporter.yml
这里的9100就是开启的端口，prometheus就需要配置这个端口来抓取数据。在prometheus.yml中
scrape_configs:
- job_name: 'jvm'
static_configs:
- targets: ['ip:port']
查询注意事项
prometheus的查询比较方便,可以直接输入指标名。但是有些指标不可以直接查询。例如gccount,gctime。这两个指标其实是累加值，是一直增长的，单独看着这个指标其实是比较茫然的，因为在图像上就是一直上涨，人总不可能一直看斜率来看现在的情况，我推荐下面几种表达。
速率
prometheus有rate的函数，可以表达一种增长情况。
时间段差值
idelta函数是可以计算一段时间的第一个值和最后一个值的差值，这个也满足了我们平时排查问题的方式，例如2分钟内的gc次数，2分钟内的gctime。
grafana
查询展示的话，建议使用grafana，而不是prometheus的图形展示。grafana有权限控制以及漂亮的图形dashboard。一般建议作为首选。
