Amazon Elasticsearch Service の Kibana にログイン機能を追加できるようになりました | Developers.IO

Amazon Elasticsearch Service は Elasticsearch、Kibana の AWSマネージドサービスです。クラスタ・ノードを AWS が運用・管理してくれ、数クリックで Elasticsearch、Kibana のクラスタをプロビジョニングでき、ノードで障害が発生すればユーザーは何もしなくても復旧します。 今まで Amazon Elasticsearch Service の … 続きを読む

Elb logs to elasticsearch lambda

AWS Lambda Funcion作成完成版のLambdaコードはGistを見てください。以下、要点のみ説明します。 全体の流れELBがアクセスログをS3に書き込むと、メタ情報がS3イベントとしてLambdaに渡され、該当のLambdaファンクションを実行します。 以下、処Describes how to integrate Amazon Elasticsearch Service … 続きを読む

Amazon Elasticsearch Service Now Available in the AWS GovCloud

Amazon Elasticsearch Service Now Available in the AWS GovCloud (US) Region. AWS GovCloud (US) joins 16 other regions where you can use Amazon Elasticsearch Service. With the… 続きを表示. AWS GovCloud (US) joins 16 other regions where you can use Amazon Elasticsearch Service. With the … 続きを読む

Elasticsearchのpainless scriptをElasticsearchに保存する。

AWSのAmazon Elasticsearch Serviceでは、ファイルに保存したscriptの呼び出し等対応していませんでしたが、version5.5以上では、scriptのstoreに対応しています。これにより毎回queryに記載していたscriptを簡素化して呼び出すことができます。

この機能を使って、Elasticsearchの painless script をElasticsearch側に保存し、検索時には、idで呼び出せるようにします。

保存するscriptは、以前記載した Elasticsearchに登録した生年月日から現在の年齢を算出する. を使います。

scriptの保存

scriptの保存は、 _script/{id} で行います。

POST _scripts/script-age
{
  "script": {
    "lang": "painless",
    "code": "Date n = new Date(); Date b = new Date(doc['birthday'].value); DateFormat f = new SimpleDateFormat('yyyy-MM-dd'); return Period.between(LocalDate.parse(f.format(b)), LocalDate.parse(f.format(n))).getYears();"
  }
}

_script の後ろに指定した値が id として扱われる為、 id の管理は、利用する側で行う必要があります。

保存したscriptを使った検索

保存したscriptを利用する場合は、 scriptで stored : id を指定します。

GET {index}/{type}/_search
{
  "script_fields": {
     "age": {
       "script": {
         "stored": "script-age"
       }
     }
   }
}

scriptの参照

保存した script を参照する場合は、 GET_script を呼び出します。

GET _scripts/script-age

scriptの削除

script を削除する場合は、 DELETE_script を呼び出します。

DELETE _scripts/script-age

queryに直接記載されたscriptを分離することで、search queryの記述を簡素でき、script単独で管理できるようになります。

本家マニュアル
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-scripting-using.html#modules-scripting-stored-scripts

あとは、保存したscriptの一覧取得が欲しいところですが、バージョン5.5では、対応するapiはなさそうです。。

続きを読む

「Microservices Meetup vol.6」に行ってきた

2017/1/19のデイリーストックランキングにランクインしました。

【毎日自動更新】Qiitaのデイリーストックランキング!ウィークリーもあるよ_-_Qiita.png


いままでの。
「Microservices Meetup vol.2」行ってきたメモ。
「Microservices Meetup vol.4」に行ってきた

図らずして1回おきに参加してますね。

Connpassのイベントページ

少し間が空いてしまったがまた定期的に開催していきたいです。
登壇したいよーって人は直接リプ投げてください
by @qsona さん

Microservices on AWS by @Keisuke69 さん

Keisuke Nishitani @ AWS

Specialist Solutions Architect

サーバーレスアプリケーション開発ガイド 2月発売

マイクロサービスのポイント

  • 管理運用まで含めて分散型
  • 各コンポーネントが独立している
    • 単独で実行できないのは適切に設計されていない

独立して分散していると負荷の高い機能の単位でスケールさせられる=コスト効率が良い

  • 一つのことをうまくやる

    • 複雑化したら分割する
  • 多言語

    • チーム(機能)にはそれぞれの問題に対して適切なツールを選択する自由がある
    • OS、言語、各種ツールに至るまで最適なアプローチを目指せる
  • 検索:Elasticsearch / Solr

  • ソーシャル:グラフDB

  • ログデータ:Cassandra

  • セッション:Redis

†AWSでは:AWSには100ちょいのサービスがあって、その中で更にチームが分かれている。
各チームに社内標準の開発プロセスは存在しない。

  • ブラックボックス

    • 詳細は外部のコンポーネントに公開されない
  • DevOps
    • マイクロサービスにおける組織原理

†AWSでは:運用のみのチームはない。オンコールも開発チームが請け負う

  • 俊敏性

    • 狭い範囲のコンテキストで活動=サイクルタイムが短い
    • システムもシンプル
    • パラレルな開発とデプロイが可能
  • イノベーション

    • 選択に対する権限と責任を持つのでイノベーションを起こしやすい
    • DevとOpsの対立がないため、効率化やイノベーションが起こしやすい
  • 拡張性

    • 適切に非干渉化されてていることで水平方向に単独にスケールできる
  • 可用性

    • ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

課題

  • 分散型であることは難しい

    • システム数が増える
    • 協調動作の難しさ
    • コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
    • ネットワークの信頼性は無限ではない、帯域も無限ではない
  • 移行が大変
    • モノリシックなシステムの分割は難しい
  • 組織
    • 組織体制の変更が必要になるが、それは大変なこと
  • アーキテクチャの難易度
    • 非同期通信
    • データ整合性
    • やっぱりココが一番の課題
    • サービスディスカバリ
    • 認証
  • 運用の複雑さ

アーキテクチャ

一番シンプルなパターン

CloudFront – ALB – ECS – datastore(ElastiCache, Dynamo, )
|
S3

  • バックエンドをRESTfulなAPIにしたSPA
  • 静的なコンテンツはS3とCloudFront
    • CDN通すことでレイテンシが上がることもある
    • キャッシュとの併用を検討
  • ECSとAutoScalingをALBとともに使うことが多い
    • ALB(L7LB)でアプリレベルの情報をルーティング
    • コンテナインスタンスにリクエストを分散
    • ECSのコンテナを負荷に応じてスケールアウト/インする

コンテナのメリット

  • Portable
  • Flexible
  • Fast
    • 軽量で早い
    • ポータビリティと関連して開発サイクルも早く
  • Efficient

  • 一貫性のある環境

  • バージョン管理出来る

Dockerの特徴

  • Package
  • Ship
  • Run

ECS

  • 複数のコンテナをEC2のクラスタ上で一元管理

    • まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
    • EKS(Kubernetes)も発表されています

データストア

  • インメモリ

    • Memcached, Redis
    • ElastiCache
    • DB負荷の軽減
  • RDBMS
    • 無限のスケーリングには向いていない
    • Amazon RDS
  • NoSQL
    • 水平スケーリングをサポートするものが多い
    • テーブル結合ができないのでロジックの実装が必要になる場合も
    • Amazon DynamoDb, KynamoDB Accelarator(DAX)

APIの実装

  • APIの設計、改善、デプロイ、モニタリング、保守派手間がかかる
  • 異なるバージョンが混在すると大変

Amazon API Gateway

  • 複数バージョンとステージ
  • Cognite User Poolsと連携して認証を追加
  • スロットリング、モニタリング
  • バックエンドとしてLamdbaが使える

サーバーレス

  • サーバーはないに越したことはない
  • スケーリングと高可用性の担保が大変
CloudFront - API Gateway - Lamdba - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

課題をAWSでどうするか

サービスディスカバリ

  • お互いの死活確認や発見
  • ハードコードするとスケールできない

    • メタデータをどこに置くか
  • ALBを利用したサービスディスカバリ

  • DNS(Route53)のサービスディスカバリ

    • VPC単位の振り分け
  • ECSイベントストリームを使用したサービスディスカバリ

    • CloudWatchイベントで拾ってキック
    • LamdbaでRoute53に登録
    • これが一番多いかも
  • DynamoDBを使用したサービスディスカバリ

    • DNSキャッシュの問題がない
    • 自由度が高い
    • 実装が大変
    • DynamoDBストリームを活用して他のサービスへステータス変更を反映
  • イベントベースのアーキテクチャ

    • イベントで処理する
    • いわゆる結果整合性とも関連
    • Dual Write Problem
    • Event Sourcing
      • 状態の記録ではなく状態の変更「イベント」を記録
      • Amazon Kinesis
      • kinesisにpublishして他サービスはsubscribe
      • S3にログを残す
      • トランザクションログの仕組み

モニタリング

  • CloudWatch

    • ログファイルの一元化
    • CloudWatch LogsかS3に保存可能
    • ECSはCloudWatch Logsに一元化できる

分散トレース

  • AWS X-Ray
  • 複数サービスに分散したリクエスト処理を透過的に追える

LogWatchの先に Kinesis FireHorse – ほにゃほにゃ

スロットリング

  • 大事だよ

リトライ

  • 多くのエラーはリトライでカバーできるものが多い
  • リトライ多発で過負荷になることがある
    • Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
    • 更に乱数でゆらぎを付けて重ならないように

LT:クラウド型医療系業務システムと Microservices への歩み by @hashedhyphen さん

https://speakerdeck.com/hashedhyphen/kuraudoxing-dian-zi-karutesisutemuto-microservices-hefalsebu-mi

クラウド型電子カルテシステムの話

  • メインロジックをRails
  • 常時接続をNode.js
  • バックエンドをScala
  • 基盤はAWS

ここに至る道のり

ファーストリリース前

  • レコメンドは大量のデータが必要

  • メインロジックで実現させようとすると厳しかった

    • Threadとか試したけど……
    • 別アプリケーションとして分離
    • JVM上でScala + Skinnyでスレッドアプリケーションンを実装
    • Microservicesちっくな構成へ
  • 障害検知時

    • メインロジック内のプロトタイプ版が動く!

会計機能リリース前

  • お金を扱う機能は安定性が欲しい
  • Scala + Cats による実装を別エンドポイントとして実装
  • マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

まとめ

  • ちょっとマイクロサービス化したことで自由度が上がった
  • 原理主義的にならなくても恩恵がある
  • エンジニアの伸びしろ!

FrontEndからみるmicroserviceとBackendからみるmicroservice by @taka_ft さん

Takahiro Fujii @ Rakuten Travel

楽天内でも採用アーキテクチャはサービスによって異なる。

サービスとしては

  • コンシューマ向け
  • Extranet
  • In-house
  • other
    • ここまではWEBとモバイルがあって、100以上のAPIを利用する
  • API(内部APIを直接利用)

Phase 1

  • 大きなモノリシックなアプリだった
  • 機能がどんどん増えていく
    • 機能別で複数のモノリシックなアプリに分割
    • その後フロントエンドとバックエンドに分割

Phase 2

  • ドメインモデルを整理
  • なるべくRESTfulで作るようになっていった
  • 大きなAPIから小さなAPIに分離
  • I/Fの決定に時間がかかるようになった
  • API呼び出しが大変になった
  • Microservicesっぽくなってきた 2014年くらい

  • 国内予約、海外予約で多言語化だけではない商習慣に根ざしたドメインの差異による重複ロジックの増殖が起きた

  • Microservicesっぽくなってきたが、どんどん品質が下がっていった

Phase 3

(ちょうど前日にプレスリリース)サイト前面刷新に向けての取り組み

  • FrontendsはJavaScriptに刷新
  • API GatewayにKong

組織

  • フロントエンドチームが2人から始まって半年でReactエンジニアを集めて20人以上に

    • 日本人は2, 3人

UI Component

  • SpringからJavaScriptでSPAに変更
  • zeplinのデザインモックからUI Componentを実装するようになった
  • Storyboardを使ってUI Coponentを管理
  • ドメインを含むUI Componentはドメインと結び付きが強いことが多い=専用のオーケストレーションAPIを用意してUI Componentないで処理を閉じることが出来る
  • レスポンシビリティを明示的に定義

    • どこまでフロントエンドでやるか、どこからAPIからもらうか
  • フロントエンドの「使いやすいレスポンス」の要求

  • バックエンドの「汎用的でシンプルなレスポンス」の希望

    • これらのバランスを取る
  • API Gatewayはフロントエンド(UI)チームの管轄

    • ただし状況によってはバックエンド側に持っていくことも検討するつもり

LT: “マイクロサービスはもう十分”か? by @qsona さん

https://speakerdeck.com/qsona/enough-with-the-microservices

POSTDに投稿していた翻訳記事。

スタートアップ企業のほとんどはマイクロサービスをさいようすべきではない

銀の弾丸はない。

「チーム間の依存性」の解決にマイクロサービスというアプローチは違う。疎結合と分散は別。

組織が大きくなると、複数チームが1つのコードベースを触るようになる。そしてマイクロサービス化したくなる。

しかし、モノリスの分割で十分。

チームとは何か

  • 自律的に動けるべき

    • チームが増えるとコミュニケーションコストや、しがらみ
  • チームの分割は目的にそった分割を行う

  • 悪い分割の例: Dev / Ops

  • 依存度が低いほど自律的に動ける

  • High Output という本

  • 使命型組織/技術型組織

    • Micorservicesは使命型組織
    • 組織間が密ならサービス間も密になる

話戻して

  • スタートアップは組織をキレイに分割することが難しい
  • 分割しても密になってしまう

  • 大きなモノリスになるとやはり分割は難しい

    • ドメインの意識は必要
  • マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNCが初期からマイクロサービスでやってた理由

  • 単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

あとで読み返して修正します。
資料パスの追加とかも。

続きを読む

Dynamic Inventoryを用いたプロジェクトでansible-consoleを使う

概要

ansibleでDynamic Inventoryを用いてec2を管理している際に
ansible-consoleをどのように使うのかメモ。
複数台のサーバに対して、簡単に調査したいときなど使えそう。

起動

  • -iの引数に、ec2.pyを渡せばOK。
$ cd /path/to/your/ansible
$ ansible-console -i ./inventories/ec2.py

console操作

グルーピング

user@all (19)[f:100]$ list groups

all
ec2
tag_Group_api
tag_Group_web
tag_Group_elasticsearch
・・・・・
  • リストした時に出力されるのは、./ec2.pyのtag_xxxが全てのようだ。
./ec2.py  --list

  "tag_Group_api": [
    "api01_dev"
  ],
・・・・・

(試し)elasticseachクラスタに対して設定ファイルgrepする

(グループ移動)
user@all (19)[f:100]$ cd tag_Group_elasticsearch

(対象ホスト確認)
user@tag_Group_elasticsearch (2)[f:100]$ list
es01_dev
es02_dev

(grepする)
user@tag_Group_elasticsearch (2)[f:100]$ grep "discovery.type" /etc/elasticsearch/elasticsearch.yml
es01_dev | SUCCESS | rc=0 >>
discovery.type: ec2

es02_dev | SUCCESS | rc=0 >>
discovery.type: ec2

参考

続きを読む

ZendeskのチケットデータをAmazon Elasticsearch Serviceへ自動的にアップロードする | Developers.IO

Amazon Elasticsearch ServiceはAmazon VPCプライベートサブネットに作成; Amazon API Gateway経由でAWS Lambdaを実行させる; Zendeskの自動化とwebhookでAmazon Elasticsearch Serviceへデータを入れるまでを自動化する; Amazon Elasticsearch Serviceへ入れるデータスキーマ … 続きを読む

センサデータを fluentd 経由で Amazon Elasticsearch Service に送信して可視化

1. はじめに

以前の記事 で、RaspberryPi で収集したセンサデータを、 さくらVPS上に構築した Elasticsearch に送信して、Kibana で可視化しました。
今回は勉強を兼ねて、データを Amazon Elasticsearch Service ( Amazon ES ) に送信するように構成を変更します。

2. 全体の構成

image.png

3. 設定

3-1. Server side ( Amazon ES )

Amazon ES を立ち上げます。

Amazon ES ダッシュボード

  • 画面右上で、東京リージョン( ap-northeast-1 )が選択されていることを確認します
  • 新しいドメインの作成ボタンを押します
image

ドメインの定義

  • ドメイン名と Elasticsearch のバージョンを設定します
image

クラスターの設定

  • 今回は最小構成にします
image

アクセスの設定

  • ダッシュボードは特定メンバーに公開したかったので、パブリックアクセスとして、IPアドレスでアクセス制限を設定しました
  • 本当は IAM Role で制限したかったのですが、Webブラウザからのアクセスが面倒になるので今回は見送りました ( ブラウザはIAM認証できない )
image

完了確認

  • 10分ほど待ちます
image
  • 設定の状態が「アクティブ」になれば完了です
image

3-2. Sensor side ( Raspberry PI )

前提条件

以前の記事 の状態が前提です。今回はこれに変更を加えます。

プラグインのインストール

  • fluentd から Elasticsearch に直接格納するためのプラグインをインストールします
  • なお、IAM 認証をする場合は fluent-plugin-aws-elasticsearch-service を使うようです
sudo fluent-gem install fluent-plugin-elasticsearch

fluentd の設定

  • fluentd の設定ファイルを編集して、データの送信先を変更して、fluentd を再起動します
/home/pi/fluent/fluent.conf
<source>
  @type tail
  format json
  path /home/pi/myroom.log
  pos_file /home/pi/myroom.log.pos
  tag log.myroom
</source>

<match log.myroom>
  @type copy
  <store>
    @type elasticsearch
    type_name myroom
    logstash_format true
    logstash_prefix myroom
    reload_connections false
    hosts https://search-myroom-********.ap-northeast-1.es.amazonaws.com
  </store>
</match>

4. 確認

データが送信されていることを確認しました。
image.png

続きを読む

RaspberryPi で収集したセンサデータを Amazon ES に格納

1. はじめに

前回の記事 では、RaspberryPi で収集したセンサデータを、 さくらVPS上に構築した Elasticsearch に格納しました。
今回は勉強を兼ねて、データを Amazon Elasticsearch Service ( Amazon ES ) に格納するように構成変更します。

2. 全体の構成

image.png

3. 設定

3-1. Server side ( Amazon ES )

Amazon ES を立ち上げます。今回はそれだけです。

Amazon ES ダッシュボード

  • 画面右上で、東京リージョン( ap-northeast-1 )が選択されていることを確認します
  • ドメインの作成ボタンを押します
image

ドメインの定義

  • ドメイン名と Elasticsearch のバージョンを設定します
image

クラスターの設定

  • 今回は最小構成にします
image

アクセスの設定

  • ダッシュボードは特定メンバーに公開したかったので、パブリックアクセスとして、IPアドレスでアクセス制限を設定しました
  • 本当は IAM Role で制限したかったのですが、Webブラウザからのアクセスが面倒になるので今回は見送りました ( ブラウザはIAM認証できない )
image

完了確認

  • 10分ほど待ちます
image
  • 設定の状態が「アクティブ」になれば完了です
image

3-2. Sensor side ( Raspberry PI )

前提条件

以前の記事 の状態が前提です。今回はこれに変更を加えます。

プラグインのインストール

  • fluentd から Elasticsearch に直接格納するためのプラグインをインストールします
  • なお、IAM 認証をする場合は fluent-plugin-aws-elasticsearch-service を使うようです
sudo fluent-gem install fluent-plugin-elasticsearch

fluentd の設定

  • fluentd の設定ファイルを編集して、データの送信先を変更して、fluentd を再起動します
/home/pi/fluent/fluent.conf
<source>
  @type tail
  format json
  path /home/pi/myroom.log
  pos_file /home/pi/myroom.log.pos
  tag log.myroom
</source>

<match log.myroom>
  @type copy
  <store>
    @type elasticsearch
    type_name myroom
    logstash_format true
    logstash_prefix myroom
    reload_connections false
    hosts https://search-myroom-q6f5bk4cwppojeescffv24dmkm.ap-northeast-1.es.amazonaws.com
  </store>
</match>

4. 確認

データが送信されていることを確認しました。
image.png

続きを読む

AWSでElastic Stack – 前回の続き Kibana Filebeatのアップグレード

はじめに

前回、KibanaとFilebeatもアップグレードするような記事を書いたのですが、途中で力尽きてElasticsearchのアップグレードで終わってしまったので、短くなりますが、KibanaとFilebeatもアップグレードしたいと思います。
前回の記事(前回中途半端で申し訳ないですが)の構成を参照して頂ければと思います。

AWSの小ネタ

本題とは関係ありませんが、一応AWSタグを付けているので、AWSで悩んだ話について。

IAMロールで起動したEC2インスタンスのプロキシ環境下にて、プロキシサーバのログに以下のログが大量に出力されていました。

TCP_MISS/404 609 GET http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s - HIER_DIRECT/169.254.169.254 text/html

それでxxになっているMACアドレスを持つサーバを調べると以下のログが連続して大量に出力されていました。

ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s

恐らくec2がmetadataを取りにいくのですが、プロキシサーバを経由してしまうせいで、
ご本人じゃありませんよとAWSのmetadataサーバに拒否されているんでしょうと推測しました。

プロキシ環境下では169.254.169.254はプロキシを経由しないようにNO_PROXYの設定を設定します。
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-http-proxy.html

自分もこの設定を入れていましたので、設定が有効になっていないかと悩まされることになりました。そこで一旦、exportしているプロキシの設定を削除しましたが、
やっぱりプロキシサーバを経由することを止められませんでした。

そこで他のプロキシを利用する設定を考えたところ、そういえば最初は全てのアクセスをプロキシ経由にするつもりが無くて、yumやwget,curlくらいしかInternetへのアクセスをしないので、それぞれのコンフィグにプロキシの設定を個別に書いていたなと思い至りました。

それで結局当たったのは、curlの.curlrcのプロキシの設定でした。
ここにはNO_PROXYの設定は書いていませんでした。
ここの設定が有効でプロキシサーバ経由でアクセスしているとは・・
ec2がmetadataを取得する際にはcurlで取りにいっているってことですかね?(分かってない)

1.アップグレード作業

では前回やり残したKibanaとFilebeatのアップグレード作業を実施したいと思います。

1.1.事前準備

公式のドキュメントを参考にしながら進めていきます。
Kibana
https://www.elastic.co/guide/en/kibana/current/rpm.html
Filebeat
https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html

あれ・・・前回見た時は6.0だったのに、どんどん更新されていきますね。

1.1.1.GPGキーのインストール

KibanaとFilebeatをインストールしているそれぞれのサーバにて実施します。

Kibanaをインストールしたサーバ(srv1)

# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Filebeatをインストールしたサーバ(srv4)

# rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

1.1.2.リポジトリの修正

6.0系のリポジトリを用意します。

Kibana

# vi /etc/yum.repos.d/kibana.repo
[kibana-6.x]
name=Kibana repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Filebeat

# vi /etc/yum.repos.d/beats.repo
[elastic-6.x]
name=Elastic repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

1.2.アップグレード

Kibana

# yum update kibana
Loaded plugins: priorities, update-motd, upgrade-helper
42 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package kibana.x86_64 0:5.6.2-1 will be updated
---> Package kibana.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================
 Package                     Arch                        Version                        Repository                       Size
==============================================================================================================================
Updating:
 kibana                      x86_64                      6.1.1-1                        kibana-6.x                       63 M

Transaction Summary
==============================================================================================================================
Upgrade  1 Package

Total download size: 63 M
Is this ok [y/d/N]: y

Filebeat

# yum update filebeat
Loaded plugins: priorities, update-motd, upgrade-helper
Resolving Dependencies
--> Running transaction check
---> Package filebeat.x86_64 0:1.3.1-1 will be updated
---> Package filebeat.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================================================================================================
 Package                                        Arch                                         Version                                       Repository                                         Size
===================================================================================================================================================================================================
Updating:
 filebeat                                       x86_64                                       6.1.1-1                                       elastic-6.x                                        12 M

Transaction Summary
===================================================================================================================================================================================================
Upgrade  1 Package

Total download size: 12 M
Is this ok [y/d/N]: y

1.3.サービスの再起動

Kibana

# service kibana restart
kibana started

Filebeat

 service filebeat restart
2017/12/25 08:46:58.653044 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.653113 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.653234 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.653256 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.653386 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.653586 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
Stopping filebeat:                                         [  OK  ]
Starting filebeat: 2017/12/25 08:46:58.773001 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.773063 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.773112 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.773132 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.773280 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.773479 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
                                                           [  OK  ]

1.4.確認

KibanaとFilebeatのバージョンやログが取れているか等確認します。

Filebeatアップグレード前

# filebeat -version
filebeat version 1.3.1 (amd64)

Filebeatアップグレード後

# filebeat -version
filebeat version 6.1.1 (amd64), libbeat 6.1.1

Kibanaアップグレード前
kibana-version.png

kibanaアップグレード後
kibana6.1ver.png

あ~~ elasticsearchとバージョンが一致しないって怒られてますね。
マイナーバージョンも一致が必要なのは作業的に面倒ですね・・

というわけでまた前回の記事と同じようにアップグレードしてきました。

# curl -XGET 'localhost:9200/'
{
  "name" : "node001",
  "cluster_name" : "my-cluster",
  "cluster_uuid" : "e06BKBFFSpiSkFwNT3kWLw",
  "version" : {
    "number" : "6.1.1",
    "build_hash" : "bd92e7f",
    "build_date" : "2017-12-17T20:23:25.338Z",
    "build_snapshot" : false,
    "lucene_version" : "7.1.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

# curl -XGET 'http://localhost:9200/_cat/plugins?v'
name    component         version
node002 analysis-kuromoji 6.1.1
node002 x-pack            6.1.1
node003 analysis-kuromoji 6.1.1
node003 x-pack            6.1.1
node001 analysis-kuromoji 6.1.1
node001 x-pack            6.1.1

改めてKibanaを確認してみます。

kibana6-1.png

エラー直りました。通常のログイン後の画面に。
先ほどのエラー画面だから画面の色合いが違うのかと思っていたのですが、普通に落ち着いた感じになっております。
改めてバージョンを確認します。

kibana_ver6-1.png

OKですね。

では、次にfilebeatからデータが送られているかを確認します。

filebeat1.png

(新しいデータが)有りません

そこでfilebeatのログを確認してみたところ・・・

2017-12-27T07:53:01Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T07:53:01Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T07:53:01Z INFO Metrics logging every 30s
2017-12-27T07:53:01Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T07:53:01Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T07:53:01Z INFO Beat name: ip-192-100-0-36
2017-12-27T07:53:01Z INFO filebeat start running.
2017-12-27T07:53:01Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Total non-zero values:  beat.info.uptime.ms=3 beat.memstats.gc_next=4473924 beat.memstats.memory_alloc=3081016 beat.memstats.memory_total=3081016 filebeat.harvester.open_files=0 filebeat.harvester.running=0 libbeat.config.module.running=0 libbeat.output.type=elasticsearch libbeat.pipeline.clients=0 libbeat.pipeline.events.active=0 registrar.states.current=0
2017-12-27T07:53:01Z INFO Uptime: 3.375689ms
2017-12-27T07:53:01Z INFO filebeat stopped.
2017-12-27T07:53:01Z CRIT Exiting: Could not start registrar: Error loading state: Error decoding states: json: cannot unmarshal object into Go value of type []file.State

なんかエラー出て、filebeatが起動していない感じですかね。
そのエラーについて調べてみたところ、同じような状態になった方がおり、解決されていました。
https://discuss.elastic.co/t/exiting-could-not-start-registrar-error-loading-state-error-decoding-states-eof/74430

/var/lib/filebeat/registryを削除してから起動すれば良いようですね。
この環境は壊れても失うのは時間だけなので、やってみます。

# rm /var/lib/filebeat/registry
# service filebeat start
# cat /var/log/filebeat/filebeat

2017-12-27T08:14:08Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T08:14:08Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T08:14:08Z INFO Metrics logging every 30s
2017-12-27T08:14:08Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T08:14:08Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T08:14:08Z INFO Beat name: ip-192-100-0-36
2017-12-27T08:14:08Z INFO filebeat start running.
2017-12-27T08:14:08Z INFO No registry file found under: /var/lib/filebeat/registry. Creating a new registry file.
2017-12-27T08:14:08Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T08:14:08Z INFO States Loaded from registrar: 0
2017-12-27T08:14:08Z INFO Loading Prospectors: 1
2017-12-27T08:14:08Z WARN DEPRECATED: input_type prospector config is deprecated. Use type instead. Will be removed in version: 6.0.0
2017-12-27T08:14:08Z INFO Starting Registrar
2017-12-27T08:14:08Z INFO Starting prospector of type: log; ID: 5240556406633074861
2017-12-27T08:14:08Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1
2017-12-27T08:14:08Z INFO Harvester started for file: /var/log/secure
2017-12-27T08:14:09Z INFO Connected to Elasticsearch version 6.1.1
2017-12-27T08:14:09Z INFO Loading template for Elasticsearch version: 6.1.1
2017-12-27T08:14:09Z INFO Elasticsearch template with name 'filebeat-6.1.1' loaded

criticalなエラーは解決したようです。

しかしながら新たなエラーが。

2017-12-27T09:24:40Z ERR  Failed to publish events: temporary bulk send failure

そういえば、WARNもありますね。まずこれが気になるのでfilebeat.reference.ymlを見ながら修正してみました。

修正したfilebeat.yml

filebeat.modules:
- module: kafka
  log:
    enabled: true
filebeat.prospectors:
- type: log
  enabled: false
  paths:
    - /var/log/secure.log
output.elasticsearch:
  hosts: ["192.100.0.4:9200"]
setup.template.settings:
setup.kibana:
logging.to_files: true
logging.files:

filebeatを再起動することでWARNは消えました。

# cat /var/log/filebeat/filebeat
2017-12-27T09:49:12Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T09:49:12Z INFO Metrics logging every 30s
2017-12-27T09:49:12Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T09:49:12Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T09:49:12Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T09:49:12Z INFO Beat name: ip-192-100-0-36
2017-12-27T09:49:12Z INFO Enabled modules/filesets: kafka (log),  ()
2017-12-27T09:49:12Z INFO filebeat start running.
2017-12-27T09:49:12Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO States Loaded from registrar: 1
2017-12-27T09:49:12Z INFO Loading Prospectors: 2
2017-12-27T09:49:12Z INFO Starting Registrar
2017-12-27T09:49:12Z INFO Starting prospector of type: log; ID: 15188226147135990593
2017-12-27T09:49:12Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1

ERRが出力されるのかしばらく待ちます。

ERRも出なくなってました。しかし肝心のデータがkibanaで表示されない・・・

 おわりに

今回はこれで終わりにしたいと思います。
また来年続きやります・・・

こんなんばっかりや・・

続きを読む