これは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の環境が使えるみたい！！

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

<ポイント>

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

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

##料金

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

※月額固定で、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に気軽にクエリを投げれるプラグイン

うん、便利だ！

##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にドキュメントが入っているか確認

投入まで成功

#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	色をカラーコードで指定

##参照

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

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