背景

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

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

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

Read the rest of this entry

背景

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

排查

初步怀疑是新节点问题,在系统日志/var/log/messagedmesg中都未发现相关错误信息,在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)

Read the rest of this entry

,

背景

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

排查

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

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

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

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

Read the rest of this entry

背景

某项目应用需迁移到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文件也是一样的错误,而且有类似配置的应用也都是正常的,这个猜测被否定。

Read the rest of this entry

背景

某项目需要升级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后,注册中心恢复正常,因此可以肯定是健康检查的问题。但是在后台没有任何错误,甚至将日志级别调整到最低也未发现错误信息,这个给排查带来很大的困难。

Read the rest of this entry

,

背景

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

<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

Read the rest of this entry

背景

某项目在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)

Read the rest of this entry

,

背景

某项目接口采用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会报错。

Read the rest of this entry

背景

某项目有两个外网的站点a.site1.comb.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进行路由达到访问不同站点的目的。

Read the rest of this entry

背景

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

正常时间:

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

Read the rest of this entry