読者です 読者をやめる 読者になる 読者になる

designetwork

ネットワークを軸としたIT技術メモ

BIG-IPでX-Forwarded-Protoを付与する設定

f:id:daichi703n:20170514162355p:plain

F5 BIG-IPでHTTP/Sの負荷分散をする際に、S-NATした上でX-Forwarded-Proto, X-Forawarded-ForのHTTPヘッダを付与する設定をする。

なお、今回の設定方法はこちらのディスカッションの情報を元にしている。

devcentral.f5.com

検証構成

検証バージョン: F5 BIG-IP VE 13.0.0 (Build 0.0.1645)

f:id:daichi703n:20170514162414p:plain

MacBookでWebサーバ(Rails)を起動し、Webブラウザ(Chrome)からBIG-IPのVirtual Server経由で自身にアクセスする。このとき、正常に通信ができるようS-NATを有効化しておく。

設定と動作確認

基本的な設定はこちらの通り。Rails向けのNode, Poolを設定した上でVirtual Serverを作成し割り当てる。通常のHTTPで試験するため種類(Type)はPerformance(HTTP)を使用する。

f:id:daichi703n:20170514164330p:plain

パケットはこちらの通り。

f:id:daichi703n:20170514164404p:plain

IPアドレスは以下の通り。キャプチャはPCで取得しているため、Client(Chrome)->Virtual Server, S-NAT->Server(Rails)のパケットが見える。

Client: 192.168.1.102
Server: 192.168.1.102
Vertual Server: 192.168.1.91
S-NAT Address: 192.168.1.8

ここではX-Forwarded-Proto(XFP), X-Forwarded-For(XFF)のいずれも付与されていない。

X-Forwarded-Proto, X-Forawarded-Forを付与する

HTTPヘッダにXFF, XFPを追加するよう、Profileを作成する。

Local Traffic > Profiles > Protocols > Fast HTTP

f:id:daichi703n:20170514164928p:plain

HTTP関連の設定欄で、Insert X-Forwarded-For: Enabled, Request Header Insert: X-Forwarded-Proto: httpと設定する。 f:id:daichi703n:20170514165706p:plain

作成したプロファイルをVirtual Serverに適用する。

f:id:daichi703n:20170514165855p:plain

適用後はコネクションが残存していることがあるため、必要に応じてNodeのOffline/Online等でクリアする。

改めてHTTPアクセスすると、以下の通りHTTPヘッダにX-Forwarded-For, X-Forwarded-Protoが追加されている。

f:id:daichi703n:20170514165913p:plain

HTTPSは適用プロファイルを変更

上記はperformance(http)での適用方法を記載した。HTTPS(SSL)等で適用する際には、使用するプロファイルを合わせて同様に設定すればよい。

通常のHTTPプロファイルを使用する場合は場所は違うが同様にRequest Header InsertでXFPヘッダを設定する。

f:id:daichi703n:20170514170156p:plain

X-Forwarded-Portは?

X-Forwarded-Protoの他に、X-Forwarded-Portを付与したいケースもあるかもしれない。残念ながら、こちらについてはiRulesでの指定が必要となる。

devcentral.f5.com

GUIで変数指定しても展開されず、動的に情報を取得できなかった。

まとめ - BIG-IPでX-Forwarded-Protoを付与する設定

HTTPプロファイルを作成することで、S-NAT環境でHTTPヘッダにX-Forwarded-Protoを付与した。なお、X-Forwarded-Portを付与したい場合にはiRulesを使用する必要がある。

postNFCData failedのエラーでBIG-IP VEがESXi6.5にデプロイできない

f:id:daichi703n:20170507154512p:plain

評価版使用のためにF5 BIG-IP VE(Virtual Edition)をVMware ESXi6.5にデプロイしようとしたがエラーが発生してデプロイに失敗した。結果として、ALL, LTMのOVAイメージはデプロイできず、1SLOTのモデルでデプロイに成功した。

発生事象

ESXi Web ClientからOVAイメージをデプロイしたときにこちらの通りエラーが発生した。後述するが、ESXiホストのスペックには余裕があったので、ALLのモデルを使用している。

f:id:daichi703n:20170507144206p:plain

postNFCData failed: Capacity of uploaded disk is larger than requested

DISK容量不足のメッセージだが、私の環境では900GB程度の空き容量があるため、システム要件等を踏まえて問題ない。

f:id:daichi703n:20170505213310p:plain

前提環境

以下の環境で試験している。

クライアント バージョン: 1.18.0
クライアント ビルド番号: 5270848
ESXi バージョン: 6.5.0
ESXi ビルド番号: 5310538

RAM: 8 GB / DISK: 1 TB

ESXiのUIバージョンなどが低い場合はこちらの通りアップデートください。

designetwork.hatenablog.com

デプロイ手順はESXi Web Clientから 新規仮想マシン > OVA/OVFテンプレートと通常通りデプロイする。

F5 BIG-IP VEモデルとバージョン

なお、互換性はこちらの通り。VE13.0.0はESXi6.5で使用可能となっている。

AskF5 | Manual: Virtual Edition and Supported Hypervisors Matrix

BIG-IP VE版のダウンロードはこちらから(要F5アカウント登録・誰でも登録可能)

https://downloads.f5.com/esd/index.jsp

BIG-IP > BIG-IP v13.x / Virtual Edition > Virtual-Edition とパスを辿るとダウンロードファイルの一覧が表示される。ここでESXを検索(ブラウザで)すると次の3種類が見つかる。(バージョンは2017/5/7時点の情報)

  • BIGIP-13.0.0.0.0.1645.ALL-scsi.ova
  • BIGIP-13.0.0.0.0.1645.LTM-scsi.ova
  • BIGIP-13.0.0.0.0.1645.LTM_1SLOT-scsi.ova

OpenStackのドキュメントでかつ一世代前の情報にはなるが、それぞれの役割はこちらに記載されている。

BIG-IP® VE Flavor Requirements — F5 OpenStack Documentation

ざっくりとHWスペックで分かれており、1SLOT: Small, LTM: Medium, ALL: Largeという こちらのスループットライセンスのCPU上限と合わせてHWスペックを選定する。

K14810: Overview of BIG-IP VE license and throughput limits - AskF5

各イメージのDISKサイズはこちらの通り。

K14946: Overview of BIG-IP Virtual Edition image sizes - AskF5

システム要件として、CPUは1SLOT/LTM: 2vCPU or ALL: 4vCPU、RAMはCPUあたり2GBとなっている。

K15796: Hardware requirements on the system hosting BIG-IP Virtual Edition - AskF5

VEモデル別のデプロイ可否

システム要件的には問題はないが、検証として各モデルのデプロイを実施した。結果は以下の通り。

VEモデル デプロイ可否
BIGIP-13.0.0.0.0.1645.ALL X
BIGIP-13.0.0.0.0.1645.LTM X
BIGIP-13.0.0.0.0.1645.LTM_1SLOT O

最小の1SLOTモデルであればデプロイすることができた。

f:id:daichi703n:20170507150455p:plain

2vCPU, RAM 4GB, DISK 8GBで動作している。

f:id:daichi703n:20170507151027p:plain

f:id:daichi703n:20170507151040p:plain

あとはコンソール・SSH・WebGUIから通常通りBIG-IP VEが使用できる。

旧BIG-IPバージョン・ESXiバージョンでの切り分け

VEモデル デプロイ可否
ESXi5.5 ALLデプロイ O
ESXi6.5 BIG-IP v12 ALLデプロイ X

ESXi側を疑って、ESXi5.5.0(1623387)でもデプロイしてみた。こちらはBIGIP-13.0.0.0.0.1645.LTM-scsi.ova問題なくデプロイできた。そのため、BIG-IP VEではなくESXi6.5の問題と考えられる。

また、ESXi5.5ではOVAデプロイ時に仮想マシンのvCPU, RAMを選択できる。

f:id:daichi703n:20170507150021p:plain

なお、BIG-IP v13の問題を疑ってv12のBIG-IP VEをESXi6.5にデプロイしてみたが、こちらは上記と同様のエラーとなりデプロイできなかった。また、ESXi6.5においてはオプションはNWの設定のみで、VMのリソース選択はできない。

f:id:daichi703n:20170507150719p:plain

まとめ - postNFCData failedのエラーでBIG-IP VEがESXi6.5にデプロイできない

ESXi6.5では、postNFCData failed: Capacity of uploaded disk is larger than requestedのエラーにより、F5 BIG-IP VE(Virtual Edition) のALL及びLTMモデルがデプロイできない。BIG-IP VEを使用したい場合は1SLOTの最小モデルを使用する必要がある。

4台のHDDで2組のRAID1を構成しESXiマウントする(PowerEdge T110ⅡPERC H200A)

f:id:daichi703n:20170505215401p:plain

自宅サーバとして使用しているDell PowerEdge T110ⅡにHDDを追加する。既存DISKは初期搭載のRAIDコントローラPERC H200Aを使用し、RAID1構成となっている。コントローラには最大4台のHDDを接続できるため、残りの2台を追加し同様にRAID1で増設する。

自宅サーバ選定はこちら。

designetwork.hatenablog.com

RAIDコントローラ

元々搭載されているRAIDコントローラはこちら。この中のPERC H200A (PowerEdge RAID Controller)というモデルのようだ。

www.dell.com

基本的な操作マニュアルはこちらに記載されている。

SAS 5/6およびPERC H200シリーズにおけるRAID BIOS操作一覧 - Dell

なお、こちらのRAIDコントローラは最大4台のHDDを接続できるものの、RAID1 * 2組 の構成ができるかの情報は事前には見つけられなかった。4台はRAID10構成用?という懸念もなった。ただ、失って困るデータもないので、実機でそのまま検証した。

RAID設定モードで新規RAID作成

まずはBIOS起動画面でCtrl+CによりRAID設定モードに入る。起動直後なので逃さないよう注意する。

f:id:daichi703n:20170505210447j:plain

その後、RAID PropertiesからCreate Newで新規RAIDを作成し、新規DISKを所属させる。(序盤の画面を撮り忘れていました…)

RAID作成後は、このように新規DISKのDrive StatusがRAIDになる。写真の0, 1が既存HDDで、今回は2, 3のHDDを増設している。

f:id:daichi703n:20170505210959j:plain

一見、既存のRAIDに追加されてRAID10になっている?というようにも感じたが、View Volumeで見ると1 of 2として新規作成分が認識されていることが分かる。追加分が1番目になっているのは若干不思議。

f:id:daichi703n:20170505211252j:plain

Alt+NでRAID情報のページを送れる。

f:id:daichi703n:20170505211255j:plain

なお、状態を確認する上ではSAS Topologyから確認するのが一番分かりやすかった。以下のように表示され、RAID1のペアが2組作成されていることが見て取れる。

f:id:daichi703n:20170505211339j:plain

なお、このときBoot Deviceの選択を誤らないように注意。OS(私の環境はVMware ESXi6.5)がインストールされているRAIDをBoot Deviceとして指定していないと、サーバを起動できなくなる。

VMware ESXi6.5にマウントする

新規RAIDを構成できたので、ESXiに取り込む。ESXi Web Clientでデータストアの追加をする。

f:id:daichi703n:20170505212559p:plain

「新しいVMFSデータストアの作成」を選択して次へ

f:id:daichi703n:20170505212652p:plain

新規作成したRAIDを認識できている。データストア名を入力して次へ

f:id:daichi703n:20170505212737p:plain

私はここで一度つまづいた。「パーティション分割オプションの選択」のステップでロードしています…のまま停止してしまった。

f:id:daichi703n:20170505212920p:plain

数分待っても進まないため、「次へ」をクリックして強制的に進めたらエラー終了…。気を取り直してもう一度最初から設定したら、今度は正常に表示された。

f:id:daichi703n:20170505213027p:plain

全容量を一つのパーティションとして使用する。物理で分けてしまうと扱いづらい部分があるため、パーティション分けは仮想マシン側で実施する。なお、ESXi6.5からは新しいVMFS6を使用できるようになっている。しかし、私はもう一台のESXi5.5からの移行等を考慮して、VMFS5で作成した。

f:id:daichi703n:20170505213310p:plain

完了して新規データストアを使用可能になった。

まとめ - PowerEdge T110Ⅱ(PERC H200A) 4台のHDDで2組のRAID1を構成しESXiマウントする

PowerEdge T110ⅡのRAIDコントローラ PERC H200A で、4台のHDDで2組のRAID1を構成することができた。また、新規RAIDVMware ESXi6.5のデータストアとして取り込むことができた。

ESXi6.5 Web ClientからVIBでパッチ適用する

f:id:daichi703n:20170505005750p:plain

VMwareでは各メジャーバージョンの中で随時パッチがリリースされている。従来、vCenterがないスタンドアロン環境ではesxcliによりVIB (VMware Infrastructure Bundle)をインストールする必要があった。しかし、ESXi6.5ではスタンドアロンで使用可能なWebGUIが搭載されているため、通常使用の管理画面から簡単にインストールすることができる。

なお、今回はGoogle ChromeからESXi Web Clientへのログイン時のエラーの対応としてesx-uiのパッチを適用する。なお、私の環境ではエラーが出てもF5更新すればエラーを抜けられた。

VIBをダウンロードする

VIB(パッチ)はMy VMwareからダウンロードできる。(要ログイン)

VMware patch portal

KBのバグ修正情報等を参考に該当するパッチをダウンロードする。

f:id:daichi703n:20170504234515p:plain

期待していたのは、Yum等のパッケージ管理のように、オンラインのリポジトリ(Depot)にアクセスしてアップデートするような動作だった。しかし、リポジトリは見つけられずローカルにダウンロードするしかないようだ。

ZIPファイルのままではNG

ダウンロードしたVIBはZIP形式で圧縮されている。残念ながらそのままではWeb Clientからはインポートできない。手順は以下の通り。

データストアにZIPファイルをアップロードする。アップロードしたパスを控えておく。

f:id:daichi703n:20170504234557p:plain

ストレージ情報からベースのパスを取得する。表示は短縮されているが、トリプルクリックで非表示部分を含め取得できる。

f:id:daichi703n:20170504235132p:plain

ホスト > 管理 > パッケージ > アップデートのインストールからインストールする。

f:id:daichi703n:20170504235836p:plain

先ほどのファイルパスを加えてフルパスで指定する。

f:id:daichi703n:20170504235352p:plain

後述するが、VIB単体でのバージョンアップはVMwareとしてのサポート対象外となってしまう。私の場合は個人的な検証利用なので問題ない。

このホストが VMware Update Manager によって管理されている場合、更新を実行するとホストが非準拠になる場合があります。続行しますか?

f:id:daichi703n:20170505001032p:plain

エラーになる…

! アップデートを適用できませんでした: アップデートが指定された形式ではありません。VIB ファイルへのパスまたは URL を指定してください。

f:id:daichi703n:20170505001211p:plain

メッセージより、ZIP形式ではダメなのだろう。

VIBファイルを取り出す

ダウンロードしたZIPファイルにはVMwareのindex情報などとともに各種VIBファイルが含まれている。内容はこのような感じ。

f:id:daichi703n:20170505002911p:plain

ZIPファイルを解凍してVIBファイル単体をアップロードする。

f:id:daichi703n:20170505002244p:plain

f:id:daichi703n:20170505003120p:plain

数秒でアップデートが完了する。(完了メッセージは撮り忘れ…)

f:id:daichi703n:20170505003218p:plain

esx-uiがバージョンアップされた。1.8.0 -> 1.18.0

Web Client からの運用は非現実的

パッチ適用作業をしてみて、正直なところ、ESXi Web Client (GUI) からのVIBインストール運用は実用に耐えないと感じている。また、VMwareのサポートを受けられなくなる点もデメリットと考えられる。

運用ハードルを下げるためにWeb GUIからの作業を実施したが、結局個別のVIBを選定したりと、それなりの知識が求められる。また、そもそもESXiを運用する人は前提知識とスキルがあるはずなので、CLIからコマンドでアップデートする方が効率も良さそうだ。

ちょうど同時期に同様の問題でパッチ適用をされている方がいらっしゃいました。こちらの手順を参考にCLIからVIB一色のインストール作業をしようと思います。

japan-vmware.hateblo.jp

まとめ - ESXi6.5 Web ClientからVIBでパッチ適用する

ESXi6.5 Web ClientからVIBのパッチを適用できた。一連の作業を実施したものの、結果としてWeb GUIからのパッチ適用作業はメリットが少なく、従来通りCLIでアップデートする方が良さそうだ。

Logstashで内容ごとに送信先を複数に振り分ける設定

f:id:daichi703n:20170410024520p:plain

Logstashでは設定したConfigは全体的に有効になるため、シンプルな設定では単一の出力設定となる。そこで、ifで項目により条件分岐させることで、複数の出力を設定できる。

前回こちらの記事で紹介した汎用的な設計を元に、Logstashからの送信先を複数に分散、振り分ける設定を追加する。

Logstashの設定

  • input/filter

inputのConfigファイルはこちらのとおり。syslog系のログをモニタリングして収集する。tagsにより、Fluentd(td-agent)と同様の処理を実装する。

/etc/logstash/conf.d/messages.conf

input {
  file {
    path => "/var/log/messages"
    tags => ["sys", "logstash_messages", "%{host}" ]
    type => syslog
  }
  file {
    path => "/var/log/cron"
    tags => ["sys", "logstash_cron", "%{host}" ]
    type => syslog
  }
  file {
    path => "/var/log/secure"
    tags => ["sys", "logstash_secure", "%{host}" ]
    type => syslog
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_field => [ "received_at", "%{@timestamp}" ]
      add_field => [ "received_from", "%{host}" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

今回は試験用に/var/log/secure/var/log/cronchmod 644で読み取れるようにしておく。デフォルトだと600で開けず以下のエラーが発生する。

[2017-04-10T02:14:50,228][WARN ][logstash.inputs.file     ] failed to open /var/log/cron: Permission denied - /var/log/cron
[2017-04-10T02:14:50,519][WARN ][logstash.inputs.file     ] failed to open /var/log/secure: Permission denied - /var/log/secure
  • output

出力用の設定は次の通り。Fluentd(td-agent)の<match tag>と同様にtagにより送信・出力先を複数に振り分ける。配列の項目を比較する際は次のようになる。今回Elasticsearchは同一サーバを使用したが、別々に指定できる。ちなみに、上記filterプラグインでも既にシンプルなif分岐を使用している。

比較は基本的にRubyの文法に従う。詳細はオフィシャルを参照。

/etc/logstash/conf.d/output.conf

output {
  if [tags][1] == "logstash_messages" {
    elasticsearch {
      hosts => ["localhost:9200"]
      index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
    }
    file {
      path => "/var/log/logstash/%{tags[0]}/%{tags[1]}.log"
    }
  } else if [tags][1] == "logstash_cron" {
    elasticsearch {
      hosts => ["localhost:9200"]
      index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
    }
    file {
      path => "/var/log/logstash/others/%{tags[1]}.log"
    }
  } else {
    file {
      path => "/var/log/logstash/others/other.log"
    }
  }
}

配列の内容を比較する場合は[<type>][<number>]を指定する。通常だと[<type>]のみ。

実装結果

Elasticsearchのindexは設定通り、messagesとcronのみが作成されている。

$ curl http://localhost:9200/sys.logstash_cron-*
{"sys.logstash_cron-2017.04.09":{"aliases":{},"mappings":{"syslog":...

$ curl http://localhost:9200/sys.logstash_messages-*
{"sys.logstash_messages-2017.04.09":{"aliases":{},"mappings":{"syslog":...

$ curl http://localhost:9200/sys.logstash_secure-*
{}

fileへのバックアップはこちらの通り。設定した通りにファイルが生成されている。

$ sudo tree /var/log/logstash/

/var/log/logstash/
├── logstash-plain.log
├── others
│   ├── logstash_cron.log
│   └── other.log
└── sys
    └── logstash_messages.log

まとめ - Logstashで内容ごとに送信先を複数に振り分ける設定

if文を使用することで、Logstashで内容ごとにログの送信先を複数に分散、振り分けることができた。ログ種別に応じて、Elasticsearch、fileなど柔軟に保存方法を設定できる。

LogstashでFluentdのforest+copy同様に複数処理の設定をする

f:id:daichi703n:20170409131212p:plain

LogstashでFluentd(td-agent)のforestプラグインとcopyを組み合わせたものと同様の設定をしてみる。これにより、ログ種別、送信元が増えていっても出力設定を都度追加することなく、簡素化できる。

また、Logstashは日本語情報が少ないため、少しでも日本のユーザーとして普及に貢献したい。

期待する動作・Fluentdでの設定例

Fluentd(td-agent)でtag変数を元に、forestで処理する汎用的な設定をする。Fluentdでの設定イメージはこちらの通り。Chunk、Bufferなどの最適化は未実装。

ベース設定。個別の設定ファイルをincludeする。検証バージョンはtd-agent 0.12.31

/etc/td-agent/td-agent.conf

<source>
  @type forward
  port 24224
</source>

@include ./conf/*.conf

シンプルにローカルのログファイルを取り込む。ここで設定するtagをElasticsearchのindexなどに使用する。

/etc/td-agent/conf/local_messages.conf

<source>
  @type tail
  path /var/log/messages
  pos_file /var/log/messages.pos
  tag "sys.messages.#{Socket.gethostname}"
  format syslog
</source>

Elasticsearchへの送信設定。バックアップ・長期保存のためにファイルとしても保存する。forest+copyを使用することで、tagを変数として取り込んでindexやファイル名に使用できる。

/etc/td-agent/conf/elasticsearch.conf

<match *.*.**>
  type forest
  subtype copy
  <template>
    <store>
      @type elasticsearch
      host localhost
      port 9200
      logstash_format true
      logstash_prefix ${tag_parts[0]}.${tag_parts[1]}
      type_name ${tag_parts[0]}
      flush_interval 20
    </store>
    <store>
      @type file
      path /var/log/td-agent/${tag_parts[0]}/${tag_parts[1]}.log
      compress gzip
    </store>
  </template>
</match>

forestプラグインはこちら。

これにより、新規のログ種別が増えてもmatchディレクティブの中には追加の設定が不要になる。複数のログを複数のサーバからそれぞれ収集・集約したいときに効率が良い。

Logstashでの設定例

Logstashのバージョンは5.3.0で試験する。

$ /usr/share/logstash/bin/logstash --version
logstash 5.3.0

/etc/logstash/logstash.ymlpath.config: /etc/logstash/conf.dの設定がされていることを確認する。(デフォルトのため問題ないはず)

Logstashでのforest+copyは次のような設定になる。パーツごとに区切って解説するが、設定は/etc/logstash/conf.d/messages.confとして一つのファイルにまとめてよい。

inputでtagsを付与してFluentdと同様にtagで振り分ける。sourceディレクティブに相当する部分。%{host}環境変数を参照するため変更不要。なお、Fluentdに沿ってtagを使用したが、idtypeなど、他のフィールドを使用することもできる。

input {
  file {
    path => "/var/log/messages"
    tags => ["sys", "logstash_messages", "%{host}"]
    type => syslog
  }
}

filterで正規表現によるindex付け、日付の処理をする。FluentdだとSourceディレクティブ内のformatdate_formatに該当する部分。filter単体で動作するため、inputで取り込んだ複数のログに適用される。そのため、ifでフィルタ対象を限定する。

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_field => [ "received_at", "%{@timestamp}" ]
      add_field => [ "received_from", "%{host}" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

outputでelasticsearchとfileにそれぞれ出力する。Fluentdのmatchディレクティブに該当する。Logstashではcopy、forestといったプラグインを使用せず、シンプルにoutput内で複数出力、変数使用ができる。同一サーバでElasticsearchを動作させている場合のサンプルのため、環境に合わせてhostsを変更する。

なお、<match <tag1>.<tag2>.*>といった指定をしないため、出力形式を共通化する必要がある。

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
  }
  file {
    path => "/var/log/logstash/%{tags[0]}/%{tags[1]}.log"
  }
}

出力結果

tags変数が展開されindexとして使用されている。

$ curl http://localhost:9200/sys.logstash_messages-*
{"sys.logstash_messages-2017.04.09":{"aliases":{},"mappings":{"syslog":{"properties":{"@timestamp":{"type":"date"},"@version":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"host":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"message":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"path":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"received_at":{"type":"date"},"received_from":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_hostname":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_message":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_program":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_timestamp":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"tags":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"type":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}}}}},"settings":{"index":{"creation_date":"1491720002393","number_of_shards":"5","number_of_replicas":"1","uuid":"AO_MMCiqQYqcNIIEG8XmQg","version":{"created":"5020299"},"provided_name":"sys.logstash_messages-2017.04.09"}}}}

ファイルアウトプットも同様、tags変数が展開され、tag情報に基づいてディレクトリ、ログファイルが作成された。

$ tree /var/log/logstash/
/var/log/logstash/
├── logstash-plain.log
└── sys
    └── logstash_messages.log

まとめ - LogstashでFluentdのforest+copy同様に複数処理の設定をする

LogstashでFluentdのforest+copy同様の設定をした。これにより、ログ種別、送信元が増えていっても出力設定を都度追加することなく、簡素化できる。

GrafanaでElasticsearchのデータを表示する

f:id:daichi703n:20170404012051p:plain

Elasticsearchのデータ・ログ可視化ツールとしてはKibanaが用意されているが、ZABBIXなどのデータを組み合わせてGrafanaでダッシュボードを作りたいときもある。使い始めとして、GrafanaのデータソースとしてElasticsearchを連携させる設定方法を記載する。

KibanaとGrafanaの使い分け

はじめに簡単に私のKibanaとGrafanaの使い分け。

Kibana:検索・抽出(詳細)

こちらの記事に書いたとおり、Kibanaの拡張版を使用すればDiscoverタブでの検索結果をCSVにエクスポートすることもできる。

Grafana:ダッシュボード(概要)

ひと目で現在の稼働状態を監視するためのダッシュボードとしての使用がメインと考えている。また、データソースとしてInfluxDBをはじめ、ZABBIXPrometheusといった統合監視など多彩なプラグインが用意されているため、ひとつの画面で多くの情報を集約できる。

Grafana・Elasticsearchインストール

割愛します。YumリポジトリやオフィシャルDockerもあるため導入は簡単。ログ収集はFluentd(td-agent)、Logstashどちらでも問題なし。

Grafana Data Sources

ElasticsearchをGrafanaのData Sourcesとして追加する。次の通りType:Elasticsearchを選択しURLを入力する。Nameは任意。AccessはProxyにするとGrafana自身がデータを取得しにいく。

f:id:daichi703n:20170404005617p:plain

Indexを入力する。通常だとPattern: Dailyとして[<logstash-prefix>-]YYYY.MM.DDとする。

f:id:daichi703n:20170404005823p:plain

なお、Pattern: No patternで<logstash-prefix>-*としても動作するが、オフィシャルではYYYY.MM.DDでの設定方法が記載されている。

f:id:daichi703n:20170404005928p:plain

Addで登録するとDatasource addedと表示される。

f:id:daichi703n:20170404010015p:plain

注意:設定が誤っていても登録は完了される。ダッシュボードでログが正常に読み込まれない場合は設定を再確認する。また、Grafana v3.xではES v5.xを未サポート。

ダッシュボード作成

Graphを作成する。Panel data sourceで連携したElasticsearchのインデックスを指定し、Metric: CountGroup by: Date Histgramとすると、ログ数のグラフが表示される。

f:id:daichi703n:20170404010810p:plain

TableからMetric: Raw Documentとして生ログを表示することもできる。

f:id:daichi703n:20170404010907p:plain

なお、JSONデータはカラム指定で表形式で表示することができる。

f:id:daichi703n:20170404011000p:plain

複数指定することで必要な情報を並べることができる。

f:id:daichi703n:20170404011111p:plain

パネル作成時にクエリ指定することができるため、あとはカスタマイズしていく。Kibanaとの差別化ができていないが、FWのアクセスログだけでもそれなりのダッシュボードを作成することができる。GEO IPなどを使ってさらにカッコ良くしたい。

f:id:daichi703n:20170404011358p:plain

まとめ

GrafanaにElasticsearchのデータを取り込むことができた。各種クエリも継続使用できるため、柔軟性は高く、用途に応じたダッシュボードを作成することができる。