altinity-expert-clickhouse-logs

システムログテーブルの健全性

system.tables、system.parts、system.disks、system.query_thread_log、system.crash_logから、「システムログは利用可能か、ディスクを圧迫していないか」を確認します。他のスキルはこれらのテーブルに依存するため、パックがデータを返さない場合は、まずこれを実行してください。 接続モード、クラスター、時間範囲がまだ確定していない場合は、最初にaltinity-expert-clickhouse-connectionを実行してください。

クエリパック

• checks.sql — Altinity ID A0.2.01〜A0.2.08を出力する6つのチェックです。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. ステートメントはファイル全体ではなく、1つずつ実行します。ステートメントは;で終わり、-- @check <id> <title>ヘッダーで始まります。結果にはIDを残してください。
3. -- @requiresに従います。指定されたテーブルがない場合、keeperが必要なのにサーバーにKeeper/ZooKeeperがない場合、またはバージョン条件を満たさない場合は、そのステートメントをスキップします。スキップしたIDと理由を記録してください。
4. クラスター用マクロがある場合は、{cluster}を記述どおりに保持します。ない場合は、接続スキルの書き換えルールを適用します。その他の{placeholder}はテンプレート変数です。実際の値に置き換えるか、ステートメントをスキップしてください。
5. エラーが発生したら、チェックIDとエラーの最初の行を記録して続行します。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 days	主なフォレンジックテーブルです。ディスク容量に余裕があれば30日間保持してください。
query_thread_log	disable, or 3 days	クエリごとにスレッド単位で1行記録されます。非常に冗長で、必要になることはほとんどありません。
part_log	14-30 days	マージ、ミューテーション、データ取り込みの根本原因分析に必要です。
trace_log	3-7 days	サイズが大きく、プロファイリング中にのみ役立ちます。
text_log	7-14 days	エラーや警告を文脈に沿って読むために必要です。
metric_log	7-14 days	ホストごとに1秒あたり1行記録され、傾向分析に役立ちます。
asynchronous_metric_log	7-14 days	データ量は少なめです。
crash_log	90 days or more	ごく小さく、書き込み頻度も低いため、長期間保持してください。

• 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 の列を持つテーブル。調査結果ごとに1行を記載し、Critical を先に示します。Evidence には結果行の数値を引用します。
3. 問題のないチェック：問題行がなかったチェック ID を1行に列挙します。
4. スキップまたは失敗したチェック：ID と理由、またはエラーの先頭行を記載します。このセクションは省略しないでください。
5. 次のステップ：次に読み込むスキルと、直ちに行う対応。

次のスキル

• システムログがディスクの大部分を占めている場合、またはディスクの空き容量が少ない場合 → スキル altinity-expert-clickhouse-storage を読み込みます
• part_log が存在して最新であり、パーツまたはマージのアクティビティを分析する必要がある場合 → スキル altinity-expert-clickhouse-part-log を読み込みます
• クラッシュ記録または再起動の繰り返しがある場合 → スキル altinity-expert-clickhouse-metrics を読み込みます
• query_log が正常で、遅いクエリまたは失敗するクエリを分析する必要がある場合 → スキル altinity-expert-clickhouse-reporting を読み込みます
• サーバー全体の健全性がまだ不明な場合 → スキル altinity-expert-clickhouse-overview を読み込みます