第19回Elasticsearch勉強会に参加しました #elasticsearchjp
ちょっとと遅くなりましたが、勉強会の参加レポ。
3月にサンフランシスコで行われたElastic{ON} 2017のフィードバックイベントだったので、仕事そっちのけで参加しました。
Elastic{ON} Re-cap
Jun Ohtani @ Elastic
日本からの参加者は50名程度
日本からスポンサーとして日立が参加。
ASK ME ANYTHING
Elasticのエンジニアに直接聞けるブース。常にエンジニアが数人立っている。
質問リスト持ってきてガッツリ質問してる人もいたり。
ご飯
ご飯も売り。
フードトラックが来る。
Filebeat Modules
5.3から。
今まではFilebeat1行1データでパースはLogstashを使う必要があった。
- Elasticsearchだけでインデックスに入れる前の前処理を書くことができる。
⇒ingest node
- moduleはそれを使用しているので、Filebeatがログをパースしているわけではない。
Time Series Visual Builder
Kibana 5.4から
メーターのVisualizeなどが追加。
今Timelionでやっている複雑なグラフもKibanaで行える。
Elastic Cloud Enterprise
AWS上でElastic Cloudで自動化しているがオンプレ環境でも出来るようになる。
GCPでも使える。
インフラエンジニアがおらず、プライベートクラウド使ってる弊社では、ECE使うのが一番楽そうなので、早く情報が欲しいところです。
Elasticsearch SQL
Coming soon
トランザクションは元々そういう概念が無いのでサポートするつもりはない。
提供方式は未定だが、今のところX-Packで行う予定。無償・有償は分からない。
GW中に来るかもと言われていたElastic Stack5.4がほんとにきちゃったので、
https://www.elastic.co/blog/elastic-stack-5-4-0-released
Machine Learningとか新しいKibanaの機能とか早く試していかないとですね。
BASEさん主催のPAY Developer Meetup #00 に参加してきた
週末募集開始されて、月曜開催というタイトなスケジュール。
特に用事なんて無いので参加させていただきました!
BASEさんの新イベント用スペースめっちゃ綺麗でした!
椅子も今日出したばかりの新品らしい。
LT2本立ての構成でした。
次は喋ってみたいな~。
PAY ID決済 イントロダクション
PAY事業部の高野さん。
PAY IDの概要から、実装までを見せてくれました。
ダッシュボードでクライアント用ID発行して、HTMLに1行追加するだけでカード入力画面にPAY ID決済ボタンが出現!
詳しくは↓
id.pay.jp
PAY ID
- 2016年6月27日に提供開始した購入者向け決済サービス
- PAY IDにクレカ情報や配送情報を紐づけることで都度入力せずに決済が可能
- BASE加盟店を含む40万加盟店で利用可能
毎回決済のたびに財布からカード取り出して、番号やセキュリティコード入力する手間が省けるのでいいですよね。
デモ
あっという間に実装されるさまは圧巻。
ダッシュボードのUIも今風でかっこいい。
質疑応答
Q.UIのカスタマイズは
A.Checkoutは既存のもの。OAuthAPI使えばカスタマイズできる。
Q.テスト環境使ってるんだけど任意の値が入れられるけど、表示順がバラバラになる
A.導入を検討する。
Q.PAYIDの住所や電話番号は認証済み?
A.物販で使用された実績はあるが、100%の保証はない。
PAY.JP使ってます
MAMORIOの高野さん
www.mamorio.jp
www.slideshare.net
金曜日にLTの依頼があったらしい。
PAY.JPにした理由
- ApplePayでの課金実現可能
- HPが綺麗だったから
- コミュニケーションが他社よりフランク
- 開発者ページが充実
懇親会では途中ボッチになってましたが、会話に混ざっていくことで
結果としていろんな人と話が出来て良かったです。
次回もぜひ参加したいです。
ありがとうございました!
Apache Struts2の脆弱性(S2-045,CVE-2017-5638) を突かれ、クレジットカード情報等72万件流出
週末にびっくりするニュースが飛び込んできましたね。
都税と住宅金融支援機構のサイトからクレジットカード情報などが大量に流出しました。
itpro.nikkeibp.co.jp
3月8日にIPAが公開した、Apache Sturts2の脆弱性を突かれたようです。
www.ipa.go.jp
Sturts2の脆弱性
Struts2は2016年にも重大な脆弱性が報告され、ネットを騒がせました。
この時に修正版を適用して良しとするのではなく、システム全体を改修すべきだったようです。
Java EEやSpringではこのようなことは起きていませんからね。
Struts2は何度も致命的な脆弱性を出しています。
そのたびにNGワードを追加することで対応してきたのですが、対応がお粗末です。
通常のサイトであれば、Struts2を使い続ける選択肢はあると思いますが、
クレジットカード情報など機微な情報を扱うサイトでは、去年の時点で移行をすべきだったように思います。
無くならないカード情報流出事件
去年起こった大きな事件としては以下の2点を挙げておきます。
www.itmedia.co.jp
[http://www.itmedia.co.jp/enterprise/articles/1612/02/news106.html:title=ニュース - 資生堂子会社で個人情報流出の疑い、最大42万件 脆弱性突かれる:ITpro]
これらの事件を受けて、カード情報を扱う事業者に対してPCI DSSの取得を義務付ける流れになっており、
PCI DSSの取得が難しい事業者については、決済代行業者にカード情報を預けるように施策が進んでいたのですが、
決済代行業者による流出事故ということで、インパクトが大きいです。
Struts1.Xを使い続けるということ
今回、Struts2のみが対象となり、Struts1は無事だったので、Struts1なら大丈夫という間違った認識がありますが、
Sturts1は誰も公式にメンテナンスをしておらず、潜在的リスクはStruts2以上に存在します。
PCI DSSについて
今回、流出した情報の中にセキュリティコードがありました。
PCI DSSではセキュリティコードの保存は禁止されていますので、PCIDSSに準拠していなかったということになります。
情報処理安全確保支援士の活用
個人情報を扱うシステムの開発・運用に情報処理安全確保支援士を必須とするといいと思います。
まさにこういった自体を防ぐために、資格が整備されたはずです。
対象者4万人と言われる中、初回登録申請者数が4000人強にとどまったのは
飴とムチのムチのみが規定された現状では仕方ないと思います。
情報処理安全確保支援士の独占業務を作り、情報共有ネットワークの整備・高度な研修による実務的な技術を身に着けられるようにすれば、
取得希望者も増え、技術者の待遇向上にも寄与し、日本国内の情報システムのセキュリティ向上も図れるかと思います。
JAWS DAYS 2017に参加してきた #jawsdays
今年から仕事でAWSを使うようになって、
色々とAWSが気になってきているところに丁度イベントがあったため参加してきました。
朝から参加しようと思ってましたが、起きれず11時からのセッションの参加でした。
会場がビルかと思ってたら、低層の建物でびっくりしました。
参加したセッションは以下の通り
- 本当の敵は社内にいる!? ~攻める情シスが吠える座談会~
- ランチタイムセッション 株式会社はてな
- EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
- 金融クラウド&FINTECH最前線。~AWSで金融からイノベーション! 2017
- 武闘派CIO3人が、ホンネで語るITの現実
- AWSデータベースアップデート 2017
本当の敵は社内にいる!? ~攻める情シスが吠える座談会~
企業の情シスの担当者が、如何に社内システムをクラウドに移行させていくか、移行させるにはどんな苦労があるかっていう話でした。
ランチタイムセッション 株式会社はてな
ベストトーカーそーだいさんの話。
PostgreSQLの話ではなく、Mackerelの話でした。
グラフは綺麗で直感的でした。
リソース監視に重点置いたシステムなのかなって思いました。
僕は今、業務では開発者目線でElasticsearch + Kibanaでの可視化を進めてますが、
Mackerelは運用目線ではよさげです。
EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
これはあんまりおもしろくなかったですね。
Excelから脱却と銘打っておきながら、Excelファイル生成してたので良く分かりませんでした。
DevOpsも今まで手動でやってきたことが自動でできるよで、話が止まってたので、
いや、それじゃ昔と変わらないじゃん・・・って。
金融クラウド&FINTECH最前線。~AWSで金融からイノベーション! 2017
FinTechって独り歩きしてて、何がFinTechなのかってのがいまいち分かってないので参加してみました。
なお、僕の理解としては、
「今まで金融機関の中で閉じていた大量のデータを集計・分析した結果をAPIを通じて公開する」だと思っています。
肝はAPIですね。
クレジットカードの決済や残高照会、振込なんかは今までもあったので、違うかなと。
それ+αを金融会社がどう提供できるかって話ですよね。
FinTech企業のこれから
電子決済代行業者
- 登録制の導入
- 情報の適切な管理
- 業務管理体制の整備
⇒金融機関も上記の状況を確認する
武闘派CIO3人が、ホンネで語るITの現実
CIO三人がのっけからお酒飲み始めて笑いました。
以下の名言は肝に銘じます。
新しいことやりたいなら、勝手に初めて客を付けてきてから社内にやりたいって言え
ただやりたいってだけなら、会社からは今の仕事をやれとしか言われない。
客を付けてきてから言えば、会社もNoとは言えないってことでした。
いや、これ実践したいと思いますよ。
Kibanaで円グラフ(Pie Chart)を作って可視化する #elasticsearch
リソースの可視化、ログデータの投入と来たら次はログデータ自身の可視化ですね。
Kibanaでは様々なグラフや表が用意されており、
それらを組み合わせることで目的に合わせたダッシュボードを作ることができます。
今回は、ログ内のUser Agent情報から、デバイス・OS・ブラウザの割合を円グラフ(Pie Chart)を使って可視化してみたいと思います。
User Agentは以下のサイトを参考にさせていただきました。
歌うキツネ : User-Agent (ユーザー エージェント) 一覧
こんな感じのログを適当に作成
2017-03-02_23-11-00.123,hostap1,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393 2017-03-02_23-12-00.123,hostap1,Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Logstashの設定ファイルはこんな感じ。
input{ file{ path => "C:\dev\ua.txt" start_position => "beginning" } } filter{ csv{ columns => ["processingDate","hostName","userAgent"] separator => "," } date{ match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"] timezone => "Asia/Tokyo" } useragent{ source => "message" prefix => "ua." } mutate{ remove_field => ["host","userAgent"] } } output{ elasticsearch{ hosts => ["<Elasticsearchが動作しているサーバのIPアドレス>"] index => "useragent-%{+YYYYMMdd}" } }
filter-useragent
今回の肝。
指定されたソースからUserAgentの書式を見つけて、
いい感じに各項目にパースしてくれるフィルターです。
prefixで接頭語を指定できます。この場合"ua."で始まる項目がuseragentフィルターで作成された項目ということになります。
mutate-remove_field
出力項目から指定された項目を除外するフィルターです。
userAgent項目はパースされており、2重になるので省いています。
Kibanaで可視化
さて、Kibanaで可視化してみましょう。
Index Patternsの追加
Kibanaのメニューの一番下にある「Management」をクリックし、
表示された項目の「Index Patterns」をクリックします。
そして「+Add New」ボタンをクリック。
Index name or patternに今回設定ファイルで設定した”useragent-YYYYMMdd”が対象になるように
「useragent-*」を入力し、「Create」ボタンをクリック。
Discoverでの表示
Kibana画面右上の時計マークをクリックして、対象のログの時間に合わせます。
Kibanaのメニュー「Discover」をクリックし、
左上に表示されているindexパターンの「▼」を押して「useragent-*」を指定します。
するとまあなんということでしょう。
ログデータが表示されますね。
円グラフ(Pie chart)の作成
さて遂に本題の可視化です。
今回はどんなOSが使われているのか、
そしてそのOSからどのようなブラウザを使用していて、
ブラウザのバージョンはいくつなのかといったことを可視化していきたいと思います。
Visualizeの作成
Kibanaメニューの「Visualize」をクリックし、
表示された中から「Pie chart」をクリックします。
index選択で今回追加した「useragent-*」を選択します。
OSの分布を可視化する
Split Slices選択して以下のように入力します。
- Aggregation : Terms
- Field : ua.os.keyword
- Order By : metric:Count
こんな感じにOS毎の円グラフが作成されます!
円グラフの分割しブラウザの使用状況を可視化する
OS分布を可視化したら次はOS毎の使用ブラウザを可視化します!
「Add Sub buckets」から再度「Split Slices」を選択し以下のように入力します。
- Aggregation : Terms
- Field : ua.name.keyword
- Order By : metric:Count
ブラウザのバージョンを可視化する
最後にブラウザのバージョンを可視化しましょう。
サポート外のブラウザ使ってアクセスしてる人、
サポート外したいのに、まだ使ってる人が多いブラウザなどが可視化出来ますね。
「Add Sub buckets」から再度「Split Slices」を選択し以下のように入力します。
- Aggregation : Terms
- Field : ua.major.keyword
- Order By : metric:Count
まだIE8を使ってる人がいる、ということを可視化出来ました!
作ったグラフは画面右上の「Save」ボタンから保存することができます。
Logstashで一部がkey value形式のログをパースする #elasticsearch
Logstashで取り込むログは多種多様で、色々なテンプレートも用意されています。
ただ、アプリケーションログはそれぞれのアプリで独自のフォーマットで記述されていることが多いと思います。
今回、ちょっと複雑なログの形式として
項目が":"区切りで且つKey=Value形式の項目があるログをパース出来たので、方法を残しておきます。
ログはこんな形式です。
2017-02-26_11-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45 :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=OK 2017-02-26_12-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45 :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=NG 2017-02-26_12-45-00.123:hostap1:bwegaakJkLKJIHGKGGIkjahawlwk2134:10000123:IN :OAUT45 :OperateId=1Create&0&ProcessId=d5aaa2jgkjgghhhglalkg&ProcessPass=234resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226 2017-02-26_12-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45 :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=NG
処理日付、サーバ名、セッションIDが":"区切りで、最後の項目にPOSTされた内容がKey=Value形式で記述されています。
Logstashの設定ファイルは以下のような感じで記述しました。
input{ file{ path => "C:\dev\inout.txt" start_position => "beginning" } } filter{ csv{ columns => ["processingDate","hostName","sessionId","merchantId","inout","functionId","telegram"] separator => ":" } date{ match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"] } kv{ source => "telegram" field_split => "&?" } mutate{ remove_field => ["telegram","@version","host"] } } output{ elasticsearch{ hosts => ["<Elasticsearchが動作しているサーバのIPアドレス>"] index => "inout-%{+YYYYMMdd}" } }
filter-kv
ここが今回のキモです。
csvフィルターで":"に項目分けをされた項目を
sourceで指定し、field_splitで"&?”を指定することでKey=Valueをそれぞれの項目として抽出できます。
(dateフィルターで、同じようなことをしているので、もしかしたら出来るかなとやってみたら見事出来ました。)
Elasticsearchに投入しKibanaで見てみます。
項目数に差異があっても同じインデックスに格納されていますね。
便利!
検索もきちんと出来ます。
WindowsでLogstashを使ってElasticsearchに既存のログを投入する #elasticsearch
Elasticsearch、Kibanaの環境を構築したら、
次はログを流し込んで可視化したくなるのが人情ですよね。
ということで出番なのがLogstash。
以下のURLからダウンロードできます。
通常の使い方はLogstashを各種サーバにインストールし、
リアルタイムでログを転送し可視化するのですが、
まずは手始めとして、手元にあるログをElasticsearchに転送してみようと思います。
動作させている環境は以下の通りです。
OS:Windows 10 Pro
Java: Oracle JDK 8u121
Logstash:5.2.1
Elasticsarch,Kibanaは以下の記事で作成したものを使っています。
mamelog.hatenablog.jp
Logstashとは
公式ページには以下の記述があります。
つまるところ、いろんな形式のデータを一か所に集約できる凄いツールってことですね。
使い方
ダウンロードしてきたzipファイルを適当な場所に解凍します。
(C:\dev配下に解凍しました。)
テストデータを用意する
こんな感じの:区切りのデータを用意しました。
2017-02-26_00-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901 2017-02-26_03-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901 2017-02-26_06-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:10.901 2017-02-26_09-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,251:0.901 2017-02-26_12-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,51:0.901 2017-02-26_15-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:DELETE:0,551:0.901 2017-02-26_18-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901 2017-02-26_21-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:UPDATE:0,311:0.901
設定ファイルを書く
Logstashは大きく分けて、
input,filter,outputの3つの処理に分かれます。
こんな感じで書いてみました。
input{ file{ path => "C:\dev\request.txt" start_position => "beginning" } } filter{ csv{ columns => [ "processingDate", "hostName", "sessionId", "merchantId", "functionId", "operateId", "internalProcessingTime", "externalProcessingTime"] separator => ":" } date{ match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"] timezone => "Asia/Tokyo" } mutate{ convert => { internalProcessingTime => float externalProcessingTime => float } remove_field => ["telegram","@version","host"] } } output{ elasticsearch{ hosts => ["<elasticsearchが動作しているサーバのIPアドレス>"] index => "request-%{+YYYYMMdd}" } }
input-file
pathに取り込みたいファイルのパスを書きます。
start_positionはファイルのどこから取り込み対象にするかを指定します。"beginning"を指定することでファイルの最初から取り込めます。
デフォルトではLogstash起動後に更新された行から取り込み対象にするようです。
filter-csv
CSV形式のファイルを取り込むときに使用します。csvと書いていますが、今回のようにseparatorに任意の文字を指定することで
カラム区切りでない文字列にも対応できます。
columusに区切ったそれぞれの値の項目名を指定します。
date
様々な書式の日付の文字列をパースします。
mutate-convert
指定しないと全て文字列になってしまうので、数値の項目は明示的に変換をかける必要があります。
floatやintegerが指定可能です。
数値にしておかないと、平均や合計、最大値最小値などの値を可視化出来なくなるので注意が必要です。
Logstashを起動する
コマンドプロンプトでLogstashをインストールしたフォルダ直下のbinフォルダに移動します。
cd C:\dev\logstash-5.2.1\bin
以下のように設定ファイルを指定して起動します
logstash -f request.conf
しばらくすればElasticsearchにデータが投入されKibanaで見ることができます。
テストデータの通り、3時間おきの計8件のデータが投入されました。
インデックス名と@timestampの日付がずれる
時差、タイムゾーンの問題だと思うのですが、
設定ファイルでインデックス名をパラメータ指定していると、午前9時までのデータが前日のindex名で格納されてしまいます。
indexを日付指定で削除するような運用をしていきたいのですが、
この状態だと日付をまたいでデータが削除されてしまうので困っています。