故障排除

使用Xray sh脚本检查微服务的状态，并确认所有的微服务都已完全启动，例如:

./xray.sh所有状态

或者Docker:

/ xray.sh ps。

一个正常工作的Xray系统的RabbitMQ队列的计数应该是相对水平的(接近0)，这将表示并提供最好的性能和最快的结果。

大量的消息云可能发生是由于:

1.一个x射线服务/组件的工作速度不够快，无法处理它的队列

2.在某个组件上发生了一些错误/意外行为，根据相应的RabbitMQ队列搜索日志将提供深入了解

1.临时增加负责适当队列(例如分析)的工作人员的数量，或为机器分配更多的资源;2022世界杯阿根廷预选赛赛程RAM和cpu用于更快的处理，SSD用于更快的磁盘I/O。

2.搜索适当的日志文件(例如x射线-analysis.log)，寻找任何[error]或“Caused by”消息作为原因。

这可能是由于其中之一(或两者的结合):

1.$XRAY_DATA位置没有正确配置-因此阻止x射线磁盘采样器检查磁盘空间可用性的正确路径

2.允许的磁盘利用率设置过高

3.应该删除的临时文件(在$XRAY_HOME/data/data/下)正在消耗大量的空间

4.＊主要是适用于大规模场景:其他数据库(RabbitMQ/PostgreSQL/MongoDB)占用空间较大

1.在事件组件上启用调试日志记录，以查看检查的路径，期望看到一个日志条目说明:"数据文件夹<位置>，已使用:<%>，已配置阈值<%>。通过改变xrayDataFolder根据xray_config.yaml文件到正确的位置。

2.在xray_config.yaml的maxDiskDataUsage标志到一个较低的值。在大规模环境中，特别是在处理大型文件时，将消耗更多的空间(临时)以允许递归索引过程完成。

3.Xray版本1.9在处理由于意外错误(例如与文件损坏有关的错误)导致索引失败的情况方面有了显著改进，并将自动删除这些错误。

也可以检查RabbitMQ的重试队列内容(获取消息)来检查消息并将它们的位置关联到xray_indexer.log*文件下。这将为重试操作提供洞察。

4.配置RabbitMQ数据库(mnesia)和$XRAY_HOME (两者应位于同一坐垫下)到一个大的挂载(通常是1-2TB)

/etc/rabbitmq/rabbitmq-env.conf(默认没有创建):

rabbitmq RABBITMQ_MNESIA_BASE = / home / / mnesia

从RabbitMQ & $XRAY_HOME中分离Mongo和PostgreSQL(可以和/或应该在同一个挂载下配对，但要分开):

Postgres:

• 检查:Postgresql主数据文件夹的位置可以使用安装程序进行配置

如果要在安装完成后进行移动，是可以跟随的本指南-确保PostgreSQL已停止

蒙戈:

• 停止Mongo(最好使用Xray .sh stop all命令停止所有x射线服务)
• 编辑/etc/mongodb.conf,改变：

  dbpath = / var / lib / mongo

  走你自己选择的路。
  
  
• 复制你的mongo数据文件夹到一个新位置-确保权限设置为mongod用户(cp命令的-a标志应该负责保留权限)
  

  Cp -ra /var/lib/mongo /home/myuser/data/mongo

如果RabbitMQ没有成功启动(使用上面故障排除中的命令)，可能是这个原因在意外的系统状态发生后，RabbitMQ遇到数据损坏，导致其消息和/或队列存储丢失完整性。

对于要分析的每个日志文件，将日志级别设置为DEBUG。每个x射线服务的日志级别设置在下面的对应配置文件中/var/opt/jfrog/xray/data/config(用于Linux安装)。例如，在分析器服务调试级别中设置analysis_log4go_config.xml，而索引器服务调试级别设置为indexer_log4go_config.xml．所有其他x射线服务也是如此。

升级完成后，Xray正在进行迁移。当迁移开始时，它会创建一个锁定机制，以便在执行迁移时阻止对数据库的外部操作。

如果迁移失败，锁将保留，锁定x射线，但可以重试，并在下次运行时成功。

快速总结一下我们将要采取的步骤:

1.检查迁移失败的原因和原因。这是可选的，尽管不是强制性的，但对未来的避税很有用。

2.删除锁，以便重新尝试迁移。

以下是需要采取的步骤:

1.停止所有x射线服务:

Non-Docker

$ ./xray.sh停止所有

码头工人:

$ ./xray.sh stop

2.仅启动MongoDB和PostgreSQL:

Non-Docker:

启动postgresql-9.5

$ service mongod start

码头工人:

$ docker start xray_mongodb_1

$ docker start xray_postgres_1

3.执行操作MongoDB的一面:

a.连接MongoDB:

Non-Docker:

$ mongo -u x射线-p password——authenticationDatabase x射线

码头工人:

$ docker exec -它xray_mongodb_1 bash

在Docker bash shell中连接到MongoDB:

$ mongo -u x射线-p password——authenticationDatabase x射线

b.切换到x射线DB:

$ use x射线

c找到当前DB迁移的状态，包括失败的迁移(对理解DB模式迁移版本很重要):

美元db.db_migrations_running.find ({}) .pretty ()

e.将输出复制到一边以供研究:

美元db.db_migrations.find ({}) .sort({“版本”:1}).limit (1)

输出的示例(对4这样做。分析步骤如下)：

{"_id": ObjectId("5a4bd9be95e701000100c37b")， "version": NumberLong(27)}

*上面的行将告诉我们正在运行的迁移的ID

f。使用以下命令移除所有迁移锁:

美元db.db_migrations_running.deleteMany ({})

在这一点上，你可以跳到步骤5。

4.用于分析和接触时JFrog支持时，需要收集以下信息:

数据库只有状态信息:

MongoDB。,复制两个命令的输出(在上面的步骤3中提供):

美元的。db.db_migrations_running.find ({}) .pretty ()

b。美元db.db_migrations.find ({}) .sort({“版本”:1}).limit (1)

b。PostgreSQL,收集以下信息PostgreSQL数据库:

连接到PostgreSQL数据库:

Non-Docker:

$ PSQL xraydb x射线

码头工人:

$ docker exec -it xray_postgres_1 /bin/bash

$ PSQL xraydb x射线

*如果/当提示输入密码时，输入x光

＊xraydb是数据库的名称，x光是用户名

1. 1. 运行以下查询(注意使用';'最后，如果没有它，它将无法执行):

$ SELECT * FROM schema_migrations;

*将输出复制到一边

b.输入:

美元\问

c.迁移时间段的Xray Services日志:

xray_server.log

xray_persist.log

xray_event.log

5.重新启动所有x射线服务。这将触发迁移重新运行。