altinity-expert-clickhouse-logs

系统日志表健康状况

通过 system.tables、system.parts、system.disks、system.query_thread_log 和 system.crash_log，回答“系统日志是否可用，以及是否正在占用大量磁盘空间？”。其他技能依赖这些表，因此如果某个工具包未返回数据，请先运行此项检查。 如果尚未确定连接模式、集群和时间窗口，请先运行 altinity-expert-clickhouse-connection。

查询包

• checks.sql — 6 项检查，输出 Altinity 标识 A0.2.01 至 A0.2.08：query_log 和 part_log 的新鲜度、超过 30 天的 query_log 数据、没有 TTL 的系统日志表、占用磁盘超过 20% 的系统日志、版本升级遗留的 system.*_logN 表、仍处于启用状态的 query_thread_log，以及近期的 crash_log 记录。每条语句仅在规则被违反时返回行，因此结果为空表示正常。检查 A0.2.01 需要 system.part_log，A0.2.07 需要 system.query_thread_log，A0.2.08 需要 system.crash_log；如果这些表不存在，请跳过对应检查。
• reference.md — 背景信息（设置、容量规划、反模式）；仅在需要解释建议时阅读。

如何运行查询包

1. 从此技能的目录中读取每个包文件（技能加载器会输出目录路径）。
2. 一次运行一条语句，切勿运行整个文件。语句以 ; 结尾，并以 -- @check <id> <title> 标头开头；保留标识并与结果一起记录。
3. 遵循 -- @requires：如果指定的表不存在、需要 keeper 但服务器没有 Keeper/ZooKeeper，或者不满足版本条件，则跳过该语句。列出跳过的标识及原因。
4. 如果存在集群宏，请保留 {cluster} 原样；否则应用连接技能的改写规则。其他任何 {placeholder} 都是模板变量：先替换为实际值，或跳过该语句。
5. 出错时，记录检查标识和错误的首行，然后继续。仅当错误为 UNKNOWN_IDENTIFIER 时，运行 DESCRIBE TABLE system.<table> 并移除缺失的列。
6. severity 列就是该行的判定结果。照录即可；不要重新评级。

解读规则

• query_log 或 part_log 中没有新鲜记录（A0.2.01、A0.2.02），意味着日志已禁用或服务器最近重启过，并不表示服务器处于空闲状态。对于依赖这些表的技能，应将其报告为阻碍项，而不是健康结果。
• 没有 TTL 的系统日志表（A0.2.04）会持续增长，直至磁盘空间耗尽。建议保留时长，并使用 ALTER TABLE system.<name> MODIFY TTL event_date + INTERVAL <n> DAY 应用：

表	保留时长	备注
query_log	7-30 天	主要的取证表；如果磁盘空间允许，保留 30 天。
query_thread_log	禁用，或 3 天	每个查询的每个线程一行。日志非常详细，且很少需要。
part_log	14-30 天	用于分析合并、变更和数据摄取问题的根本原因。
trace_log	3-7 天	占用空间较大；仅在性能分析期间有用。
text_log	7-14 天	用于结合上下文查看错误和警告。
metric_log	7-14 天	每台主机每秒一行；适用于趋势分析。
asynchronous_metric_log	7-14 天	数据量较小。
crash_log	90 天或更久	占用空间极小且很少写入；应长期保留。

• system.*_log1、*_log2 等表（A0.2.06）是遗留表：升级时，ClickHouse 会重命名不兼容的日志表并创建新表。它们之后不会再被读取；如果不再需要旧数据，应将其删除。
• 在任何繁忙的服务器上，启用 query_thread_log（A0.2.07）都属于一项发现。除非特定调查需要每个线程的数据，否则应在服务器配置中将其禁用。
• 近期的 crash_log 行（A0.2.08）意味着服务器发生过崩溃，而不只是重启。将其与运行时长以及 system.text_log 中的警告关联分析，然后再判断其他发现是否由同一事件导致。
• 更改系统日志表的 TTL 只会影响之后的清理。使用 TRUNCATE TABLE system.<name> 或删除旧分区来回收现有空间。

报告格式

1. 标题：连接模式、集群或“单节点”、ClickHouse 版本、时间范围。
2. 发现：包含 check、severity、object、evidence、recommendation 列的表格；每项发现占一行，严重问题优先。evidence 引用结果行中的数字。
3. 正常检查：用一行列出未返回问题行的检查 ID。
4. 跳过和失败的检查：列出 ID 和原因或第一行错误信息。切勿省略此部分。
5. 后续步骤：接下来要加载的技能和立即采取的行动。

后续技能

• 系统日志占用大量磁盘空间，或磁盘空间即将耗尽 → 加载技能 altinity-expert-clickhouse-storage
• 存在且仍有新记录的 part_log，需要分析 part 或合并活动 → 加载技能 altinity-expert-clickhouse-part-log
• 存在崩溃记录或反复重启 → 加载技能 altinity-expert-clickhouse-metrics
• query_log 状态正常，需要分析慢查询或失败查询 → 加载技能 altinity-expert-clickhouse-reporting
• 仍不清楚服务器的整体健康状况 → 加载技能 altinity-expert-clickhouse-overview