郑剑峰的个人博客

背景

某客户实施DAP，在上线前需要对DAP进行压力测试，有专门的压力测试环境，并且要求并发能够达到1000，团队使用jmeter作为压测工具，整个系统架构很简单浏览器->Nginx->Tomcat，在压测的时候碰到以下问题

• 对DAP流程提交接口进行压测，压测不通过
• 部署一个仅仅返回请求参数，没有任何业务逻辑，压测不通过
• 绕过Nginx，直接对Tomcat进行压测，压测通过
• 直接对Nginx进行压测，压测Nginx welcome页面，压测不通过

并且对Nginx进行了大量的调优，能调的参数基本都试过，压测不通过，总结下来就是，只要经过Nginx，压测就不通过，看来问题出现在Nginx上

背景

某客户kubernetes集群新加了一个节点，新节点部署应用后，应用会间歇性unavaliable，用户访问报503，没有事件消息，主机状态也正常。

排查

初步怀疑是新节点问题，在系统日志/var/log/message和dmesg中都未发现相关错误信息，在kubelet中发现以下日志

kubernetes集群时通过rke进行安装，可以在节点上直接执行命令docker logs -f --tail=30 kubelet查看kubelet日志

E0602 03:18:27.766726    1301 controller.go:136] failed to ensure node lease exists, will retry in 7s, error: an error on the server ("") has prevented the request from succeeding (get leases.coordination.k8s.io k8s-node-dev-6)
E0602 03:18:34.847254    1301 reflector.go:178] k8s.io/client-go/informers/factory.go:135: Failed to list *v1.CSIDriver: an error on the server ("") has prevented the request from succeeding (get csidrivers.storage.k8s.io)
I0602 03:18:39.176996    1301 streamwatcher.go:114] Unexpected EOF during watch stream event decoding: unexpected EOF
E0602 03:18:43.771023    1301 controller.go:136] failed to ensure node lease exists, will retry in 7s, error: an error on the server ("") has prevented the request from succeeding (get leases.coordination.k8s.io k8s-node-dev-6)

背景

某项目kubernetes环境某个应用每隔20分钟左右就会重启一次，时间不固定，但在容器事件里面没有任何记录。

排查

首先怀疑是健康检查没过导致容器自动重启，以下是健康检查的配置

按照该配置，检查间隔30s，不健康阈值60，也就是1800s=30分钟后会标记为不健康，但很快就排除该猜测，理由是

• 手动调用健康检查是ok的
• 后台有健康检查的记录，记录显示也都是通过的
• 如果是健康检查不过的话，事件里面会有记录，这里找不到记录

正常情况下如果kubernetes重启pod那会在事件里记录重启的原因，但事件里面没有任何记录，所以可能不是kubernetes重启的，那么很容易想到一个可能性就是OOM，也就是进程因为内存使用超过限制触发OOM操作系统将其kill掉，查看操作系统日志/var/log/messages发现以下日志

背景

某项目应用需迁移到k8s环境，其中有个应用配置了Ingress，但通过域名访问，始终返回503服务不可用，应用服务都是正常的

➜ curl -v http://mdm-sts-test.xxx.com
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.19.2</center>

从错误日志可以看出503是nginx返回的，并不是后端服务返回（后端tomcat），也就是说请求可能根本没有到达后端服务

排查

将Ingress连接到其他应用的service，还是继续报错，将Ingress的域名换成其他域名，结果正常，所以从测试结果上看应该是域名出问题。因为该域名已经在dns中配置，所以怀疑是不是又解析回到dns造成死循环（虽然k8s不会犯这么低级的错误），把域名配置到了hosts文件也是一样的错误，而且有类似配置的应用也都是正常的，这个猜测被否定。

背景

某项目需要升级kubernetes集群，考虑到原k8s版本较低，并且在部署结构上不是很合理，因此决定重新搭建一套新的k8s集群，做应用迁移。迁移过程也是非常曲折，这个后面会专门写一篇文章记录，应用迁移后有部分应用在注册中心状态为DOWN

如果服务状态为DOWN调用该服务就报404错误，因为应用配置了健康检查，怀疑是健康检查没有通过，进入后台调用接口查看检查结果

$ curl http://localhost:8080/management/health
{"description":"Remote status from Eureka server","status":"DOWN"}

服务使用jhipster框架生成，在配置文件里面有以下配置

eureka:
    client:
        enabled: true
        healthcheck:
            enabled: true
        fetch-registry: true
        register-with-eureka: true
        instance-info-replication-interval-seconds: 10
        registry-fetch-interval-seconds: 10

将eureka.client.healthcheck.enabled设置为false后，注册中心恢复正常，因此可以肯定是健康检查的问题。但是在后台没有任何错误，甚至将日志级别调整到最低也未发现错误信息，这个给排查带来很大的困难。

背景

某项目中间件环境部署应用时出现错误，错误日志如下：

<2020-12-7 下午04时04分48秒 CST> <Error> <Management> <BEA-141244> <Schema validation errors while parsing config/config.xml - Expected elements 'staging-mode@http://xmlns.oracle.com/weblogic/domain alt-descriptor-path@http://xmlns.oracle.com/weblogic/domain alt-wls-descriptor-path@http://xmlns.oracle.com/weblogic/domain application-identifier@http://xmlns.oracle.com/weblogic/domain application-name@http://xmlns.oracle.com/weblogic/domain' instead of 'cache-in-app-directory@http://xmlns.oracle.com/weblogic/domain' here in element app-deployment@http://xmlns.oracle.com/weblogic/domain> 
Caused By: java.io.IOException: [Management:141245]Schema Validation Error in config/config.xml see log for details. Schema validation can be disabled by starting the server with the command line option: -Dweblogic.configuration.schemaValidationEnabled=false
	at weblogic.management.provider.internal.EditAccessImpl.checkErrors(EditAccessImpl.java:2340)
	at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleConfigTreeLoad(RuntimeAccessDeploymentReceiverService.java:968)
	at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateDeploymentContext(RuntimeAccessDeploymentReceiverService.java:599)
	at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doUpdateDeploymentContextCallback(DeploymentReceiverCallbackDeliverer.java:147)
	at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.updateDeploymentContext(DeploymentReceiverCallbackDeliverer.java:28)
	Truncated. see log file for complete stacktrace

背景

某项目在weblogic升级失败后进行回滚，回滚后环境接口无法访问，报500异常，接口为BPM Service客户端程序，错误如下：

SEVERE: <.> getTokenType: invalid token: e0FFU31EbGdrK0IxSlV1WkFMM0doc2dlMUJxdWpjQmEza0tzZGNncnlOSUlLdnFaT0QrY1pyanBBa0d0MTdURHhqbmx4SWJ1d3hvMGsxNmZyaUJFcDIvbGd3MkFWUjRCUXVZdFhvemcxZmprQm83akFoS3pMSWVxeG1DT213VkJpUW5rUWhzQ3lVSmRUT204dXdUUmI2bnlsdEg4bTducTFBWVd0eDVKWjdVSHRiRndsRkRxcjQrZnBVKzBoV0lkc1lRZXQ2VlZkSDRtNUp0V05LYW1SdGNMNWZOUE0rVTVtaEhYYWU5czg4c1VLNHIvenFDN05GTXFieGl6YXJubkd6ZHhTSEZRcUxiRTlmK3ZaNzlLMVlCNExmbkJhL0pSY2hvanlHZ0ZyQWJLdVhJbz0=
SEVERE: <.> Invalid Token Error in Verification Service.
Invalid Token Error in Verification Service. Received invalid token in getTokenType.
Verify that correct token is passed.
ORABPEL-30503
Invalid Token Error in Verification Service.
Invalid Token Error in Verification Service. Received invalid token in getTokenType.
Verify that correct token is passed.
	at oracle.bpel.services.workflow.verification.impl.Token.getTokenType(Token.java:545)
	at oracle.bpel.services.workflow.verification.impl.Token.isSameValue(Token.java:314)
	at oracle.bpel.services.workflow.verification.impl.VerificationService.isInternalWorkflowContext(VerificationService.java:689)

背景

某项目接口采用jersey开发，部署在weblogic上，升级JDK至jdk1.7.0_191后所有接口无法访问，返回404 Not Found。

测试

首先怀疑是JDK升级后部分java类初始化失败导致404，但重启服务器，重启应用，重新部署应用都未报错，说明应用启动是成功的，一开始也没怀疑到jersey框架上，因此走了很多弯路，这里就不赘述。到后面所有的猜测都验证后，还是没有解决，于是决定本地用jersey写一个最简单的接口部署上去看下结果。

• 接口部署到线上weblogic访问404
• 接口部署到本地tomcat，访问正常
• 接口部署到其他weblogic环境，访问正常，jdk版本为jdk1.7.0_80
• 正常的环境将jdk切换至jdk1.8.0_171，访问404

基于以上实验可以看出，**jersey在weblogic环境下，高版本的jdk会报404，tomcat没有这问题**，确定了问题后排查方向就比较清楚，就是搞清楚为什么高版本的jdk会报错。

背景

某项目有两个外网的站点a.site1.com，b.site2.com需要通过definesys.com进行代理，代理后的地址

• a.definesys.com => a.site1.com
• b.definesys.com => b.site2.com

a和b都是托管在vps站点上。

CNAME

接到这个任务时，以为很简单，到definesys.com域名后台增加两个域名，并且将CNAME指向代理的站点即可，但还是想简单了，这里简单介绍下vps托管站点的原理，vps就是大家所说的虚拟主机，相比云服务器，vps具有价格低，部署简单，监控方便等特点，所以很多站点都会托管到vps上，但我们都知道vps供应商不可能一台服务器只部署一个站点，肯定想法设法压榨服务器资源，一台服务器可能部署了上千个站点，那么是如何实现几千个站点都可以通过80端口进行访问，我在之前的这篇文章中有介绍过方法，就是根据访问的host进行路由达到访问不同站点的目的。

背景

某项目OIM资源历史记录时间显示时区不对，比北京时间少了8个小时

正常时间：

导致了跨时区用户无法登录，账户被锁，在修改了所有跟时区有关的环境信息后（包括操作系统时区，数据库时区，jvm时区，oim时区）依然无法解决。