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

クラウド Syslog ソース

syslog クライアントが RFC 5424 準拠のメッセージを Sumo に送信できるようにクラウド syslog ソースを設定できます。Sumo によって生成されたソース固有のトークンは、ソースを識別するために各メッセージに挿入されます。TCP でのトランスポート層セキュリティ (TLS) 1.2 が必要です。

Sumo では、syslog サーバの柔軟なスケーリング セットを管理でき、一連の AWS Elastic Load Balancer の背後で拡張および縮小が可能です。AWS ELB セットも、拡大および縮小できます。このため、Sumo では IP アドレス ベースのエンドポイントではなく、次の形式のエンドポイント ホスト名が使用されます。

syslog.collection.YOUR_DEPLOYMENT.sumologic.com

上の YOUR_DEPLOYMENTaudeeujp us1、または us2 になります。エンドポイントについての詳細は、ここを参照してください。

以下の手順では、Sumo でクラウド syslog ソースを設定します。これにより、Sumo Logic トークンとエンドポイントのホスト名が生成されます。次に、サーバに証明書をダウンロードして TLS をセットアップします。

Sumo Logic では、syslog-ng や rsyslog などの syslog クライアントがサポートされています。使用しているサーバで syslog データを送信するように設定するには、以下の該当するセクションの手順に従ってください。syslog データが Sumo Logic に表示されない場合は、以下のトラブルシューティングを参照してください。

クラウド Syslog ソースの設定

クラウド syslog の設定には、クラウド syslog ソースを設定するときに自動的に生成されるトークンが必要です。Sumo ではこのトークンによって、ログ メッセージを他の顧客のログメッセージと区別できます。トークンは、ソースに関連付けられ、特定のユーザには関連付けられません。 

Sumo Logic に送信されるすべての syslog メッセージにトークンを構造化 ID として含めます。トークンは Sumo Logic によって取得時に削除され、検索結果の syslog メッセージに含まれません。

ソースを削除すると、トークンが削除されます。トークンを変更するには、次の手順に従って [Regenerate Token (トークンの再生性)] オプションを使用します。

クラウド Syslog ソースを設定するには、次の手順を実行します。

  1. Sumo Logic で [Manage Data (データの管理)] > [Collection (コレクション)] > [Collection (コレクション)] を選択します。
  2. [Collection (コレクション)] ページで、ホスト型コレクタの横の [Add Source (ソースを追加)] をクリックします。  ホスト型コレクタの追加については、「ホスト型コレクタをセットアップする」を参照してください。
  3. [Cloud Syslog (クラウド Syslog)] を選択します。
  4. Sumo でこのソースに表示する名前を入力します。必要に応じて説明を入力します。
  5. (省略可能) [Source Host (ソース ホスト)][Source Category (ソース カテゴリ)] に、このソースから収集された出力にタグを付けるために、任意の文字列を入力します (カテゴリ メタデータは _sourceCategory という検索可能なフィールドに格納されます)。
  6. [Advanced (詳細)] で以下のいずれかを設定します。
  • Enable Timestamp Parsing (タイムスタンプ パースの有効化): デフォルトでは、このオプションはオンになっています。オフにすると、タイムスタンプ情報はパースされません。
  • Time Zone (タイム ゾーン): タイム ゾーンには 2 つのオプションがあります。ログ ファイル内のタイム ゾーンを使用できます。その後にタイム ゾーン情報がログ メッセージにない場合のオプションを選択します。また、特定のタイム ゾーンを強制することができ、この場合ログ内にあるタイム ゾーン情報は完全に無視されます。どのオプションを選択した場合も、適切なタイムゾーンを設定することが重要です。ログのタイム ゾーンを特定できない場合、UTC タイム ゾーンが割り当てられます。残りのログが別のタイムゾーンからのものである場合は、検索結果に影響します。
  • Timestamp Format (タイムスタンプ フォーマット): デフォルトでは、Sumo はログのタイムスタンプ フォーマットを自動的に検出します。ただし、ソースのタイムスタンプ形式を手動で指定することができます。「タイムスタンプ、タイム ゾーン、時間範囲、および日付フォーマット」を参照してください。
  1. 新しいソースに必要な処理ルールを作成します。
  2. [Save (保存)] をクリックします。
    cloudsyslog02.png

    トークン情報は、以下に示す読み取り専用のダイアログ ボックスに表示されます。
    syslog-token.png
     
  3. syslog クライアントで使用する情報をコピーするには、[Copy (コピー)] をクリックします。この情報が次の形式でコピーされます。

    Token: 9HFxoa6+lXBmvSM9koPjGzvTaxXDQvJ4POE/WCURPAo+w4H7PmZm8H3mSEKxPl0Q@41123, Host: syslog.collection.YOUR_DEPLOYMENT.sumologic.com, TCP TLS Port: 6514

    トークン内の番号 41123 は、Sumo プライベート エンタープライズ番号 (PEN) です。トークンを含める方法は 2 つあり、構造化されたデータ フィールドまたはメッセージ本文に含めることができます。 

    次の例では、トークンは構造化されたデータ フィールド内にあります。 

    <165>1 2015-01-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [YOUR_TOKEN] msg

    次の例では、トークンは構造化されたメッセージ本文内にあります。

    <165>1 2015-01-11T22:14:15.003Z mymachine.example.com evntslog - ID47 - YOUR_TOKEN msg
  4. ソースを設定した後、[Collectors and Sources (コレクタとソース)] ページからこれらのトークンを操作できます。
  • クラウド syslog ソースのトークンは、[Show Token (トークンの表示)] をクリックすることでいつでも表示できます。 
    showtoken.png
  • 新しいトークンを生成する必要がある場合は、[Regenerate Token (トークンを再生性)] をクリックします。
    regentoken.png

TLS のセットアップ

トランスポート層セキュリティ (TLS) をセットアップします。

DigiCert 証明書を https://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt からダウンロードします。

syslog-ng

syslog-ng の場合は証明書を設定ディレクトリに置きます。syslog-ng クライアントが、そのディレクトリから処理のために証明書を取得します。DigiCert 証明書をセットアップするには、次のステップを実行します。

$ cd /etc/syslog-ng/ca.d
$ wget -O digicert_ca.der https://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt
$ openssl x509 -inform der -in digicert_ca.der -out digicert_ca.crt
$ ln -s digicert_ca.crt `openssl x509 -noout -hash -in digicert_ca.crt`.0

rsyslog

DigiCert 証明書をセットアップするには、次のステップを実行します。

$ cd /etc/rsyslog.d/keys/ca.d
$ wget -O digicert_ca.der https://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt
$ openssl x509 -inform der -in digicert_ca.der -out digicert_ca.crt

syslog-ng を使用したクラウド syslog ソースへのデータの送信

syslog-ng を初めて使用する場合は、このリンクから syslog-ng をインストールしてください。 

このセクションでは、syslog-ng を使用する syslog クライアントを設定する方法を示します。syslog-ng は、Sumo クラウド syslog サービスで受信される syslog メッセージを送信します。テンプレート、宛先、およびソースを指定する必要があります。 

テンプレートは、Sumo の正しい形式で定義してください。メッセージが受け入れられるためには、次の形式にする必要があり、$ フィールドの順序は次の記述のとおりにする必要があります。

template t_sumo_syslog {
    template("<$PRI>1 $ISODATE $HOST $PROGRAM $PID $MSGID [E5kTyaEcth45/DU81M236oU4vM8j1ZaqTpWgjXB6lod7cFTeq09zzMn5ErmM0O/3@41123] $MSG\n"); template_escape(no);
 };

サンプルのトークン E5kTyaEcth45/DU81M236oU4vM8j1ZaqTpWgjXB6lod7cFTeq09zzMn5ErmM0O/3@41123,
を実際のトークンで上書きします。

Sumo エンドポイントに使用する宛先を定義します。次の TCP の宛先オプションの例では、エンドポイント (syslog.collection.YOUR_DEPLOYMENT.sumologic.com) と TCP TLS ポート 6514 を指定しています。CA 証明書の ca-dir も含まれています。最後の項目では、信頼できる証明書だけがリモート エンドポイントへの接続で受け入れられるように指定されています。

destination d_sumo_tls {
    tcp("syslog.collection.YOUR_DEPLOYMENT.sumologic.com"
        port("6514")
        template(t_sumo_syslog)
        tls(
            ca-dir("/etc/syslog-ng/ca.d")
            peer_verify("required-trusted")
        )
    );
};

syslog の destination オプションを使用する場合の例を次に示します。参考として、syslog-ng オープンソース ドキュメントの 「syslog() destination options」を参照してください。トークンは、syslog destination の構造化データ フィールドではなく、メッセージ本文に含める必要があります。

destination d_sumo_tls {
    syslog("syslog.collection.YOUR_DEPLOYMENT.sumologic.com"
        port("6514")
        template(t_sumo_syslog)
        transport(tls)
        tls(
            ca-dir("/etc/syslog-ng/ca.d")
            peer_verify("required-trusted")
        )
    );
};

Sumo の出力先に送信するログを指定します。この例では、既存の syslog-ng ソース (s_sys) を指定し、syslog-ng フィルタ (f_default) を適用して、Sumo Logic エンドポイント (d_sumo_tls) の使用方法を指定します。

log {
    source(s_sys);
    filter(f_default);
    destination(d_sumo_tls);
};

rsyslog を使用したクラウド syslog ソースへのデータの送信

このセクションでは、rsyslog を使用する syslog クライアントを設定する方法を示します。rsyslog は、Sumo Logic クラウド syslog サービスで受信する syslog メッセージを送信します。rsyslog を初めて使用する場合は、この rsyslog のドキュメントに従ってインストールしてください。

rsyslog をインストールしたら、設定ファイルを編集して Sumo へのログ送信を開始します。設定ファイルはデフォルトで /etc/rsyslog.conf にあります。 

rsyslog v7 以前

# Setup disk assisted queues
$WorkDirectory /var/spool/rsyslog         # where to place spool files
$ActionQueueFileName fwdRule1             # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g               # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on             # save messages to disk on shutdown
$ActionQueueType LinkedList               # run asynchronously
$ActionResumeRetryCount -1                # infinite retries if host is down

# RsyslogGnuTLS
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/digicert_ca.crt
$ActionSendStreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer syslog.collection.YOUR_DEPLOYMENT.sumologic.com

template(name="SumoFormat" type="string" string="<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msgid% [YOUR_TOKEN] %msg%\n")

*.* action(type="omfwd" protocol="tcp" target="syslog.collection.YOUR_DEPLOYMENT.sumologic.com" port="6514" template="SumoFormat")

template ステートメントでは、必ず YOUR_TOKEN を実際のトークンに置き換え、YOUR_DEPLOYMENT を実際のデプロイに置き換えます。文字列内のプロパティでは、先頭と末尾に '%' を付けます。他のすべてのテキストと空白は、表記どおりに認識されます。rsyslog の設定の詳細については、rsyslog テンプレートのドキュメントまたは rsyslog omfwd のドキュメントを参照してください。

rsyslog v8 以降

# Setup disk assisted queues# Setup disk assisted queues
$WorkDirectory /var/spool/rsyslog     # where to place spool files
$ActionQueueFileName fwdRule1         # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g           # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on         # save messages to disk on shutdown
$ActionQueueType LinkedList           # run asynchronously
$ActionResumeRetryCount -1            # infinite retries if host is down

# RsyslogGnuTLS
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/digicert_ca.crt

template(name="SumoFormat" type="string" string="<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msgid% [YOUR_TOKEN] %msg%\n")

action(type="omfwd"
    protocol="tcp"
    target="syslog.collection.YOUR_DEPLOYMENT.sumologic.com"
    port="6514"
    template="SumoFormat"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="syslog.collection.*.sumologic.com")

template ステートメントでは、必ず YOUR_TOKEN を実際のトークンに置き換え、YOUR_DEPLOYMENT を実際のデプロイに置き換えます。文字列内のプロパティでは、先頭と末尾に '%' を付けます。他のすべてのテキストと空白は、表記どおりに認識されます。rsyslog の設定の詳細については、rsyslog テンプレートのドキュメントまたは rsyslog omfwd のドキュメントを参照してください。

メッセージの形式

syslog メッセージは RFC 5424 に準拠した形式で記述する必要があり、準拠していない場合は削除されます。サイズが 64KB を超えるメッセージは、余剰部分が削除されます。

次の図は、RFC 5424 形式を示しています。

Cloud Syslog - RFC 5424.png

既知の問題

TCP 接続は、待機状態のタイムアウトを 60 分に設定した Amazon Elastic Load Balancer (ELB) を経由します。接続が 60 分以上待機状態になると、ELB によって接続が閉じられます。syslog クライアントが待機状態のタイムアウト後に接続を再確立しようとしたときに、いくつかのメッセージが消失する可能性があります。

rsyslog には、次の設定パラメーターが提供されており、データの損失を最小限に抑えることができます。

$ActionResumeRetryCount 1 # Reconnect but misses the first message after connection is idle for an hour.
$RebindInterval 1 #Establish a new connection every message. Change 1 to another number N so a new connection gets used every N messages.

トラブルシューティング

問題が発生した場合は、以下の手順に従って最初に Sumo サービスの接続を確認し、次にクライアント設定が正しいことを確認してください。

Sumo サービスとの接続の確認

Sumo サービスが syslog メッセージを受信できることを確認するには、TLS をサポートする nMap.org の ncat などのネットワーク ユーティリティを使用して、syslog ポートがメッセージを受け入れることを確認します。 

$ ncat --ssl syslog.collection.YOUR_DEPLOYMENT.sumologic.com PORT

ここで、YOUR_DEPLOYMENT は、使用しているデプロイと置き換えます。例:

$ ncat --ssl syslog.collection.us2.sumologic.com 6514

次に、テストメッセージを入力します。次に例を示します。

<165>1 2017-10-24T06:00:15.003Z mymachine.example.com evntslog - ID47 - YOUR_TOKEN This is a message

ここで、YOUR_TOKEN は、上記のクラウド Syslog ソースを作成したときに Sumo によって生成されたトークンと置き換えます。

クライアント設定の検証

syslog-ng または rsyslog の設定に関するドキュメントに従っても、Sumo Logic にデータが表示されない場合は、次の手順に従ってトラブルシューティングを行ってください。

  1. クラウドの syslog トークンが、有効で、「@41123」の記述があり、メッセージの正しい場所 (構造化データフィールドまたはメッセージ本文内) に位置することを確認します。
  2. 設定を変更するたびに、syslog クライアントを再起動します。

$ sudo service rsyslog restart
または
$ /etc/init.d/syslog-ng restart

  1. syslog クライアントが実際にデータソースからデータを受信していることを確認します。
  2. ファイアウォール ルールによってパケットがブロックされていないことを確認します。
  3. アカウントがスロットリングされていないことを確認します。
  4. tcpdump を実行して、パケットが双方向に送信されていることを確認します。

$ sudo tcpdump host syslog.collection.YOUR_DEPLOYMENT.sumologic.com
    
出力は次のようになります。

TLS ハンドシェイクの場合:

21:53:08.005676 IP client-host.client-port > server-host: Flags [S], seq 471724626, win 26883, options [mss 8961,sackOK,TS val 523109896 ecr 0,nop,wscale 7], length 0

21:53:08.006321 IP server-host > client-host.client-port: Flags [S.], seq 3885139041, ack 471724627, win 28960, options [mss 1460,sackOK,TS val 112542097 ecr 523109896,nop,wscale 8], length 0

21:53:08.006349 IP client-host.client-port > server-host: Flags [.], ack 1, win 211, options [nop,nop,TS val 523109896 ecr 112542097], length 0 ...

データ送信の場合:

21:46:35.954790 IP client-host.client-port > server-host: Flags [P.], seq 471728183:471728572, ack 3885141774, win 256, options [nop,nop,TS val 523153927 ecr 112585055], length 389

21:46:35.955326 IP server-host > client-host.client-port: Flags [.], ack 389, win 181, options [nop,nop,TS val 112586129 ecr 523153927], length 0 ...

  1. 上記の手順で問題が解決しない場合は、特定のコレクタとソースのセットアップに関する情報を含むサポート ケースを提出してください。tcpdump がある場合には、そのデータも併せて提出してください。
  • この記事は役に立ちましたか?