# システムログ

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。

<!-- body -->

## klog

klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。

klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。

klogネイティブ形式の例:

```
I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
```

### 構造化ログ








  <div class="feature-state-notice feature-alpha">
      <span class="feature-state-name">FEATURE STATE:</span>
      <code>Kubernetes v1.19 [alpha]</code>
    </div>
  



<div class="alert alert-danger" role="note"><h4 class="alert-heading">警告:</h4><p>構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。</p>
<p>ログの形式と値のシリアライズは変更される可能性があります。</p>
</div>


構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。

構造化ログの形式:

```ini
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
```

例:

```ini
I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
```


### JSONログ形式








  <div class="feature-state-notice feature-alpha">
      <span class="feature-state-name">FEATURE STATE:</span>
      <code>Kubernetes v1.19 [alpha]</code>
    </div>
  



<div class="alert alert-danger" role="note"><h4 class="alert-heading">警告:</h4><p>JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、<a href="/ja/docs/reference/command-line-tools-reference/">コマンドラインツールリファレンス</a>を参照してください。</p>
<p>すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。</p>
<p>フィールド名とJSONのシリアライズは変更される可能性があります。</p>
</div>


`--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。

```json
{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}
```

特別な意味を持つキー:
* `ts` - Unix時間のタイムスタンプ(必須、float)
* `v` - verbosity (必須、int、デフォルトは0)
* `err` - エラー文字列 (オプション、string)
* `msg` - メッセージ (必須、string)

現在サポートされているJSONフォーマットの一覧:
* <a class='glossary-tooltip' title='コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/command-line-tools-reference/kube-controller-manager/' target='_blank' aria-label='kube-controller-manager'>kube-controller-manager</a>
* <a class='glossary-tooltip' title='Kubernetes APIを提供するコントロールプレーンのコンポーネントです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='kube-apiserver'>kube-apiserver</a>
* <a class='glossary-tooltip' title='コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/command-line-tools-reference/kube-scheduler/' target='_blank' aria-label='kube-scheduler'>kube-scheduler</a>
* <a class='glossary-tooltip' title='クラスター内の各ノードで実行されるエージェント。コンテナがPod内で実行されていることを保証します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a>

### ログのサニタイズ








  <div class="feature-state-notice feature-alpha">
      <span class="feature-state-name">FEATURE STATE:</span>
      <code>Kubernetes v1.20 [alpha]</code>
    </div>
  



<div class="alert alert-danger" role="note"><h4 class="alert-heading">警告:</h4>ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。</div>


`--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。

現在ログのサニタイズをサポートしているコンポーネント一覧:
* kube-controller-manager
* kube-apiserver
* kube-scheduler
* kubelet


<div class="alert alert-info" role="note"><h4 class="alert-heading">備考:</h4>ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。</div>


### ログのverbosityレベル

`-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。

### ログの場所

システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。

* Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。
* kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。

systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。

## 次の項目

* [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。
* [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。
* [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/main/contributors/devel/sig-instrumentation/logging.md)について読む。