---
title: "ログ問題"
slug: "cla-troubleshoot-log"
updated: 2026-10-20T09:05:28Z
published: 2026-10-20T09:05:28Z
canonical: "guide.ncloud-docs.com/cla-troubleshoot-log"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ログ問題

Classic/VPC環境で利用できます。

Cloud Log Analyticsの利用中に次のような問題が発生することがあります。問題ごとの原因と解決方法を確認し、適切に対処してください。

## ログ削除

ログを削除したいです。

#### 原因

Cloud Log Analyticsに保存されたログは任意に削除できません。

#### 解決方法

ログは任意に削除できず、保存期間(最大30日)が過ぎると古い順に自動的に削除されます。詳細な説明は、[Cloud Log Analytics の仕様](/docs/ja/cla-spec#%EC%A0%9C%EC%95%BD%EC%82%AC%ED%95%AD)をご参照ください。

## ログ収集の解除

Cloud DB for MySQLサービスを利用していますが、ログ収集機能を使いたくないです。

#### 原因

Cloud DBサービスは Cloud Log Analyticsと連携し、Errorログと Slow Queryログを収集して提供します。Cloud DBサービスは Cloud Log Analytics使用が必須であるため、Cloud Log Analyticsの解約とログ削除はできません。

#### 解決方法

Cloud DBサービスを利用している場合は、Cloud Log Analyticsとの連携解除はできません。

## filebeatログ照会

収集設定エージェントをインストールした後、ログが正常に送信されるかサーバで filebeatログを照会したいです。

#### 原因

filebeatのログはファイルとして作成しないよう設定されています。

#### 解決方法

ログファイルを保存したい場合は、次のように対応します。

1. `/etc/filebeat/filebeat.yml` ファイルの末尾に次の内容を追加します。

```
logging.level: debug
logging.to_stderr: false
logging.to_syslog: false
logging.to_files: true
logging.files:
  path: /var/log/filebeat
  name: filebeat
  keepfiles: 7
  permissions: 0644
```

1. エージェントを再起動します。

```
sudo systemctl restart filebeat.service
```

1. `/var/log/filebeat` パスに作成されたログファイルでエラーメッセージを確認します。

              参考

              

- ログファイルは最大7つまで作成された後に循環されるため、ディスクの使用量が増加し続けません。使用量をより減らしたい場合、`logging.level: error`、`keepfiles: 3`に設定した後に確認します。確認が完了したら、追加した設定を削除します。
- ログ収集パス、収集サーバアドレスなどのコンソールで設定する項目は、`filebeat.yml`ファイルで直接変更しないでください。詳細は、[特定のログ未収集](/docs/ja/cla-troubleshoot-log#%ED%8A%B9%EC%A0%95%EB%A1%9C%EA%B7%B8%EB%AF%B8%EC%88%98%EC%A7%91)をご参照ください。

## ログ転送エラー

エージェントをインストールして「Finish Installation」メッセージを確認したのに、ログ送信ができません。

#### 原因

ログが照会されない場合は、次のように区分されます。該当する状況の項目を事前にご確認ください。

| 照会ステータス | 確認項目 |
| --- | --- |
| 全体ログの未照会 | 以下の解決方法 |
| テンプレートログ(SYSLOG、Securityなど)正常照会、Custom Logのみ未照会 | [特定のログ未収集](/docs/ja/cla-troubleshoot-log#%ED%8A%B9%EC%A0%95%EB%A1%9C%EA%B7%B8%EB%AF%B8%EC%88%98%EC%A7%91) |
| Searchの Log Typeリストに一部の Log Typeを表示しない、ログ発生直後に未照会 | [収集ログ未照会](/docs/ja/cla-troubleshoot-log#%EC%88%98%EC%A7%91%EB%A1%9C%EA%B7%B8%EB%AF%B8%EC%A1%B0%ED%9A%8C) |

ログがまったく送信されない場合、その原因は次の通りです。

| 原因 | 確認方法 |
| --- | --- |
| エージェント(filebeat)プロセス未起動 | プロセスリストの照会結果に filebeatが不在 |
| ファイアウォール、ACG、サーバ内の `iptables`設定による収集サーバの通信遮断 | 収集サーバ `5043`ポートへのアクセス失敗 |
| インストールサーバポートのみ許可し、収集サーバポートを不許可 | インストールは完了したが、収集サーバ `5043`ポートへのアクセス失敗 |
| エージェント設定ファイルの未作成、収集サーバアドレスの漏れ | 設定ファイルの不在、または `output.logstash.hosts`値の不在 |
| エージェントがインストールされたサーバイメージで作成したサーバ | 以前のサーバ基準にインストールされたエージェント残留 |

#### 解決方法

以下の手順に確認して対応します。

1. エージェントプロセスが起動しているか確認します。

```
ps -ef | grep filebeat
```

- プロセスがない場合、`sudo systemctl restart filebeat.service`コマンドで再起動します。

1. エージェント設定ファイルが作成されているか、収集サーバアドレスが含まれているか確認します。

```
ls -altr /etc/filebeat/filebeat.yml
cat /etc/filebeat/filebeat.yml
```

- ファイルが存在しなかったり、内容がない場合はコンソールのインストールコマンドをサーバで再実行します。
- `output.logstash.hosts`項目に収集サーバアドレスとポートがあることを前提としています。

1. サーバから収集サーバに通信できるか確認します。収集サーバのポートは `5043/TCP`です。

```
telnet{収集サーバアドレス}5043
```

- Windowsサーバでは `Test-NetConnection {collection-server-address} -Port 5043`コマンドを利用します。
- 収集サーバアドレスは2番で確認した `output.logstash.hosts`の値です。

              注意

              

エージェントインストールで使用するインストール/管理サーバとログを送信する収集サーバはそれぞれ異なるサーバであり、ポートも異なります。インストール/管理サーバの `80/TCP`のみ許可した場合、インストールは完了しますがログは送信されません。2つのサーバの通信をすべて許可します。

1. 通信されない場合、ACGまたはファイヤーウォールで当該アドレスとポートのアウトバウンド通信を許可します。サーバ内で `iptables`を利用する場合、許可対象を destinationに登録する必要があります。
2. エージェントがインストールされた状態のサーバイメージで作成したサーバの場合、以前のサーバを基準にインストールされたエージェントが残っているため、ログが送信されないことがあります。エージェントを削除した後、当該サーバの **Management**画面で発行したインストールコマンドで再インストールします。
3. 上記の項目をすべて確認した後もログが送信されない場合、[filebeatログ照会](/docs/ja/cla-troubleshoot-log#filebeat%EB%A1%9C%EA%B7%B8%EC%A1%B0%ED%9A%8C)で診断ログを保存した後、`/var/log/filebeat`パスのエラーメッセージと共にサポートまでお問い合わせください。

## 特定のログ未収集

SYSLOG、Securityなどのテンプレートで設定したログは照会できますが、Custom Logのみ照会されません。

#### 原因

一部のログのみ収集されない場合、エージェント全体の問題ではなく当該 Log Typeの収集設定、または収集対象ファイルの問題です。原因は次の通りです。

| 原因 | 確認方法 |
| --- | --- |
| コンソール収集設定のサーバ未反映 | 設定ファイルの `paths`項目に当該ログパスが不在 |
| パスにファイル名を未指定 | `paths`項目がディレクトリまで指定 |
| パスまたはファイル名の誤字 | `paths`項目の文字列と実際のファイル名が一致しない |
| 収集対象ファイルが不在 | 指定したパスにファイルがない |
| シンボリックリンク対象ファイルの置換 | 固定されたリンクファイル名に指定 |
| テキストファイルでないファイルの指定 | バイナリファイルまたは圧縮ファイルの指定 |
| ログファイルの読み取り権限不足 | root権限でないアカウントでエージェントをインストール |

#### 解決方法

**1. 収集設定反映の有無確認**

最もよく発生する原因です。コンソールで収集ログを追加したり、パスを変更した後は **Management**画面に表示されるインストールコマンドをサーバで再実行することで、変更内容がエージェント設定ファイルに反映されます。

1. 設定ファイルに収集されないログのパスがあるか確認します。

```
cat /etc/filebeat/filebeat.yml
```

1. `paths`項目に当該パスがない場合、コンソールで当該サーバのインストールコマンドを再コピーしてサーバで実行します。

              注意

              

`filebeat.yml`ファイルの収集パスを直接変更しないでください。認証に使用される値はインストール時にサーバで作成されるため、ファイルを直接変更するとコンソールの収集設定と内容が一致しません。そのため、ログが収集されない場合があります。

**2. 収集パスと対象ファイルの確認**

1. 設定ファイルの`paths`項目にディレクトリパスのみ入力されていることを確認します。ログはファイル単位で収集されるため、パスにファイル名またはファイル名のパターンまで入力します。

- 収集されない例: `/home/nginx/log`
- 収集される例: `/home/nginx/log/access*.log`

1. `paths`項目の文字列と実際のファイル名が一致することを確認します。指定したパスにファイルがあるか、次のコマンドで確認できます。

```
ls -altr {ログパス}
```

1. 収集対象がシンボリックリンクであり、リンク対象ファイルが定期的に置き換えられる場合、固定されたリンクファイル名の代わりに実際のログファイル名のパターンに設定を変更します。
2. パスを変更した後は、1番の方法でインストールコマンドを再実行します。

              参考

              

**Logパス**入力ルールと例は、[Management](/docs/ja/cla-use-management#1%EC%BD%98%EC%86%94%EC%97%90%EC%84%9C%EB%A1%9C%EA%B7%B8%EC%88%98%EC%A7%91%EC%84%A4%EC%A0%95)をご参照ください。

**3. 収集対象ファイルの形式確認**

エージェントはテキストファイルのみ収集します。バイナリファイル(`wtmp`、`btmp`、`lastlog`など)や、圧縮ファイルは収集対象に指定しても正常に収集されません。テキスト形式に記録されるログファイルを指定します。

**4. エージェントインストールアカウントの確認**

一部のログファイルに読み取り権限のないアカウントでエージェントをインストールした場合、当該ログのみ収集されないことがあります。この場合、ログファイルの権限を変更する方法では解決できないため、root権限でエージェントを再インストールします。

**5. 追加確認**

上記の項目をすべて確認した後もログが収集されない場合、[filebeatログ照会](/docs/ja/cla-troubleshoot-log#filebeat%EB%A1%9C%EA%B7%B8%EC%A1%B0%ED%9A%8C)で診断ログを保存した後、`/var/log/filebeat`パスのエラーメッセージと共にサポートまでお問い合わせください。

## 収集ログ未照会

ログの収集中に Search画面で一部のログが照会されません。

#### 原因

以下はすべて正常動作であり、ログが収集されなかったわけではありません。

| 状況 | 原因 |
| --- | --- |
| Searchの Log Typeリストに特定の Log Typeを表示しない | ログ量の多い上位5つの Log Typeのみリストに表示 |
| 直前に発生したログ未照会 | ログ送信後、インデックスと検索が反映されるまでの時間差 |
| ワイルドカードで指定したローリングログの過去の内容未照会 | エージェントが既に読み取りした場所の後に追加された内容のみ送信 |

#### 解決方法

1. Searchの Log Typeリストにはログ量の多い上位5つの Log Typeのみ表示されます。リストに表示されない場合、当該ログが収集されなかったという意味ではありません。収集有無は、**Menu** > **All Services** > **Management & Governance** > **Cloud Log Analytics** > **Management**画面の収集設定ステータスでご確認ください。検索条件と検索結果の表示方法は、[Search](/docs/ja/cla-use-search)をご参照ください。
2. ログが送信された後、検索に反映されるまで時間差があります。ログ発生の直後に照会されない場合、しばらくしてから再照会してください。
3. ワイルドカードでローリングログを収集する場合、エージェントは各ファイルで既に読み取りした場所を管理し、その後に追加された内容のみ送信します。ファイルが新規作成されたり、置き換えられた場合にも、重複送信や漏れは発生しません。

              参考

              

本ガイドで必要な情報が見つからない場合やさらに必要な情報がある場合は、いつでも以下のフィードバックアイコンをクリックして、ご意見をお寄せください。いただいたご意見を参照して、より有益な情報を提供できるよう努力してまいります。