メインコンテンツまでスキップ
Sumo Logic Japanese

Syslog ソース

Syslog ソースは、syslog サーバのように動作し、syslog メッセージを受信する指定ポートをリッスンします。Syslog ソースを設定する場合、指定したポートに syslog データを送信するように、ホストまたは syslog 対応デバイスを設定します。   

複数の syslog 接続の場合は、それぞれの接続に個別にソースをセットアップし、ポート番号を設定します。

ソースを編集する場合、メタデータの変更内容はこれからのログに反映されます。過去に収集したログ データのメタデータは、遡って変更されることはありません。

ステップ 1: Syslog ソースの設定

  1. Sumo Web アプリケーションで、[Manage Data (データの管理)] > [Collection (コレクション)] > [Collection (コレクション)] を選択します。

  2. Syslog ソースを追加するインストール済みコレクタを見つけます。[Add (追加)] をクリックして、ポップアップ メニューから [Add Source (ソースの追加)] を選択します。
  1. [Syslog] をソース タイプとして選択します。
  2. 以下の項目を設定します。
  • Name (名前): 新しいソースに表示する名前を入力します。必要に応じて説明を入力します。ソースの名前は _sourceName というメタデータ フィールドとして格納されます。
  • Protocol (プロトコル):  syslog 対応デバイスが現在 syslog データの送信に使用しているプロトコル (UDP または TCP) を選択します。詳細については、「UDP または TCP の選択」を参照してください。
  • Port (ポート): ソースがリッスンするポート番号を入力します。コレクタが root として動作する場合 (デフォルト) は、514 を使用します。それ以外の場合は、1514 または 5140 にします。デバイスが同じポートに送信することを確認します。
  • Source Category (ソース カテゴリ): 収集されたメッセージを検索可能なメタデータ フィールド [_sourceCategory] でタグ付けするための文字列を入力します。たとえば、すべての収集済みメッセージを [_sourceCategory] フィールドでタグ付けするために "firewall" と入力します。[Search (検索)] フィールドに「_sourceCategory=firewall」と入力すると、このソースから結果が返ってきます。詳細については、「メタデータの命名規則」を参照してください。
  1. [Advanced (詳細)] で以下のいずれかを設定します。
  • Enable Timestamp Parsing (タイムスタンプ パースの有効化): デフォルトでは、このオプションはオンになっています。オフにすると、タイムスタンプ情報はパースされません。
  • Time Zone (タイム ゾーン): タイム ゾーンには 2 つのオプションがあります。ログ ファイル内のタイム ゾーンを使用できます。その後にタイム ゾーン情報がログ メッセージにない場合のオプションを選択します。または、Sumo Logic がログ内のタイム ゾーン情報を無視するように設定する場合は、タイム ゾーンを強制適用します。どのオプションを選択する場合でも、適切なタイム ゾーンを設定することが重要です。ログのタイム ゾーンを判断できない場合、Sumo はログに UTC を割り当てます。ログの残りの部分が他のタイム ゾーンの場合は、検索結果に影響があります。
  • Timestamp Format (タイムスタンプ フォーマット): デフォルトでは、Sumo はログのタイム スタンプ フォーマットを自動的に検出します。ただし、ソースのタイムスタンプ形式を手動で指定することができます。詳細は、「タイムスタンプ、タイム ゾーン、時間範囲、および日付フォーマット」を参照してください。
  1. 新しいソースには、任意の処理ルールを作成できます。
  2. ソースの設定が完了したら、[保存] をクリックします。

このダイアログに戻って、いつでもソースの設定を編集できます。

ステップ 2: Syslog ソースへの転送設定

インストール済みコレクタに Syslog ソースを設定して、環境内のホストから syslog データを受信するだけでなく、ホストがソースへ syslog データを送信するように設定する必要もあります。この設定を行う手順は、ご使用のオペレーティング システムの syslog エージェントによって異なります。MacOS と Linux にはそれぞれ組み込み syslog エージェントがあります。Windows に組み込み syslog エージェントはありませんが、複数の Windows 用サードパーティ syslog エージェントを使用できます。  

syslog エージェントを設定するには、その設定ファイルを編集します。MacOS または Linux の組み込み syslog エージェントの場合、設定ファイルは通常 /etc/syslog.conf です。他の syslog 実装を使用する場合は、他の設定ファイル名を使用できます。

設定ファイルの各行には 2 つの項目があります。selector は送信するメッセージを指定し、action は一致するメッセージの処理方法を指定します。例:

facility.level    action

  • facility.level はセレクタです。  
    • facility は syslog メッセージ ファシリティです。ファシリティはメッセージを生成したソフトウェアのタイプを指定します。以下はデフォルトの syslog メッセージ ファシリティです。authauthprivdaemoncronftplprkernmailnewssysloguserlocal0 ~ local7
    • level は以下のメッセージの重大度を示します。emergalertcriterrwarnnoticeinfodebug。syslog エージェントは指定された重大度以上のメッセージを送信します。たとえば、auth.crit を指定した場合、重大度が emergalert、および crit のメッセージを承認システムから受信します。特定の重大度のメッセージのみを受信する場合は、重大度の前に等号を追加します (例: auth.=crit)。
  • action はメッセージの処理方法を指定します。アクションにはさまざまなタイプを指定できます。転送設定の場合は、action を使用して、Syslog ソースを設定したコレクタのアドレスを指定します。UDP でメッセージを送信するには、@IP_address のフォーマットを使用します。TCP でメッセージを送信するには、@@IP_address のフォーマットを使用します。Sumo ソース が 514 以外のポートをリッスンするように設定した場合は、@IP_address:port のフォーマットでポートも指定します。

以下の行は、すべてのファシリティの重大度が crit 以上のメッセージを、UDP で IP アドレス 168.191.5.65 のホストのポート 514 へ送信します。  (ポートは指定されていないため、メッセージはデフォルトの syslog ポート (514) に送信されます)。

*.crit @168.191.5.65

以下の行は、すべてのファシリティの重大度が crit 以上のメッセージを、UDP で IP アドレス 168.191.5.65 のホストのポート 514 へ送信します。

*.crit @168.191.5.65:514

以下の行は、auth ファシリティの重大度が crit 以上のメッセージを、UDP で IP アドレス 168.191.5.65 のホストのポート 514 へ送信します。

auth.crit @168.191.5.65:514

以下の行は、auth ファシリティの重大度が crit 以上のメッセージと、ftp ファシリティのすべての重大度レベルのメッセージを TCP で IP アドレス 168.191.5.65 のホストのポート 514 へ送信します。

auth.crit;ftp.* @@168.191.5.65:514

UDP または TCP の選択

syslog ソースを設定する場合、送信プロトコル (TCP または UDP) を選択します。syslog 対応ホストまたはデバイスを TCP または UDP を使用して設定済みの場合は、同じプロトコルを選択します。デバイスのみをセットアップする場合は、TCP を選択することをお勧めします。

TCP には、配信を保証する仕組みがあります。つまり、すべてのログが順序に従って Sumo コレクタに着信し、ログ メッセージがドロップされないように、ネットワーク層が機能します。このプロトコルの欠点は、UDP プロトコルよりもネットワークおよび CPU オーバーヘッドが発生することです。ただし、信頼性保証があるため、ネットワークおよび CPU の使用量に関して、ログ メッセージのボリュームが極端に大きい場合に対処が必要になるような懸念がある場合を除いて、TCP をお勧めします。

コレクタでは、単一行 TCP メッセージが最大 65,535 バイトまでサポートされます。

UDP は配信保証はないストリーミング プロトコルなので、ログ メッセージはドロップされたり、順序が間違って着信したりする可能性があります。ただし、保証がない代わりに、TCP プロトコルで発生するようなネットワークや CPU オーバーヘッドはありません。実際には、ほとんどのネットワークにおいて、UDP はミッション クリティカルな用途でも十分な信頼性がありますが、ネットワーク トラフィックが大量に発生した場合にメッセージがドロップされたり、順序が間違って着信したりすることが考えられます。このリスクを許容できない場合は、TCP を選択します。

RFC 5426 あたり最大 2048 バイトの UDP メッセージがデフォルトでサポートされます。UDP メッセージの長さ制限をデータグラムの最大サイズ (65k) に増やすには、以下の設定を collector/config/collector.properties に追加して、コレクタを再起動します。

collector.syslog.udp.readBufferSize = 65535

変数を使用した sourceCategory の設定

In Collector version 19.216-22 and later, if you have a Docker Logs Source on the same Installed Collector where you are configuring the new Source, you can define the Source Category and Source Host, if the Source supports that field, for the new Source using system environment variables defined on the Collector’s host. To do so, specify the environment variables to include the metadata field in this form:

{{sys.VAR_NAME}}

Where VAR_NAME is an environment variable name, for example:

{{sys.PATH}}

You can use multiple variables, for example:

{{sys.PATH}} - {{sys.YourEnvVar}}

You can incorporate text in the metadata expression, for example:

AnyTextYouWant {{sys.PATH}} - {{sys.YourEnvVar}}

If a user-defined variable doesn’t exist, that portion of the metadata field will be blank.

ネットワーク インターフェイスの指定

複数のネットワーク インターフェイスがあるコンピューターに Syslog ソースを設定する場合、コレクタをバインドするネットワーク インターフェイスを指定できます。このオプションは collector.properties ファイルで設定されます。

ネットワーク インターフェイスを指定するには:

  1. Syslog ソースを設定します。
  2. collector/config/collector.properties に移動します。テキスト エディタでこのファイルを開きます。
  3. syslog.hostname=your_host_name を追加します。your_host_name は使用するネットワーク インターフェイスです。
  4. ファイルを保存し、閉じます。
  5. コレクタを再起動します。

TLS Syslog データ

コレクタでは、Syslog ソースを使用して TLS syslog データを直接受信することはできません。TLS データを受信する仲介サービスをセットアップして、プレーン テキストを Syslog ソースに転送する必要があります。syslog-ng または rsyslog を使用する方法以外に、stunnel があります。https://www.stunnel.org には、「Stunnel は、TLS 暗号化機能をプログラム コードを変更せずに既存のクライアントやサーバに追加するプロキシです。」という記述があります。

https://www.stunnel.org/downloads.html からダウンロードします。または、CentOS/RedHat では以下のコマンドを実行して stunnel をインストールできます。

> yum install stunnel

インストールしたら、ホストでキー/証明書を生成して、以下のような stunnel 設定を使用して syslog データを転送します。

cert = /etc/stunnel/stunnel.pem
sslVersion = SSLv3
chroot = /var/run/stunnel/
setuid = nobody
setgid = nobody
pid = /stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
output = stunnel.log
client = no
[syslog]
accept = 1543
connect = 1514

この例では、受信 TLS 接続のためにホスト ポート 1543/TCP をリッスンします ("accept = 1543")。次に、このプレーン テキスト データをポート 1514/TCP ("connect = 1514") またはコレクタ Syslog 設定で定義したポートへ、ループ バックで転送します。

Stunnel と使用可能な設定オプションの詳細については、https://www.stunnel.org/docs.html を参照してください。

デフォルトで IPv4 を使用する

JVM がデフォルトで IPv4 を使用するように設定するには、Wrapper 設定ファイルに省略可能な Java パラメータを追加します。

  1. /Sumo Logic Collector/config/wrapper.conf を開いて 69 行目、"# Java Additional Parameters" で以下を実行します。
  2. 以下の行を追加します。

wrapper.java.additional.3=-Djava.net.preferIPv4Stack=true

  1. ./collector restart を使用して、コレクタを再起動します。

または、以下の手順で IPv6 を完全に無効にします。

  1. 以下のコマンドを使用してファイルにアクセスします。

sudo gedit /etc/sysctl.conf

  1. ファイルの終わりに以下の行を追加します。

# IPv6 disabled
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

3.以下のコマンドを実行して sysctl 設定をリロードします。すぐに変更内容が適用されます。 

sysctl -p.

Syslog ソースのトラブルシューティング

データが syslog ソースに取り込まれない場合、ファイアウォール ルールを追加して、コレクタがリッスンするポートへの受信トラフィックの許可が必要になることがあります。 

以下のステップを使用して問題を特定します。

  1. netstat を使用して、Sumo がポートをリッスンしていることを確認しますSyslog ソースを設定したら、"netstat -nap" の出力の設定ポートにリッスン プロセスが存在するかどうかをコレクタ ホストで確認します。設定済みプロトコル (TCP/UDP) とポートでリッスンする Sumo プロセスがない場合、他のプロセスがポートを使用しているため Sumo プロセスがポートにバインドされなかった可能性があります。この場合、コレクタ ログ メッセージは、Sumo プロセスがポートのバインドに失敗したことを示します。

  2. netcat を使用して、テスト メッセージをプッシュします。netcat を使用しチャット セッションでデータをポートにプッシュします。Netcat は、TCP および UDP ソケットからの読み書きに使用できるシンプルなインターフェイスを備えたネットワーク ユーティリティです。Netcat はデフォルトではインストールされません。http://nmap.org/ncat からダウンロードできます。コマンド例を以下に示します。コレクタが動作するホストでコマンドを実行する場合は、"<ip_address>" を "localhost" に置き換えます。

    以下の例では、Windows で TCP 経由のメッセージをテストします。

ncat.exe -v <ip_address> 1514

     以下の例では、Windows で UDP 経由のメッセージをテストします。

ncat.exe -vu <ip_address> 1514

     以下の例では、Linux で TCP 経由のメッセージをテストします。

nc -v <ip_address> 1514

     以下の例では、Linux で UDP 経由のメッセージをテストします。

nc -vu <ip_address> 1514

  1. 次のようにテスト メッセージの取り込みを確認し、タイムスタンプの問題を確認します。Sumo [Search (検索)] ページで、チャット インターフェイスでプッシュしたデータが使用できるかどうかを確認します。 

Sumo [Search (検索)] ページでメッセージが使用できる場合、Syslog ソースは適切に動作しています。この場合の問題は、送信元 Syslog クライアントまたはロード バランサーから Syslog が設定されたポートにデータが到達していない可能性があります。

また、[Search (検索)] ページの [Start (開始)] ボタンの横にある [Use Receipt Time (受信時間の使用)] チェックボックスをオンにします。Syslog ソースはデフォルトでは UTC 時間を使用するように設定されています。テスト メッセージにはタイムスタンプがないので、ログが UTC 時間と解釈され、検索にはデフォルトの [Last 15 Minute (最近 15 分間)] 期間内の結果が表示されません。

  1. テスト メッセージは取り込まれますが、ソースからのデータは取り込まれない場合は、ファイアウォールの問題を確認します。コレクタが動作するローカル ホストからプッシュした ncat データは取り込まれて、リモート ホストからプッシュされた ncat データは取り込まれない場合、ファイアウォール ルールが原因でコレクタが動作するホストで外部データが受信されない (ホストでできてもプロセスで受信できない場合もあります) ためと考えられます。ファイアウォール ルールを追加 (場合によっては、ファイアウォール例外を削除) して、コレクタがリッスンするポートで受信トラフィックを許可することが必要な場合があります。

  2. すべて正常でもデータが取り込まれない場合、データの CR LF を確認します。Syslog データにキャリッジ リターンや LineFeed 文字 (CR LF または \r \n) がない場合、接続をリッスンし、行末文字が見つかるまで待機してタイムアウトになるため (通常のタイムアウトは 2 秒)、コレクタ ログに以下のメッセージが記録されます。syslog データに CR LF が含まれていることを確認して、修正します。

2017-05-07 17:20:08,293 -0500 [Thread-2875] ERROR com.sumologic.scala.collector.input.syslog.EventInput - Received event: Exception. server com.sumologic.scala.collector.input.syslog.TCPSyslogServer@45424f69, socketAddress /172.21.36.28:60097 java.net.SocketTimeoutException: Read timed out