故障诊断
以下是一些故障诊断方案。
一般问题
"unrhel" 的早期用户
当使用 unrhel@v5.1.1 或更低版本从 RHEL 迁移环境时，将返回以下消息。
FAILED => 缺少 sudo 密码
要解决此问题，请在执行升级之前执行以下命令。
$ ssh sevone@<'agent' IP address>
$ sudo -i
$ echo "sevone ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers未找到连接插件 "local
这是由于在运行过程中触发了ansible升级。
如果出现这种情况，请确保安装了最新版本的 sevone-cli。
$ sudo rpm -Uvh /opt/SevOne/upgrade/utilities/sevone-cli*$(rpm --eval '%{dist}')*.rpm
只需重试升级即可。 或者，您可以先运行安装程序，然后再运行运行程序。
$ sevone-cli playbook install
$ sevone-cli playbook up
未找到连接插件 "ssh
这与未找到连接插件 "local "的问题相同。
找不到独立于平台的库
如果sevone-cli运行失败并伴有以下错误，则问题与未找到连接插件 "local "类似。
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = '/usr/bin/python3.12'
isolated = 0
environment = 1
user site = 1
safe_path = 0
import site = 1
is in build tree = 0
stdlib dir = '/root/.pyenv/versions/3.12.1/lib/python3.12' sys._base_executable = '/usr/bin/python3.12'
sys.base_prefix = '/root/.pyenv/versions/3.12.1'
sys.base_exec_prefix = '/root/.pyenv/versions/3.12.1' sys.platlibdir = 'lib'
sys.executable = '/usr/bin/python3.12'
sys.prefix = '/root/.pyenv/versions/3.12.1'
sys.exec_prefix = '/root/.pyenv/versions/3.12.1'
sys.path = [
'/root/.pyenv/versions/3.12.1/lib/python312.zip',
'/root/.pyenv/versions/3.12.1/lib/python3.12',
'/root/.pyenv/versions/3.12.1/lib/python3.12/lib-dynload',
]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00007f7bdf71e740 (most recent call first):
<no Python frame>
>> [ERROR] An error occurred running the playbook /opt/SevOne/upgrade/ansible/playbooks/up.yaml. Please check the output above.
ModuleNotFoundError:没有名为 "编码 "的模块
如果sevone-cli运行失败并伴有以下错误，则问题与未找到连接插件 "local "类似。
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = '/usr/bin/python3.12'
isolated = 0
environment = 1
user site = 1
safe_path = 0
import site = 1
is in build tree = 0
stdlib dir = '/root/.pyenv/versions/3.12.1/lib/python3.12' sys._base_executable = '/usr/bin/python3.12'
sys.base_prefix = '/root/.pyenv/versions/3.12.1'
sys.base_exec_prefix = '/root/.pyenv/versions/3.12.1' sys.platlibdir = 'lib'
sys.executable = '/usr/bin/python3.12'
sys.prefix = '/root/.pyenv/versions/3.12.1'
sys.exec_prefix = '/root/.pyenv/versions/3.12.1'
sys.path = [
'/root/.pyenv/versions/3.12.1/lib/python312.zip',
'/root/.pyenv/versions/3.12.1/lib/python3.12',
'/root/.pyenv/versions/3.12.1/lib/python3.12/lib-dynload',
]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00007f7bdf71e740 (most recent call first):
<no Python fram>
>> [ERROR] An error occurred running the playbook /opt/SevOne/upgrade/ansible/playbooks/up.yaml. Please check the output above.
在 GraphQL 日志中拒绝访问
如果 SOA apikeys 已过时或已到期，那么您可能会收到此错误。 要解决此问题，请更新数据源密钥。
- 执行以下命令以确保 GraphQL pod 处于 Running 状态，而不是 Errored 或 CrashLookBackOff 状态。
示例
$ kubectl get pods | grep graphql di-graphql-7d88c8c7b5-fbwgc 1/1 Running 0 22h - 如果第三列显示 Errored 或 CrashLookBackOff ，请使用您选择的文本编辑器，根据 SevOne Data Insight 版本编辑配置文件，如查找配置文件一节中的表格所示，加入以下环境变量，然后保存。
示例：适用于 SDI6.8.x及以下版本、
graphql: env: SKIP_REPORT_MIGRATION_DRY_RUN: true示例：适用于 SDI7.0.x及以上版本、
graphql = { env = { "SKIP_REPORT_MIGRATION_DRY_RUN" = "true" } } - 应用对配置文件所做的更改。
$ sevone-cli playbook up --tags apps - 一旦 GraphQL pod 状态为正在运行/正常运行，就会为每个受影响的数据源生成新的 SOA API 密钥。 执行以下命令。
$ sevone-cli exec graphql -- npm run reconfig-datasource注: 系统将多次提示您。 当系统提示您 登录而不是提供 API 密钥时，请保留所有缺省值，但输入 y 除外。用户名必须是 admin
密码必须是数据源的图形用户界面管理员密码。
重要信息: 对每个数据源重复此步骤。示例
$ sevone-cli exec graphql -- npm run reconfig-datasource > insight-server@7.0.0 reconfig-datasource /insight-server > NODE_PATH=./dist/libs node dist/scripts/database-init/reconfigure-datasource.js Datasource config: Name: Data Insight API Address: https://staging.soa.sevone.doc API key: eyJ1dWlkIjoiYzMxNTQzZWUtMTgxZC00NWMyLTlkNjctNTUwZWRhODQ2MGFkIiwiYXBwbGljYXRpb24iOiJEYXRhIEluc2lnaHQgKGNrcmwxdmhqZzAwMDA1M3MwM3Z5bmRlZXMpIiwiZW50cm9weSI6IjZVaWxuQStzVDk2ZUFKeG92WW1Nak1odS9nZ29JSWhLNVBDZ05yZHBBT1lrSE11ZlM0eU9CbCs4YWxEUXd3a1MifQ== Dstype: METRICS/FLOW Datasource name [Data Insight API]: [1] METRICS/FLOW [2] splunk-datasource [3] elastic-datasource [0] Keep: METRICS/FLOW Datasource dstype [1, 2, 3, 0]: 0 Datasource address [https://staging.soa.sevone.doc]: Login instead of providing an API key? [y/n]: y Username: admin Password: ****** info: [Data Insight API@reconfigure-datasource] SOA request (SOA-1) post https://staging.soa.sevone.doc/api/v3/users/signin (node:347) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. (Use `node --trace-warnings ...` to show where the warning was created) info: [Data Insight API@reconfigure-datasource] SOA response (SOA-1) elapsed 1755ms. info: [Data Insight API@reconfigure-datasource] SOA request (SOA-2) post https://staging.soa.sevone.doc/api/v3/users/apikey info: [Data Insight API@reconfigure-datasource] SOA response (SOA-2) elapsed 277ms. New datasource config: Name: Data Insight API Address: https://staging.soa.sevone.doc API key: eyJ1dWlkIjoiMzgyMDdhMjItNzE2Mi00OWRlLTk5NTYtYmI3OTVkYjc5NzZkIiwiYXBwbGljYXRpb24iOiJEYXRhIEluc2lnaHQgKGNrczUyYnd0YzAwMDA5bnMxNnQ3aWcxYnQpIiwiZW50cm9weSI6IkNoYS9tbDFWbVVyYThQcHVsLzIzY05JZk94QXcxWFQrVnEyM0hPSzYzSTdPNGNMbkJTVjQyWUVRSW1FeGtDaEoifQ== Dstype: METRICS/FLOW Is this config correct? [y/n]: y info: [Data Insight API@create-datasource] SOA request (SOA-3) get https://staging.soa.sevone.doc/api/v3/users/self info: [Data Insight API@create-datasource] SOA response (SOA-3) elapsed 275ms. Datasource config updated! Datasource reconfiguration complete. - 更新所有数据源后，重新启动 GraphQL pod。
$ kubectl delete pods -l app.kubernetes.io/component=graphql
装入报告时访存窗口小部件出错
当 wdkserver 未向用户界面提供窗口小部件时，会发生此错误。 在大多数情况下，这是由于浏览器中设置的无效 cookie 值导致错误。 您可以根据浏览器的 Developer Tools 来检查网络活动，并查找对 /wdkserver的请求。 如果无法检查网络活动，请联系 IBM SevOne 支持人员。
如果您观察到从 /wdkserver 返回的以下错误消息，请除去有问题的 cookie 或禁用 wdkserver 中的严格头。 如果需要此方面的帮助，请联系 IBM SevOne 支持人员。
{"statusCode":400,"error":"Bad Request","message":"Invalid cookie value"}- 使用自己选择的文本编辑器，根据 SevOne Data Insight 版本编辑配置文件，如查找配置文件部分的表所示，加入以下环境变量，然后保存。
适用于 SDI6.8.x及以下版本、
wdkserver: env: DISABLE_STRICT_HEADER: true适用于 SDI7.0.x及以上版本、
wdkserver = { env = { "DISABLE_STRICT_HEADER": "true" } } - 应用对配置文件所做的更改。
$ sevone-cli playbook up --tags apps
无法连接到服务器: x509: 证书已到期
如果您看到错误消息 x509: 证书已到期，那么在运行 kubectl 命令时，您的证书已到期，需要手动轮换。 有关详细信息，请参阅 SevOne Data Insight 管理指南 > 章节 Rotate Kubernetes Certificates。
[WARN] 没有可用的升级
如果尝试重试失败的升级，或者如果升级 .tgz 文件放置在不正确的目录中，那么通常会发生 无升级可用 警告。
- 确保.tgz 文件位于 SevOne Data Insight 升级过程指南 > 确认 SevOne Data Insight 版本一节所述的正确目录中。
- 使用 ssh ，以 sevone 身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight 'control plane' node IP address or hostname> - 使用您选择的文本编辑器，将 /SevOne.info 中的 SevOne Data Insight 专业 / 辅修 版本还原为较早/较低的版本。
$ vi /SevOne.info示例# 1
当前的 SevOne Data Insight 版本是 7.0.0。 Data Insight SevOne 7.0.0 之前的版本是 SevOne Data Insight 6.8.0。 在这种情况下，如果要转至先前版本，那么必须更改主版本和次版本以转至先前版本/较低版本。
major = 7 # e.g.: if this is `7` then set it to `6` minor = 0 # e.g.: if this is `0` then set it to `8` patch = 0 build = <###> # e.g.: replace the build number with the one for the prior version i.e., 45之前的版本是，
major = 6 minor = 8 patch = 0 build = 45示例# 2
当前的 SevOne Data Insight 版本是 6.8.0。 Data Insight SevOne 6.8.0 之前的版本是 SevOne Data Insight 6.7.0。 在这种情况下，若要降级到旧版本，必须将次要版本号更改为较低版本号。major = 6 # e.g.: if this is `6` then leave it as-is minor = 8 # e.g.: if this is `8` then set it to `7` patch = 0 build = <###> # e.g.: replace the build number with the one for the prior version i.e., 160之前的版本是，major = 6 minor = 7 patch = 0 build = 160
域名解析 (DNS) 不工作
重要： 任何 SevOne Data Insight 部署都需要一个正常运行的 DNS 配置。
DNS 服务器必须能够在 控制平面 和 代理程序 节点上解析 SevOne Data Insight 的主机名，否则 SevOne Data Insight 将无法工作。 可通过通过 nmtui 添加 DNS 服务器或通过直接编辑 /etc/resolv.conf 文件来完成此操作，如以下步骤中所示。
在以下示例中，让我们使用以下 SevOne Data Insight IP 地址。
| 主机名 | IP 地址 | 角色 |
|---|---|---|
| sdi-node01 | 10.123.45.67 | 控制平面 |
| sdi-node02 | 10.123.45.68 | 客服 |
此外，在此示例中，将使用以下 DNS 配置并使用 DNS 搜索记录 sevone.com 和 nwk.sevone.com 。
| 名称服务器 | IP 地址 |
|---|---|
| 名称服务器 | 10.168.16.50 |
| 名称服务器 | 10.205.8.50 |
- 使用 ssh，从两个不同的终端窗口以 sevone 身份登录到指定的 SevOne Data Insight 控制平面 节点和 代理程序 节点。
通过 SSH 从终端窗口 1 进入 "控制平面 "节点
$ ssh sevone@10.123.45.67从终端窗口通过 SSH 连接到 "agent" 节点 2
$ ssh sevone@10.123.45.68 - 在此示例中，获取 控制平面 和 代理程序 节点的 /etc/resolv.conf 文件中的 DNS 条目列表。
从终端窗口 1
$ cat /etc/resolv.conf # Generated by NetworkManager search sevone.com nwk.sevone.com nameserver 10.168.16.50 nameserver 10.205.8.50从终端窗口 2
$ cat /etc/resolv.conf # Generated by NetworkManager search sevone.com nwk.sevone.com nameserver 10.168.16.50 nameserver 10.205.8.50 - 确保 DNS 服务器可以解析 控制平面 和 代理程序 节点上的 SevOne Data Insight 的主机名 /IP 地址以及 /etc/resolv.conf 文件中的 DNS 条目 (请参阅 search 行和 nameserver)。
从终端窗口 1 以下输出显示 DNS 服务器可以在 控制平面 和 代理程序 节点上解析主机名 /IP 地址。
检查 "nslookup" 是否解析 "控制平面" IP 地址
$ nslookup 10.123.45.67 67.45.123.10.in-addr.arpa name = sdi-node01.sevone.com.检查 "nslookup" 是否解析 "控制平面" 主机名
$ nslookup sdi-node01.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sdi-node01.sevone.com Address: 10.123.45.67检查 "nslookup" 是否解析 "agent" IP 地址
$ nslookup 10.123.45.68 68.45.123.10.in-addr.arpa name = sdi-node02.sevone.com.检查 "nslookup" 是否解析 "agent" 主机名
$ nslookup sdi-node02.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sdi-node02.sevone.com Address: 10.123.45.68/etc/resolve.conf 中搜索行中的 nslookup 名称 "sevone.com"
$ nslookup sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sevone.com Address: 23.185.0.4/etc/resolve.conf 中搜索行中的 nslookup 名称 "nwk.sevone.com"
$ nslookup nwk.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: nwk.sevone.com Address: 25.185.0.4/etc/resolve.conf 中的 nslookup 名称服务器 "10.168.16.50"
$ nslookup 10.168.16.50 50.16.168.10.in-addr.arpa name = infoblox.nwk.sevone.com./etc/resolve.conf 中的 nslookup 名称服务器 "10.205.8.50"
$ nslookup 10.205.8.50 50.8.205.10.in-addr.arpa name = infoblox.colo2.sevone.com.从终端窗口 2 以下输出显示 DNS 服务器可以在 控制平面 和 代理程序 节点上解析主机名 /IP 地址。
检查 "nslookup" 是否解析 "agent" IP 地址
$ nslookup 10.123.45.68 68.45.123.10.in-addr.arpa name = sdi-node02.sevone.com.检查 "nslookup" 是否解析 "agent" 主机名
$ nslookup sdi-node02.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sdi-node02.sevone.com Address: 10.123.45.68检查 "nslookup" 是否解析 "控制平面" IP 地址
$ nslookup 10.123.45.67 67.45.123.10.in-addr.arpa name = sdi-node01.sevone.com.检查 "nslookup" 是否解析 "控制平面" 主机名
$ nslookup sdi-node01.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sdi-node01.sevone.com Address: 10.123.45.67/etc/resolve.conf 中搜索行中的 nslookup 名称 "sevone.com"
$ nslookup sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: sevone.com Address: 23.185.0.4/etc/resolve.conf 中搜索行中的 nslookup 名称 "nwk.sevone.com"
$ nslookup nwk.sevone.com Server: 10.168.16.50 Address: 10.168.16.50#53 Name: nwk.sevone.com Address: 25.185.0.4/etc/resolve.conf 中的 nslookup 名称服务器 "10.168.16.50"
$ nslookup 10.168.16.50 50.16.168.10.in-addr.arpa name = infoblox.nwk.sevone.com./etc/resolve.conf 中的 nslookup 名称服务器 "10.205.8.50"
$ nslookup 10.205.8.50 50.8.205.10.in-addr.arpa name = infoblox.colo2.sevone.com.注: 如果以上终端窗口 1 或终端窗口 2 中的任何 nslookup 命令失败或返回以下一个或多个命令，那么必须首先解决名称解析问题，否则 SevOne Data Insight 将无法工作。示例
** server can't find 67.45.123.10.in-addr.arpa.: NXDOMAIN or ** server can't find 68.45.123.10.in-addr.arpa.: NXDOMAIN or *** Can't find nwk.sevone.com: No answer etc.如果在部署 SevOne Data Insight 后由于任何原因导致名称解析失败，那么这也可能导致 SevOne Data Insight 中的正常操作失败。 因此，建议确保 DNS 配置始终正常工作。
错误: 无法打开标识文件 "/home/sevone/.pub": 无此类文件或目录
作为一种安全措施，全新安装 不 随附预先生成的 SSH 密钥。
- 使用 ssh ，以 sevone 身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight 'control plane' node IP address or hostname> - 执行以下命令为集群生成唯一 SSH 密钥。
$ sevone-cli cluster setup-keys
SevOne Data Insight 和 SevOne NMS 之间的 TimeShift
如果 SevOne Data Insight 与 SevOne NMS 设备之间的时间差超过 5 分钟，那么必须执行以下步骤。
- 检查 SevOne Data Insight 设备上的时间。
$ date - 检查 SevOne NMS 设备上的时间。
$ date - 如果 SevOne Data Insight 与 SevOne NMS 设备之间的时间差超过 5 分钟，请检查这两个设备上的 NTP 配置。 这两个设备都必须与 NTP 进行时间同步。注: 如果 NTP 服务器不可用，请在两个设备上手动设置相同的时间，如以下示例中所示。示例
$ date --set="6 OCT 2023 18:00:00"
预检失败
TASK [确认可用空间]
- 如果此任务失败，那么可以尝试清除在文件系统的各个部分中可能找到的旧安装程序文件。 例如，
- /root
- /home/sevone
- /opt/SevOne/upgrade
- /var/lib/rancher/k3s/agent/images
重要提示： 在进行清理之前，请务必小心谨慎。 确保只删除不再需要且已确认可安全删除的文件。 例如，查找格式为sdi-x.y.z-build.<###>.tgz的安装文件，其中 x.y.z 是旧版本，而不是您要升级的版本。 - 清除调度的报告高速缓存。 执行以下命令以删除超过一周 (604800 秒) 的文件。注: SevOne Data Insight 维护已调度报告的打印 PDF 的高速缓存。 根据您对报告调度的使用情况，建议偶尔清除高速缓存以释放磁盘空间。
$ sevone-cli exec graphql -- "npm run asset-sweeper -- --prefix=scheduledReports --age=604800"您可以运行以下命令来删除超过一周 (604800 秒) 的文件。
- 运行以下命令可帮助跟踪系统中占用空间最大的文件。
$ du -sh /* - 在您的调查中，如果您发现以下目录正在填满您的 HDD (硬盘) ，那么它是一个容器或一个 pod 才是罪魁祸首。
$ /var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots重要： 请勿删除文件夹。 只删除安全且批准删除的文件。 删除文件时请谨慎操作。 如果文件夹被意外删除，可以通过运行以下命令来恢复。$ sudo systemctl restart containerd $ sudo systemctl restart k3s必须继续运行 du -sh 以进一步精确定位容器或 pod。 在某些情况下，由于 node.js 核心转储文件，它可能是占用空间的 打印机 容器。 执行以下命令以标识这些文件。
$ find /var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots \ -name "core\.*"
安装/升级失败
TASK [ k3s : 初始化集群]
如果此任务失败，您可以使用以下命令来观察 k3s 服务的状态。
$ systemctl status k3s找不到合适的网络地址。 找不到缺省路径。
检查是否向路由表添加了缺省路由。
$ ip route | grep default如果此返回为空，那么您将需要添加缺省路由。
添加缺省路由
$ ip route add default via <default_gateway>TASK [如果升级到新版本，请停止 k3s-server ]
如果此任务未在一分钟内完成，那么您必须先应用以下变通方法，然后再继续升级。
注意： 如果使用图形用户界面安装程序进行升级，则必须停止图形用户界面安装程序 API 和客户端进程。
停止 API 和客户机进程
$ sudo systemctl status sevone-guii-@api
$ sudo systemctl status sevone-guii-@client
$ sudo systemctl start sevone-guii-@api
$ sudo systemctl start sevone-guii-@client
$ sudo systemctl stop sevone-guii-@api
$ sudo systemctl stop sevone-guii-@client$ sed -i 's/.*k3s-killall.sh.*/ echo noop/' \
/opt/SevOne/upgrade/ansible/playbooks/roles/k3s/tasks/02_setup.yaml
$ sevone-cli playbook up --tags kube,apps,kernel这是由于尝试关闭某些正在运行的 containerd 进程时，上游问题导致 k3s-killall.sh 脚本挂起。
TASK [prep: 确保设置主机名]
尝试运行升级时，可能会迂到以下错误。
TASK [prep : Ensure hostname set] ****************************************************************************************************************************************************
fatal: [sevonek8s]: FAILED! => {“changed”: false, \
“msg”: “Command failed rc=1, out=, err=Could not get property: \
Failed to activate service ‘org.freedesktop.hostname1’: timed out\n”}当 hostnamed 可能崩溃时，会发生此情况。 重新启动 hostnamed。
$ sudo systemctl restart systemd-hostnamed重要信息: 如果 hostnamed 重新启动不起作用，请重新启动机器。
$ sudo rebootTASK [运费: 安装 rhel8-update-*.el8.tgz ]
升级到 SevOne Data Insight> = 3.8 或更高版本时，元凶可能是软件包更新太晚。 如果您的机器具有因特网访问权并且可以解析 yum 软件包服务器，那么可能会发生此情况。 此修订将在跳过具有中断依赖关系的 yum 软件包时重试升级。
- 除去挥之不去的 yum 软件包或软件包冲突。
$ sudo yum clean all $ sudo rm -rf /var/cache/yum/ - 通过命令行界面 (CLI) 重试升级。
$ sevone-cli playbook up --extra-vars "freight_install_skip_broken=yes"
任务 [ helm upgrade/install default/<chart_name> ]
此任务可能失败的原因有几个。 不幸的是， Helm 不会报告错误或有用的调试信息。 因此，需要对此进行进一步调查。 请在任务输出中返回的大型 JSON 主体中查找 stderr 键。
升级失败: 部署应用程序
如果要在 3.5.x 版本之间进行升级，例如从 3.5.1 升级到 3.5.3，那么升级将无法部署应用程序。
要解决此问题，请在执行升级之前执行以下命令。
$ sevone-cli playbook up --skip-tags apps,kernel
$ sudo systemctl restart k3s
$ ssh sevone@<'agent' IP address>
$ sudo systemctl restart k3s-agent常规调试提示
任务 helm upgrade/install default/<chart_name> 可能失败的原因有几个。 Helm 未提供有用的调试信息，需要进一步调查以了解故障。
- 执行以下命令以 重试 升级。
$ sevone-cli playbook up --tags apps - 在执行上述命令时，从另一个终端窗口运行 k9s。
- 监视每个 pod 的状态，并参阅下表以了解一些基本调试方法。注: 如果通过 k9s观察日志时未显示日志，请按 0 以始终启用日志。
状态 操作 CrashLoopBackOff 通过将鼠标悬停在 pod 上并按 1来检查 pod 日志。 错误 通过将鼠标悬停在 pod 上来检查 pod 日志，并通过将鼠标悬停在 pod 上并按 1来按 "检查 pod 日志"。 暂挂 通过将鼠标悬停在 pod 事件日志上并按 d来检查该日志。
其他问题
获取 NMS IP 列表时出错
注意：
本节仅适用于 SevOne NMS 在 6.x 上出现此错误的情况。
注： SOA 版本
- SevOne NMS 群集中所有设备上的 SOA 必须是最新版本。 必须使用命令行界面 (CLI) 在 all 对等设备上升级 SOA，因为图形用户界面 (GUI) 只能为所连接的 NMS 设备升级 SOA。
- 如果要在群集中的所有对等机上安装/升级 SOA，请添加标记 --all-peers 。
错误
$ sevone-cli soa upgrade /opt/SevOne/upgrade/utilities/SevOne-soa-*.rpm --all-peers
>> [INFO] ATTEMPTING TO AUTO-DETECT SOA DATASOURCES...
Defaulted container "mysql" out of: mysql, metrics
...
...
<returns an ERROR>
如果收到此错误，请确保您以 sevone身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight IP address or hostname>
现在，重新运行该命令以 升级 SOA。
$ sevone-cli soa upgrade /opt/SevOne/upgrade/utilities/SevOne-soa-*.rpm --all-peers
在引导和/或供应提示中输入了不正确的信息?
如果在引导和/或供应提示中输入了不正确的信息，请执行以下命令以允许您覆盖输入。 这些命令只能在 SevOne Data Insight 启动并运行后运行。
$ ssh sevone@<SevOne Data Insight IP address or hostname>
$ sevone-cli exec graphql -- npm run bootstrap -- -f
$ sevone-cli exec graphql -- npm run provision -- -f
注: 这些命令的用途是通过引导程序和供应提示重新运行。 如果第一次提供不正确的信息，它们尤其有用。
Pod 处于终止状态
如果 pod 被卡住，而您又想让它重启，可以在删除 pod 命令的末尾添加 --grace-period=0 --force 。
示例
$ ssh sevone@<SevOne Data Insight IP address or hostname>
$ kubectl delete pod $(kubectl get pods | grep 'dsm' | awk '{print $1}') --grace-period=0 --force查看/收集日志
可以在 pod 级别收集日志。 Pod 的状态必须为 正在运行。
注意： 在下面的命令中，要获取日志，需要输入 <resource-type/pod-name>。例如 deployment.apps/di-printer 或 deploy/di-printer。
缺省情况下， resource-type = pod。 对于资源类型 = pod 的日志，您可以选择只传递 pod 名称；资源类型为可选项。
使用 ssh，以 sevone身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight IP address or hostname>
示例: 获取 "pod" 名称
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
di-create-secrets-xllfj 0/1 Completed 0 22h
di-upgrade-l2cs8 0/1 Completed 0 22h
clienttest-success-89lmt 0/1 Completed 0 22h
clienttest-fail-lb8mq 0/1 Completed 0 22h
di-report-version-sweeper-28276440-zpcxt 0/1 Completed 0 20h
ingress-ingress-nginx-controller-54dfdbc9cf-g9wdz 1/1 Running 0 22h
di-prometheus-node-exporter-shnxk 1/1 Running 0 22h
di-graphql-7d88c8c7b5-fbwgc 1/1 Running 0 22h
di-ui-5b8fbcfc54-rtwlq 1/1 Running 0 22h
di-kube-state-metrics-6f4fbc67cb-tsbbk 1/1 Running 0 22h
di-migrator-fdb9dd58b-29kl2 2/2 Running 0 22h
ingress-ingress-nginx-defaultbackend-69f644c9dc-7jvvs 1/1 Running 0 22h
di-printer-7888679b59-cqp9q 2/2 Running 0 22h
di-scheduler-7845d64d57-bdsm2 1/1 Running 0 22h
di-registry-68c7bbc47b-45l5v 1/1 Running 0 22h
di-djinn-api-5b4bbb446b-prsjd 1/1 Running 1 (22h ago) 22h
di-mysql-0 2/2 Running 0 22h
di-prometheus-server-7dc67cb6b5-bjzn5 2/2 Running 0 22h
di-redis-master-0 2/2 Running 0 22h
di-wdkserver-6db95bb9c9-5w2kt 2/2 Running 0 22h
di-assetserver-5c4769bd8-6f2hw 1/1 Running 0 22h
di-prometheus-node-exporter-mp5xf 1/1 Running 0 22h
di-report-tombstone-sweeper-28277040-kj227 1/1 Running 0 10h
datasource-operator-controller-manager-5cf6f7f675-h5lng 2/2 Running 3 (5h37m ago) 22h
di-asset-sweeper-28277645-tq6gb 0/1 Completed 0 12m
di-user-sync-28277645-dl6ks 0/1 Completed 0 12m
di-asset-sweeper-28277650-hxwvn 0/1 Completed 0 7m46s
di-user-sync-28277650-6kxf7 0/1 Completed 0 7m46s
di-asset-sweeper-28277655-gjtpr 0/1 Completed 0 2m46s
di-user-sync-28277655-chgxd 0/1 Completed 0 2m46s
重要信息: Pod 名称是在列 NAME下找到的名称。
获取资源类型
获取 "所有 "资源类型
$ kubectl get all | more
获取 pod 的资源类型
$ kubectl get all | grep <pod-name>
示例: 获取包含 "printer" 的 pod 名称的资源类型
$ kubectl get all | grep printer
pod/di-printer-68f6bddb6f-hkhdt 1/1 Running 2 (27h ago) 2d3h
deployment.apps/di-printer 1/1 1 1 2d3h
replicaset.apps/di-printer-68f6bddb6f 1 1 1 2d3h
示例: 获取包含 "rabbitmq" 的 pod 名称的资源类型
$ kubectl get all | grep rabbitmq
pod/di-rabbitmq-0 1/1 Running 2 (27h ago) 2d3h
service/di-rabbitmq-headless ClusterIP None <none> 4369/TCP,5672/TCP,25672/TCP,15672/TCP 2d3h
service/di-rabbitmq ClusterIP 192.168.108.109 <none> 5672/TCP,4369/TCP,25672/TCP,15672/TCP,9419/TCP 2d3h
statefulset.apps/di-rabbitmq 1/1 2d3h
重要： pod、 deployment.apps, replicaset.apps 服务 statefulset.apps 等是资源类型。
上面例子中的 di-printer, di-rabbitmq 等都是 pod 名称。
获取日志
$ kubectl logs <resource-type>/<pod-name>
示例: 获取 pod-name "di-printer" 的日志
$ kubectl logs deployment.apps/di-printer
OR
$ kubectl logs deploy/di-printer
示例: 获取 pod-name "di-rabbitmq" 的日志
$ kubectl logs statefulset.apps/di-rabbitmq
OR
$ kubectl logs sts/di-rabbitmq
示例: 获取具有时间戳记的 pod 名称 "rabbitmq" 的日志
$ kubectl logs statefulset.apps/di-rabbitmq --timestamps
OR
$ kubectl logs sts/di-rabbitmq --timestamps
缺省情况下， resource-type = pod。
In the example below, to obtain the logs for <resource-type>/<pod-name> = pod/di-mysql-0, <resource-type> Pod is 可选.
示例：<资源类型> = pod; <资源类型> 为可选项
$ kubectl logs pod/di-mysql-0
OR
$ kubectl logs di-mysql-0
重要信息: 每个 pod 都可以有一个或多个关联的容器。
收集具有一个容器的 Pod 的日志
- 使用 ssh，以 sevone身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight IP address or hostname> - 获取属于 pod 的容器的列表。示例：Pod 名称 " di-mysql-0 "包含一个容器 "mysql
$ kubectl get pods di-mysql-0 -o jsonpath='{.spec.containers[*].name}{"\n"}' mysql metrics - 收集日志。注: 对于仅具有一个容器的 pod ，以下命令中的 -c < container-name > 是 可选。
$ kubectl logs <pod-name> -c <container-name> or $ kubectl logs <pod-name>示例$ kubectl logs di-mysql-0 -c mysql or $ kubectl logs di-mysql-0
收集具有多个容器的 Pod 的日志
- 使用 ssh，以 sevone身份登录到 SevOne Data Insight。
$ ssh sevone@<SevOne Data Insight IP address or hostname> - 获取属于 pod 的容器的列表。示例：Pod 名称 " svclb-ingress-ingress-nginx-controller-6fbfd "包含两个容器，即 " lb-port-80 "和 " lb-port-443 "。
$ kubectl get pods svclb-ingress-ingress-nginx-controller-5pcm7 \ -o jsonpath='{.spec.containers[*].name}{"\n"}' lb-port-80 lb-port-443 - 收集日志。重要信息: 对于具有多个容器的 pod ，需要 -c < container-name > 。
$ kubectl logs <pod-name> -c <container-name>示例获取 <container-name> 的日志 = lb-port-80$ kubectl logs svclb-ingress-ingress-nginx-controller-vzcqj -c lb-port-80示例获取 <container-name> 的日志 = lb-port-443$ kubectl logs svclb-ingress-ingress-nginx-controller-vzcqj -c lb-port-443
收集所有日志
- 要收集与 SevOne Data Insight pod 及其容器相关的所有日志，请创建可收集所有日志的工作目录。
$ TMPDIR="/tmp/sdi_logs/$(date +%d%b%y)" $ mkdir -p $TMPDIR - 执行以下命令以收集所有 SevOne Data Insight 容器的所有日志。注: 以下命令中的 -- timestamps 选项允许您使用时间戳记收集日志。
示例: 用于从所有 SevOne Data Insight Pod 和容器收集日志的命令
$ for POD in $(kubectl get pods --no-headers -n default | \ awk '{print $1}'); do for CONTAINER in $(kubectl get pods \ $POD -o jsonpath='{.spec.containers[*].name}{"\n"}'); \ do echo "Collecting logs for POD: $POD - CONTAINER: \ $CONTAINER in log file $TMPDIR/$POD_$CONTAINER.log.gz" ; \ kubectl logs $POD -c $CONTAINER --timestamps | \ gzip > $TMPDIR/$POD_$CONTAINER.log.gz 2>&1; done ; done此处显示了 for 命令，其中包含清晰的缩进。
for POD in $(kubectl get pods --no-headers -n default | awk '{print $1}') ; do for CONTAINER in $(kubectl get pods $POD -o jsonpath='{.spec.containers[*].name}{"\n"}') ; do echo "Collecting logs for POD: $POD - CONTAINER: $CONTAINER in log file $TMPDIR/$POD_$CONTAINER.log.gz" ; kubectl logs $POD -c $CONTAINER --timestamps | gzip > $TMPDIR/$POD_$CONTAINER.log.gz 2>&1 ; done ; done用于查看 $TMPDIR 中包含的文件的命令
$ ls -lh $TMPDIR - 收集日志后，可以将内容放入 tar 文件中。 由于日志已压缩，因此无需再次压缩。
$ tar -cf /tmp/sdi_logs-$(date +%d%b%y).tar $TMPDIR $ ls -l /tmp/sdi_logs-$(date +%d%b%y).tar $ md5sum /tmp/sdi_logs-$(date +%d%b%y).tar - 删除日志目录以释放空间。
$ rm -rf $TMPDIR - 您可以在 /tmp/sdi_logs-$(date +%d%b%y) .tar 中上载 tar 文件以进行进一步调查。
重新引导后处于 "未就绪" 状态的 "代理程序" 节点
如果 代理程序 节点在重新引导后处于 未就绪 状态，请执行以下操作。
确保数据洞察已 100% 部署
通过运行以下命令来检查部署的状态。 确保所有内容都处于 正在运行 状态。
$ ssh sevone@<SevOne Data Insight IP address or hostname>
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
di-create-secrets-xllfj 0/1 Completed 0 22h
di-upgrade-l2cs8 0/1 Completed 0 22h
clienttest-success-89lmt 0/1 Completed 0 22h
clienttest-fail-lb8mq 0/1 Completed 0 22h
di-report-version-sweeper-28276440-zpcxt 0/1 Completed 0 20h
ingress-ingress-nginx-controller-54dfdbc9cf-g9wdz 1/1 Running 0 22h
di-prometheus-node-exporter-shnxk 1/1 Running 0 22h
di-graphql-7d88c8c7b5-fbwgc 1/1 Running 0 22h
di-ui-5b8fbcfc54-rtwlq 1/1 Running 0 22h
di-kube-state-metrics-6f4fbc67cb-tsbbk 1/1 Running 0 22h
di-migrator-fdb9dd58b-29kl2 2/2 Running 0 22h
ingress-ingress-nginx-defaultbackend-69f644c9dc-7jvvs 1/1 Running 0 22h
di-printer-7888679b59-cqp9q 2/2 Running 0 22h
di-scheduler-7845d64d57-bdsm2 1/1 Running 0 22h
di-registry-68c7bbc47b-45l5v 1/1 Running 0 22h
di-djinn-api-5b4bbb446b-prsjd 1/1 Running 1 (22h ago) 22h
di-mysql-0 2/2 Running 0 22h
di-prometheus-server-7dc67cb6b5-bjzn5 2/2 Running 0 22h
di-redis-master-0 2/2 Running 0 22h
di-wdkserver-6db95bb9c9-5w2kt 2/2 Running 0 22h
di-assetserver-5c4769bd8-6f2hw 1/1 Running 0 22h
di-prometheus-node-exporter-mp5xf 1/1 Running 0 22h
di-report-tombstone-sweeper-28277040-kj227 1/1 Running 0 10h
datasource-operator-controller-manager-5cf6f7f675-h5lng 2/2 Running 3 (5h37m ago) 22h
di-asset-sweeper-28277645-tq6gb 0/1 Completed 0 12m
di-user-sync-28277645-dl6ks 0/1 Completed 0 12m
di-asset-sweeper-28277650-hxwvn 0/1 Completed 0 7m46s
di-user-sync-28277650-6kxf7 0/1 Completed 0 7m46s
di-asset-sweeper-28277655-gjtpr 0/1 Completed 0 2m46s
di-user-sync-28277655-chgxd 0/1 Completed 0 2m46s
注意：要查看其他 pod 的详细信息，可以使用 kubectl get pods -o wide 命令。
重新启动 SOA
如果 SevOne NMS 已升级或降级，请确保在成功升级/降级后重新启动 SOA 容器。 执行以下命令。
从 SevOne NMS 设备，
$ ssh root@<NMS appliance>
$ supervisorctl restart soa