Elastic Cloudに既存のログ基盤を移せるか検証してみた(EFKスタック)

  • 5
    Like
  • 0
    Comment

これはElastic stack (Elasticsearch) Advent Calendar 2016 16日目の記事です。

アクセスログとかアプリのエラーログを、オンプレ環境でEFKスタック使って集約しているのですが、全社をあげたクラウド化に伴いAmazonESかElasticCloudどちらを採用するか迷っており、今回、ElasticCloudを試してみました。

検証環境のログを、Elastic Cloudに流してTimelionで可視化するまでのレポートです。(何かネタあるだろうと3年連続AdventCalender登録したのですが、昨日ELASTIC{ON} 東京に参加したおかげでネタ出来てよかった。。)

※AmazonESは既に検証済

目次

  • Elastic Cloudについて
  • 既存のログ検証環境の出力先の一つにElastic Cloudを追加する手順(elasticseach,fluentd)
  • Timelionでの可視化

はじめにまとめ

検証しながら書いていて長くなってしまったので、最初にまとめを書いておきます。

  • AmazonESにも言えるが、HEAPだったりパラメータのチューニングを気にせずに、サッと環境つくれてデータをどう使うかにフォーカス出来るのはマネージドサービスの強み
    • elasticsearchは、そこそこ運用にパワーがいるのを実感してるから尚更
  • Timelionにはかなりのポテンシャルを感じる(ログ分析との相性が最高に良い)
    • esの異なるインデックスや他のデータソースの可視化に使える(SQLもいけそうな!!)
  • Kibana5は、Timelion,Console(Sensu)が内包されグレードアップした
  • fluentdからのデータ投入は、ほぼ既存の設定で移行出来る
  • AmazonESと比較した時に、最新版のelastic スタックを使えるのは大きなメリット(AmazonESは、1.5か2.3固定)

Elastic Cloud

elastic社が運営している、elasticスタックのマネージドサービスです。
※AWS上にある、AmazonES(Elasticsearch Service)は、Amazonが運営しているもので、elastic社は関与していないとのこと

トライアルアカウント発行

14日間 フリートライアルがあるので早速メアドを入力して登録。

Memory:1G/Storage:24Gの環境が使えるみたい!!

https://www.elastic.co/jp/cloud

以降の設定は、下記投稿を参考に進めていく(わかりやすくて助かりました!!)

http://qiita.com/takanorig/items/873f02119768dcaf4be8

<ポイント>
- 途中でポップアップ表示されるパスワードを控えておく
- kibanaはデフォルトでは無効なので、[Configuration]で有効化する

クラスタの構築はこれで終わり。
簡単!

料金

memory+Storageのサイズ毎に固定のようです。

https://www.elastic.co/jp/cloud/as-a-service/pricing

※月額固定で、AmazonESのようにデータ転送料金はかからないよう。(昨日 大谷さんに聞きました)

既存のログ検証環境の出力先の一つにElastic Cloudを追加する手順

で本題の使い勝手について調査

まずは、エンドポイントに対してcurlでリクエストを送ってみる。

※ベーシック認証かかっているので、user(elastic)とパスワードの入力を忘れずに

5.1.1のelasticsearchのクラスタが見えてますね!ここまで10分で来れます。

$ curl --user elastic:"パスワード" https://5ef0d41100ec1a27fbf4e2fb4d8adee9.ap-northeast-1.aws.found.io:xxxx
{
  "name" : "instance-0000000000",
  "cluster_name" : "5ef0d41100ec1a27fbf4e2fb4d8adee9",
  "cluster_uuid" : "KDJqvcB-TGy_cFSzS2q6QA",
  "version" : {
    "number" : "5.1.1",
    "build_hash" : "5395e21",
    "build_date" : "2016-12-06T12:36:15.409Z",
    "build_snapshot" : false,
    "lucene_version" : "6.3.0"
  },
  "tagline" : "You Know, for Search"
}

続いてお決まりのtemplate作成

elasticsearchはスキーマレスではあるのですが、欲しいデータをうまく使うにはスキーマを定義する必要があります。
↓そこら辺の話はだいぶ前のネタですが、下記に書いてあります。
プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事

multi_field→fieldsに変更(5系から)

既存のテンプレートで、multi_field(一つのフィールドに対して、複数の型を持たせる)を使っていたので少しはまる。。

{"error":{"root_cause":[{"type":"mapper_parsing_exception",
"reason":"No handler for type [multi_field] declared on field [c_ip]"}],
"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: No handler for type [multi_field] declared on field [c_ip]",
"caused_by":{"type":"mapper_parsing_exception","reason":"No handler for type [multi_field] declared on field [c_ip]"}},"status":400}

公式ドキュメントのfields

#2系まで使えたmulti_typeを使った書き方
        "c_ip" : { "type":"multi_field",
          "fields":{
            "c_ip":{ "type":"string","index":"not_analyzed", "doc_values": true},
            "iptype":{ "type":"ip", "doc_values": true}
          }
        }

↓
#5系のfieldsを使った書き方
        "c_ip" : {
          "type":"string",
          "index":"not_analyzed",
          "doc_values": true,
          "fields": {
            "iptype":{
              "type":"ip",
              "doc_values": true
            }
          }
        }

multi_field指定してた箇所だけ修正して、無事テンプレート作成

$ curl --user elastic:パスワード -XPUT https://5ef0d41100ec1a27fbf4e2fb4d8adee9.ap-northeast-1.aws.found.io:9243/_template/iislog_template -d @./iislog_template_5.json
{"acknowledged":true}

templateの確認 (kibana5のconsoleで)

早速、kibana5からbundleされたと昨日聞いたconsoleでtemplateを確認。
console: sensuと言われていた、elasticsearchに気軽にクエリを投げれるプラグイン

うん、便利だ!

Console_-_Kibana.jpg

fluentd経由で、ElasticCloudにpostする

templateが入ったので、fluentdからデータ投入

AmazonESは、専用のfluentdのプラグインを使わないといけなかったけど、elasic cloudはどうなんだろうという不安を抱えつつとりあえず下記でデータ投入してみる。

最近は、logstashユーザも増えてきているみたいですが、うちの環境ではfluentdを使っているので下記のように、copyプラグインに一つアウトプット先を一つ追加

hosts句に認証情報を埋め込む形式

AmazonESでは、専用のtype[aws-elasticsearch-service]を使う必要があったがElastic Cloudではelasticsearchプラグインで行けた!!

/etc/td-agent/td-agent.conf
  <store>
    @type forest
    subtype elasticsearch
    <template>
      @id iislog_elastic_cloud
      hosts "https://#{ENV['ES_CLOUD_USER']}:#{ENV['ES_CLOUD_PASSWORD']}@#{ENV['ES_CLOUD_URL']}"
      logstash_format true
      time_key datetime
      logstash_prefix iislog_${tag_parts[1]}
      logstash_dateformat %Y.%m.%d
      type_name iislog
      buffer_type file
      buffer_path /var/log/td-agent/buffer/iislog_${tag_parts[1]}_es_cloud.*.buffer
      buffer_chunk_limit 3m
      buffer_queue_limit 2000
      flush_interval 1s
      flush_at_shutdown false
      retry_wait 1s
      retry_limit 17
    </template>
  </store>

ポイントとしては、hostsで認証情報を埋め込む必要があるので、そこは環境変数で隠蔽してるとこ。べた書きはよくない。

  • td-agentで環境変数を使うには、/etc/sysconfig/td-agentに書き込む

fluentdを再起動し、無事connectelastic cloudにアクセス出来たことを確認。

突然のkibana(on Elastic Cloud)エラー

中々お目にかかれそうもないエラーが出たので、一応記録として貼っておく。

fluentdから接続し、データのインサートが始まったが、トライアル環境に一度に大量のログ(fluentdに結構なbuffer作ってたので駄目だったみたい)投げすぎたらしくクラスタが固まったww

Kibana.jpg

リロードすると。。。

Kibana.jpg

ごめんなさい。
セッションクリアして、再度接続!

トライアル環境のせいか全体的に動きは重いな。。

kibanaにドキュメントが入っているか確認

投入まで成功

Kibana.jpg

Timelionで可視化

普通にVisualizeを使っても面白くないので、kibana5からプラグインでなくバンドルされるようになったというTimelionを使ってグラフを作ってみる

異なるインデックスを一つのグラフにプロットするのは、Visualizeでは出来なかったのでかなり重宝しそうです。

データソース関数は独自のものですが、Timelion内にヘルプページもあり理解が捗ります

今回の可視化に使ったデータソース関数
内容) indexをサービス毎にわけているのでサービス毎のアクセス数を可視化

.es(index=iislog_stay-*).label(stay).color(#81BEF7) .es(index=iislog_ray-*).label(ray).color(#088A68), .es(index=iislog_res-*).label(res).color(#FF8000).title(access_count)
関数名 意味
es elasticsearchをデータソースとして指定
label 表示されるメトリクスにつけるラベル
color 色をカラーコードで指定

sample1_-_Timelion_-_Kibana.jpg

参照

[Timelion]
http://blog.johtani.info/blog/2015/12/01/introduction-timelion/
https://www.elastic.co/jp/blog/timelion-timeline

使い勝手は中々よかったので、ビジュアライズ周りをもう少し検証してどのような構成で行くか決めたいと思います。