我们使用nexus搭建了docker镜像，随着推送的镜像数量越来越多，导致nexus服务器的磁盘空间不够用了。于是，我们急需先手动删除一些过期的镜像，可发现磁盘空间并没有释放。那么，如何才能彻底释放掉呢？使用nexus实现的npm私库和maven私库，想要清理掉无用的包，从而释放磁盘空间，同样的操作，就不一一重复。

健康检测接口返回OUT_OF_SERVICE从日志启动看，没有任何报错信息；而且jvm进程也启动成功。关键的一点信息是，服务的swagger地址访问也正常。但是，consul上的服务状态就是不健康。当然，重启大法不好使。

本文通过线上实际发生的一个生产事故，梳理了我们的解决思路，对于高频慢接口的访问，最后只能通过kong的熔断来解决。事实证明，重启银弹和扩容银弹并不适用此，对于fullgc等jvm内存问题可能适用。这个生产事故，也给我们一个提醒，需要及时排查慢接口和数据库的慢查询，它们就像是航船的漏洞一样，小洞如果不及时堵上，等变大了，想堵就来不及了。

这里以两个节点的启动为例。下面看到的日志所在节点是192.168.8.28，另外一个节点是192.168.8.18。除了主动注册外，随着服务节点的下线，zk会自动删除节点。这里重点看ZkListener的增与删的方法。

jvm程序的内存和gc没有变化，在接口访问量陡增的情况下，我们根据目前得到的信息，决定修改程序代码redission的配置。也就是说，减少程序对redis服务器的并发请求，至少不会让redis服务器的压力陡增。一味地增加redis配置当然不可取，因为我们的redis配置已经是很高了。另外，我很怀疑阿里云在今天的表现，说实话，业务在没有变化非常大的情况下，不应该使得redis一下子就卡机了。服务只是

Dockerfile建议优化一把，下一篇我们将整理在jenkins ci过程，如何构建并推送镜像。

镜像redis下载超时镜像pinpoint-batch下载超时容器pinpoint-mysql启动失败修改完docker-compose.yml后再次执行 docker-compose up -d 启动所有的镜像。可以看到， 最新版本的pinpoint比之前的组件变多了。访问pinpoint-web(8080端口),http://localhost:8080/这是因为在docker-compose

可以看到，本机有许多IP地址，还未许多未截取。而实际的IP是192.168.8.28所以我们在读取本机IP的时候，需要去掉无效的IP。因为本机安装了docker导致生成了许多虚拟网段的IP。

本文欲梳理一次mongodb的生产事故，在不确定事故起因的情况下，我们从早上六七点，一直到中午才定位出问题。持续时间之长，不可谓不是一次惨痛的教训。首先，我们是第一时间收到了Mongodb数据库监控告警的信息，体现最明显的是cpu使用率达到了100%。（遗漏了其他信息，或者说不同于以往的指标，待下文细说）其次，客户端应用反馈说后端响应巨慢，无法访问。说明后端服务挂了，此时再使用应用重启这一大招也不

java程序打包后的jar如下图所示：可以看到META-INF目录下的三处均可以读取到程序的版本号：程序版本号字段 即 Implementation-Version2、build-info.properties这个是依赖maven插件 git-commit-id-plugin，具体在我之前的博文都有详细讲述。这里就不再赘述~路径是maven/{基本package名}/{服务名}，读取pom.xml