到了isilon的OneFS 8 版本，系统就引入了isi healthcheck的工具用来做系统的健康检查，不同的版本功能差异是比较大的，在老的版本上需要单独安装这个包，但是新的OneFS版本应该和操作系统集成了，不需要再单独安装，直接运行命令就可以了。
OneFS 内置的一套"规则化体检框架"，用来检查集群当前的软件状态、硬件状态、配置状态，以及升级前后的风险点。IOCA（Isilon On-Cluster Analysis）已经整合进这个 HealthCheck RUP 框架里，所以它不只是做日常巡检，也能辅助做升级规划。
码字不易，欢迎点赞、关注、添加v：StorageExpert，下次更新不迷路。
isi healthcheck 到底是什么
它不是单一一条检查命令，而是一个检查框架。isi healthcheck 用来评估集群中特定软件组件、硬件组件以及集群环境的状态；而且 IOCA 也被集成了进去，可以分析正在运行的集群健康状态，并帮助规划升级。
- 它不是"修复工具"，而是一个故障诊断工具
- 它不是只看一个点，而是把很多检查点组织成体系
- 它既能查日常健康，也能查升级前/后风险
- 它能检查单节点问题，也能检查全局集群问题
一些核心概念
Item
Item 就是"单个检查项"。
比如：
- 检查某节点 DIMM 错误日志
- 检查 boot drive wear
- 检查 AVScan 服务状态
- 检查集群剩余容量
有些 item 是 Per node，每个节点单独检查；有些是 Per cluster，整个集群作为一个整体检查。举例说，DIMM error 这种是按节点检查，而 free space 这种是按集群检查。所以，可以把它理解为：item就是一个具体的健康规则。
Checklist
Checklist 就是"检查项集合"。
比如：
- basic
- pre_upgrade
- post_upgrade
- performance
- smartconnect
- synciq
- nfs
- smb
每个 checklist 都包含一组 item。也就是说：checklist = 一类场景下要跑的一组检查
我手头的这个版本，一共列出了 19 个 checklist，包括basic、auth、avscan、cluster_capacity、infiniband、job_engine、ntp、performance、pre_upgrade、post_upgrade、smartconnect、smartpools、smb、snapshot、synciq 等。
是不是随着版本的不同，这些检查项会发生变化，这个我不清楚。
Parameters
Parameter 是某些 item 的参数。比如 auth_ad_clock_skew，它有个参数叫 ad_provider，可以给它赋值 win_ad。这些参数通过 isi healthcheck parameters set 来设置。
这意味着 healthcheck 不是一成不变的，而是可以通过参数来调整：
- 有些检查项是可以带上下文的
- 有些场景需要你指定目标版本、目标服务、目标环境
这在 pre_upgrade 特别有意义，pre_upgrade 这个 checklist 里有很多 item 会用到 target_version 参数。
Evaluation
Evaluation 就是一次实际的"运行结果"。当你执行一次 checklist 或 item，它的结果会被保存到：
/ifs/.ifsvar/modules/health-check/results/evaluations。
所以 healthcheck 不是只在屏幕上临时输出一下，它会留下结果记录，后续可以 list和view等命令来复查。
Freshness
这个概念很重要，很多人第一次用会误解。Freshness = 结果新鲜度/缓存有效期。每个 item 都有一个默认 Freshness 值。它决定再次评估时，是重新获取新数据，还是直接返回之前缓存的结果。举个例子，如果某 item 的 freshness 是 1D，就是一天内再次运行，就直接返回上次结果，而不是重新采集。这意味着：
- 刚处理完毕问题马上重跑，结果不一定立刻变
- 某些检查项需要强制 override freshness，才会重新抓实时状态
- healthcheck 的结果不一定 100% 等于"此刻现况"，它有缓存机制
这点特别关键。
healthcheck 包含哪些内容
我目前的这个版本：
- 有 19 个 checklist
- 有 215 个 item
- 其中还包含了 IOCA 前缀项（ioca_...）
比如 basic checklist 的示例里，就包含了这些东西：
- ioca_checkAuthStatus
- ioca_checkBMCandCMC
- ioca_checkBootDisks
- ioca_checkDriveFirmware
- ioca_checkDriveFirmwarePackage
- ioca_checkDriveLoad
- mellanox_blown_fuse
- celog_rep_pp
这说明 basic 其实已经覆盖了不少核心面：
- 认证状态
- BMC/CMC
- 启动盘
- 硬盘固件
- 驱动/负载
- 网卡/后端相关
- CELOG 相关告警机制
也就是说，basic 不是"很基础很简单"的意思，而是"集群总体健康总览"。
第一步：看有哪些 checklist
isi healthcheck checklists list
这个命令会列出当前 OneFS 版本可用的所有 health checks。
第二步：查看某个 checklist 里面有哪些 item
isi healthcheck checklists view basic
或者：
isi healthcheck checklists view smartconnect
这样你能知道这次检查到底会查什么。比如 smartconnect 示例里会查：
- nfs_dynamic_pools
- smb_dynamic_pools
- suspended_nodes
- auto_suspended_nodes
- smartconnect_enabled
- synciq_dynamic_pool
- flexnet_running
- dns_query_smartconnect_zones
- smartconnect_sip_responsive
- smartconnect_zone_resolution
第三步：执行 checklist
isi healthcheck evaluations run basic
或者：
isi healthcheck evaluations run pre_upgrade
evaluations run <ID> 会运行该 checklist 下定义的那些 item。
第四步：列出已经跑过的 evaluation
isi healthcheck evaluations list
它会显示：
- evaluation ID
- 状态（Queued / Completed）
- Failures
- Logs 路径
evaluation ID 由"checklist 名称 + 时间戳"组成。
第五步：查看详细结果
isi healthcheck evaluations view <evaluation_id> --verbose
verbose 结果会展开到每个节点、每个 item 的状态，比如 NFS 检查示例里会列出 Node 1 / Node 2 / Node 3 的 nfs_daemon、nfs_mount、nfs_rpc、nfs_service 等项。
第六步：如果某项 WARNING/CRITICAL，再单独看 item 的说明
isi healthcheck items view <item_name>
这一条非常重要。当某个 healthcheck item 返回 warning 或 failure 时，第一步 troubleshooting 就是看 item details。item details 会告诉你是否需要进一步处理，以及建议的处理动作。
healthcheck 输出状态
WARNING 就是警告，不是说马上就有问题了，CRITICAL的告警是需要关注的。
例1：celog_memory
- OK：14 天内没有 CELOG memory issues
- WARNING：14 天内有过 memory issues，可能只是异常负载，也可能是趋势开始
- CRITICAL：14 天内超过 50 次，说明压力非常大，要尽快调查
这说明：
- 有些 warning 是"观察项"
- 它不是马上说明系统坏了
- 它更像"趋势预警"
例2：celog_chan_fail
- WARNING：14 天内至少一次 channel send failure，可能漏过告警
- CRITICAL：14 天内超过 5 次，说明告警发不出去的问题已经严重，需要查 isi event list 和 /var/log/isi_celog_alerting.log
这说明：
- 某些 item 检查的是"告警机制本身是否健康"
- 不是业务直接坏，而是"出问题时你可能收不到通知"
例3：celog_service_restart / celog_process_restart
- 少量 restart 可能正常
- 大量 restart 才说明服务不稳定甚至极度不稳定
说明：
- healthcheck 里不少项是"趋势型监控"
- 要结合时间窗口和数量阈值看
Scope: Per node 和 Per cluster
Per node
表示每个节点各查各的。
典型意义：
- 你可能只有某 1 个节点坏
- 这类问题通常是局部硬件/局部服务/局部日志异常
- 查看结果时要看具体哪个 node fail
例如：
- battery_test_status
- boot_drive_wear
- avscan_service_status
这些都偏节点级。
Per cluster
表示整个集群只给一个总结果。
典型意义：
- 它查的是全局配置、全局容量、全局服务逻辑
- 这种 fail 更像"设计/配置/整体状态问题"
如：
- auth_enabled
- celog_enabled
都属于 cluster 级别。
常用检查项checklist
basic
总览型检查。
适合：
- 日常巡检
- 接手陌生集群先摸底
- 故障后先跑一个全局健康概览
pre_upgrade
升级前检查。
这个checklist的很多 item 会用 target_version 参数。说明它不只是看"现在好不好"，而是看"你要升到某个版本前是否有障碍"。
post_upgrade
升级后验证。
适合确认：
- 升级后服务起来没
- 配置是否继承正常
- 某些组件是否进入异常状态
performance
主要是检查性能方面的问题的。出现"集群慢和客户端卡"的时候的检查项目。
smartconnect
SmartConnect 相关专项。
适合排查：
- DNS 解析
- SIP 响应
- dynamic pool
- suspended node
- zone resolution
nfs / smb
协议专项。
文档里 nfs 的 verbose 示例就展示了 NFS 服务检查的粒度。
cluster_capacity
容量健康专项。
当我们关心：
- pool/cluster 剩余空间
- 容量是否接近阈值
- 容量相关风险
就需要检查这个。
常用命令
isi healthcheck checklists list
isi healthcheck checklists view <id>
isi healthcheck items list
isi healthcheck items view <id>
isi healthcheck parameters list
isi healthcheck parameters view <name>
isi healthcheck evaluations list
isi healthcheck evaluations view <id>
执行类
isi healthcheck evaluations run <checklist>
还支持高级参数：
--override-pass <item>:<pass-status>
--override-fresh <item>:<freshness>
--override-thresholds <item>:<critical>:<warning>:<ok>
--parameter <name>:<value>
这些参数可以用来对跑的健康检查做些控制：
- 你可以临时覆盖某个 item 的pass状态
- 可以覆盖 freshness，强制更新
- 可以调阈值
- 可以传参数
这些在升级、特殊环境、实验性分析中都很实用。
控制 evaluation 状态
isi healthcheck evaluations pause <id>
isi healthcheck evaluations resume <id>
isi healthcheck evaluations cancel <id>
参数管理
isi healthcheck parameters set <name> <value>
isi healthcheck parameters delete <name>
用于修改 item/checklist 相关的运行参数。
另外，healthcheck 还可以定时运行
- 系统可以在 cluster time 每天 00:00 自动跑一次
- 由 isi_cron_control 控制
- 可以查看、启用、禁用
命令是：
isi_cron_control hc_daily status
isi_cron_control hc_daily enable
isi_cron_control hc_daily disable
这意味着它可以做成自动化的"日常检查"。
IOCA与HEALTHcheck的关系
- IOCA 位于 /usr/libexec/isilon/ioca/
- 更新 IOCA 后，HealthCheck 框架会自动检测到新版本
- 然后触发 IOCA 相关 item，ioca checklist 也会更新
这说明在这份 RUP 里：
- IOCA 不是独立工具了
- 它已经变成 healthcheck 体系的一部分
- 所以你看到很多 ioca_ 前缀项，是正常的
这个 healthcheck 更像是一个"规则引擎 + 巡检框架"，而不是简单脚本。这个healthcheck 有几个特点：
优点
- 把很多散乱检查项统一封装
- 结果可追踪、可复查
- 有分层结构：checklist / item / parameter / evaluation
- 适合升级前后验证
- 对 SmartConnect、NFS、SMB、容量、CELOG 这类专题很实用
- 集成 IOCA 后，对升级规划价值更高
局限
- 它是"规则判断"，不是一个故障分析工具
- WARNING 可能只是趋势提醒，不是故障
- 由于有 freshness 缓存，所以每次运行的结果不一定是最实时的东西
- 某些异常仍然要回到日志、事件、服务状态、硬件层面去查
大礼包，现场直接用的
日常巡检
isi healthcheck evaluations run basic
isi healthcheck evaluations list
isi healthcheck evaluations view <id> --verbose
某类问题排查
例如 SmartConnect：
isi healthcheck evaluations run smartconnect
isi healthcheck evaluations view <id> --verbose
升级前
isi healthcheck evaluations run pre_upgrade --parameter target_version:<目标版本>
某个 item 报警后
isi healthcheck items view <item_name>
先看 item 自己的定义和处理建议，再决定要不要进一步看：
- isi event list
- /var/log/...
- 节点硬件状态
- 后端网络
- 磁盘/boot media/firmware
- 认证或协议服务状态