背景

某项目需要升级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

背景

某项目数据库磁盘告警,磁盘使用率接近100%

$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda1      ext4       99G   60G   35G  64% /
devtmpfs       devtmpfs   32G     0   32G   0% /dev
tmpfs          tmpfs      32G   69M   32G   1% /dev/shm
tmpfs          tmpfs      32G  7.8M   32G   1% /run
tmpfs          tmpfs      32G     0   32G   0% /sys/fs/cgroup
/dev/vdc1      ext4       99G   94G   52M 100% /u01/oracle
/dev/vdb4      ext3       99G   30G   64G  32% /soa
tmpfs          tmpfs     6.3G     0  6.3G   0% /run/user/1002
tmpfs          tmpfs     6.3G   52K  6.3G   1% /run/user/1003
tmpfs          tmpfs     6.3G     0  6.3G   0% /run/user/1005

可以看到/dev/vdc1使用率已经100%

Read the rest of this entry

背景

某项目Oracle 11g RAC其中一个节点vip服务offline,集群从双节点变为单节点

排查

  • crsctl命令查看集群状态

Read the rest of this entry

,

背景

某项目OIM修改密码异常的慢,修改一次密码需要耗费15分钟时间,该功能基本已不可用,通过curl工具调用OIM rest api进行修改密码也需要十几分钟的时间

curl -X PUT \
http://10.10.10.10:14000/iam/governance/selfservice/api/v1/users/61729/password \
-H 'accept-language: zh-CN,en-US;q=0.8,zh;q=0.7,zh-TW;q=0.5,zh-HK;q=0.3,en;q=0.2' \
-H 'authorization: Basic xxxxxxxxxxxxxxxxxxxxx' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-H 'postman-token: e86578e5-6c12-6bd0-3304-7588cae0f60a' \
-H 'x-requested-by: xx' \
-d '{
"oldPassword": "welcome@2020",
"newPassword": "welcome@2020238",
"confirmPassword": "welcome@2020238"
}'

排查

获取源码

后台并无报错,也没相关有价值的日志,因此考虑从源码入手,api源码位于oim这个应用中,你可以登录console查看ear包路径

Read the rest of this entry

背景

某项目服务器响应慢,cpu严重超负荷运行,并且有大量的netstat进程,如图:

进程由oracle用户启动,说明是通过oracle用户并非root用户启动。

排查

这种情况,第一直觉就是中毒了,大概率是挖矿程序,Linux中毒第一步就是排查是否有cron记录,大部分病毒都是通过cron进行自启动,cron还能保证进程关闭后能够再次启动,达到死而复生的目的。crontab -l命令显示果然有病毒的定时任务程序脚本

Read the rest of this entry