Quantcast
Channel: なからなLife
Viewing all 174 articles
Browse latest View live

MySQLでmetadata lockにハマりやすいパターン

$
0
0

しばらくブログエントリあげてませんでしたが、引き続きMySQL関係のお仕事していたので、復活弾もやっぱりMySQLネタです。

そもそも

「metadata lockって何よ?」
とか
「Waiting for Table metadata lockでハマったらどうしたら良いの?」
って話は、過去にエントリ
MySQL5.6以前でmetadata lock発生の犯人を後追いする - なからなLife
にあげているので、そちらも参照してください。


とはいえ長いので、簡潔に書くとこんな感じです。

metadata lockって何よ?

metadata=テーブル定義情報のWrite Lock。DML同士は共有、DDLとは排他。

Waiting for Table metadata lockでハマったらどうしたら良いの?

select * from information_schema.innodb_trxを見て、TRX_STARTED(トランザクション開始時刻)が異常に古いものからKillする。


マリパターン

で、本題に入ります。
「metadata lockで処理が詰まるケースにハマリやすいパターンってこんなだよね」
っていうのを、経験にもとづいて整理してみました。


他にもこういうのあるぜ、ってのがあったら、是非教えていただきたいです。

パターン1.「autocommit=OFF」

普通そうするよね、とは思うけど、これが引き金の一つです。

そもそも、「autocommit=ON」だったら、SQL単位でしかmetadata lockを取らないから、そんなに長引くこともない!?
(1日かけても帰ってこないようなSELECTを投げるケースを除く)


「autocommit=ON」にすると、複数SQLをまとめて1つのトランザクションとしたい場合には、明示的にSTART TRANSACTION宣言しないといけないので、「autocommit=OFF」の時のような暗黙のトランザクションの閉じ忘れ、というケースは防げそう。

パターン2.「ポーリング」

「キューテーブルをでポーリング(SELECT)して、処理対象があったら~」という仕様にもとづいてプログラムを書くと、「処理対象がなかったら何もしない」となるケースが多いです。
本当に何もしないと、「autocommit=OFF」ではSELECTによる暗黙のトランザクションが開始され、そのまま放置されることになります。


実践ハイパフォーマンスMySQL 第3版にも記載されている通り、「キューテーブル」は性能面の担保にも苦労するが、トランザクションの閉じ忘れも引き起こしやすいですね。

パターン3.「コネクションプーリング」

トランザクションをオープンしたままコネクションをプールに戻されると、原因特定がめんどくさいことになります。
コネクションをプールせず、都度確立、都度切断していれば、中途半端なものを引き継ぐこともないですね。

新規コネクション確立のオーバーヘッドが気にならないレベルの性能要件であったり、多重度の制御がうまくできていて無謀な同時接続数にならないのであれば、コネクションプールを使わない、という選択することもアリですね。


パターン4.「定時洗い替え」

ジョブスケジューラを利用して、テーブルの再作成(DROP/CREATE)、テーブルのリセット(TRUNCATE)、パーティション切り替えなどのDDLを発行すると、metadata lockによるトラブルの引き金となりやすいです。


そもそも、「Waiting for Table metadata lock」はDDLを発行したタイミングで起こる話なので、メンテナンス作業以外で頻繁に発生するとしたらコレ。


じゃあヤメロ、っていう話にはならないはずなので、「これを仕様に組み込んでいる場合、トランザクションの閉じ忘れにはより一層気をつけろ」ということ。


なお、Oracleで、DDLが同様のメタデータ情報のロック衝突を起こした場合、デフォルトだとリソースビジーで即エラーが帰ってきます。
MySQLにも同じような挙動をさせたい(DDLでロック待ちさせたくない)場合、「lock_wait_timeout=1」を設定します。
最小1秒、最大&デフォルト31536000(1年)です。

DDL以外にも影響するので、公式ドキュメント参照のこと。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.1.4 サーバーシステム変数



まとめ

MySQLにアクセスするコードを書くプログラマは「トランザクション」を意識しよう。


つまりはそういうことです。

MySQLトラブルシューティング

MySQLトラブルシューティング


RDSのStopからの復旧ログが不思議

$
0
0

RDSの「stop」がサポートされました。

AWS Relational Database Service(以下RDS)は、いわゆるDatabase as a serviceで、EC2とは違い、インスタンスのStop/Startが出来ず、停止・起動に相当するのはTerminate(最終スナップショットを取得して、インスタンス自体は破棄)/Launch(スナップショットからのリカバリ)しかサポートしていませんでした。

それが2017年6月より、Stop/Startをサポート開始となりましたが、「最大で連続7日間」という制約があります。

で、早速Stopさせてみて、7日後に起動することを確かめました。

7日後の復旧時のログが、なんか違和感。

環境特定されるとマズイ環境なのでキャプチャやめて、ログの「システムノート」の転記だけにするけど、10分くらいかけて、以下のようなログが出てました。

DB instance is being started due to it exceeding the maximum allowed time being stopped.
Recovery of the DB instance has started. Recovery time will vary with the amount of data
Recovery of the DB instance is complete.
DB instance started
DB instance restarted
DB instance shutdown
DB instance restarted
Backing up DB instance
Finished DB Instance backup
AWS Management Console上では、時系列逆順=直近から降順で表示されますが、ここでは時系列そのままで記載しています)

なんで上げたり下げたりしてるのでしょう?不思議。


とはいえ、仕様どおりインスタンスは起動されました。
いや、7日以上眠らせておいてもよいのだけど。

Amazon Web Services完全ソリューションガイド

Amazon Web Services完全ソリューションガイド

さすがにこの話は最近すぎる機能なのでどの本にも書いてないか。

JavaのOutOfMemoryErrorを追いかけてみた

$
0
0

だいたいのことは、ネットに書いてある

Java自体、すでに歴史ある技術ですし、今回のOutOfMemoryErrorも、その解析方法も確立されているようで、ネットでかなりの情報が手に入り、10年くらい前、Java1.4の案件でちょっとコード書いた程度にしかJavaと接点のない私でも理解できました。

インターネットすばらしい。

一方、本職アプリケーションエンジニアで今回の案件もJavaのコードをバリバリ書いてる人たちがたくさん集まっているはずなのに、なんでその情報に一番最初にたどり着くのが自分なんだろう、みたいなモヤモヤもあったりして。



事の発端

DB屋、プラスアルファでDB以外のインフラも対応、という感じのポジションなので、アプリケーションエンジニアが書いたコードのことはよくわからない立場だったのですが、DBに接続して来るJavaのプログラムがOutOfMemoryErrorに悩まされていたので、一緒に格闘してました。

アプリケーションエンジニアに開発したソースコードを確認してもらっても、オブジェクト参照の解放漏れはないようだけど、環境によって、ほぼ毎回発生する環境と、一回もエラーにならない環境がある、とのこと。

エラーになるケースでは、CPU利用率が跳ね上がる、ということで、以下の仮説、確認ポイントを設けて、調査することに。

  • 多分GCがCPU利用率を引き上げてる原因だよね。
  • GC発生してるのにOutOfMemoryErrorが出るってことは、意図せず解放できていないやつがいるよね。
  • エラー発生時にログに出力されているStackTraceでは、どこでエラーが発生したかはわかるけど、それって犯人じゃなくて被害者の可能性もあるよね。
  • 具体的にはメモリ(JavaHeap)に何が乗っているかわからないと、特定難しいよね。

DB観点で言うと、クライアントサイドの話なのでDBサーバーサイドの設定は基本的に関係なし、あるとすれば投入データの差異か、クライアントパラメータの設定か、クライアントライブラリのバグでメモリリーク?か、という感じで、どれも可能性が薄いなあと思いつつ、いい機会なのでJavaの事もお勉強です。

Javaといえば、GC(garbage collection:ガベージコレクション

Javaといえば、確保したメモリの解放をVMにおまかせして、使わなくなったメモリ領域はGCによって回収、再利用するというのが、Javaが出てきた当初から?の仕様です。
文字通り「ゴミ拾い」。

RDBMS脳でいうと、「バッファプール」と似たような考え方でOK。

特にMySQLで例えるなら、新しいデータはバッファプールのYoung領域に一旦置いて、Young領域があふれるタイミングでまだ使っているものはOld領域へ、そうじゃないものはプールから破棄(開放)、を繰り返すイメージですね。

ただし、GCはあくまで「使わなくなった領域」を回収するわけで、「もう使わないよ」っていうことを忘れていると、GCで回収できる領域が減って、いずれOutOfMemoryError(VMが確保した領域では処理できない)が発生してしまいます。

このあたりのイメージは、
Java技術最前線 - 「メモリーを意識してみよう」第2回 GCの仕組みを理解する:ITpro
とか
HP-UX Developer Edge - Javaのかなめ、「ガベージ・コレクション」をやさしく学ぶ・前編 | HPE 日本
とかの図解がわかりやすいので、軽く読んで頭に入れておくと良いですね。

解析に使うのは「GC Log+GC Viewer」「jstat」「HeapDump+Eclipse Memory Analyzer (MAT)」

GC Log

GC Log」はJavaVMにおいて、ガベージコレクションが発動されたタイミングでログに出力されるものです。
テキストファイルに出力されるので、その量を見るだけでも発生頻度が分かりますが、GC Viewerというツールに読み込ませると、時系列での変化をグラフィカルに表示されるのでわかりやすいです。
解析したいJavaアプリケーションの起動オプションとして指定してあげるだけで出力するようになりますが、「GC Log出力先に、そのユーザでの書き込み権限が必要」という条件に注意。

使い方は
最強のJVMチューニング・ツール: GCログを可視化するGCViewerとリモート接続でプロファイリング可能なVisualVM
とか
JavaVMのGCログ出力とGCViewerについて - TASK NOTES
あたりを参照してください。

jstat

「jstat」は、JavaVMのHeapの状況を確認できるツールで、OSレベルでいうvmstatコマンドのようなものです。

解析したいJavaアプリケーションのプロセスID(psコマンドやjpsコマンドで確認)を指定します。

また、オプションに実行間隔をミリ秒単位で指定できます。
GC logがGC発生時のみ記録されるのに対し、GC未発生の状況も収集できますので、時系列でのヒープ内部の状況変化をより正確に把握できます。

ファイルにロギングさせたものをExcelに貼り付けてグラフ化してあげると見やすいですね。

HeapDump

「Heap Dump」は、JavaVMのヒープの状態をそのままDumpしたものです。
jmapコマンドやkill -3で出力することができるのですが、特にHeapの解析が必要となるOutOfMemoryErrorに関しては、「このエラーが発生したらHeapDumpを出力する」という指定を、Javaの起動オプションとして設定することができます。

GC Logと同様に、出力先の書き込み権限に注意するひつようがあるのと、ヒープの内容をまるごと出力するのでHeapサイズ指定(Xms、Xmx指定)が大きい場合に注意が必要です。

ダンプファイルはそのままでは読めませんので、ツールを使うことになります。

Eclipse Memory Analyzer(通称「MAT」)

JavaのHeap Dumpを読み取り、解析できるツールで、Eclipseプラグインおよびツール単体での使用が可能です。

ツール自体もJavaで動きます。大きなダンプファイルを解析する場合には、ツール自身のXms、Xmxを大きめに指定する必要がありますが、そもそもOSが32bit版Windowsだったりすると大きなダンプファイルを読めなかったりします。
*1

OutOfMemoryError発生時のHeap Dumpを読み込むことで、Heap Dumpに残っている=GCでも回収できなかったJavaのオブジェクトがクラスレベルで特定できます。

その専有量のランキング、表面上必要な量と、つかみっぱなしになっている量の差、掴んでいるオブジェクトに格納されている具体的な値、そのオブジェクトを参照しているオブジェクトのスタックトレースが確認できます。

メモリリークの「疑い」があるオブジェクトの候補を抽出する機能なども存在します。

HeapDumpとEclipse Memory Analyzer諸々のお話は、このSlideshare
OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方
が非常によくまとまっています。


なお、なぜMA「T」なのか、わかりません。

VisualVM

GC Viewerの参照先で紹介した
最強のJVMチューニング・ツール: GCログを可視化するGCViewerとリモート接続でプロファイリング可能なVisualVM
に記載がありますが、実行中のJVMをグラフィカルにモニタリングできるツールのようです。

今回はこのツール自体を知らなかったこともあり、使いませんでしたが、OutOfMemoryErrorでHeapDumpを発生させる前から「どのクラス/オブジェクトがヒープ領域を食っているか」が見えるようですので、もっと早くに原因を掴めたかもしれません。

解析結果

今回のケースでは、JavaVMを監視してアプリケーションパフォーマンスの情報を収集、管理する「APM:Application Performance Management」のエージェントプログラムが、SQL文を格納しているオブジェクトへの参照を掴んでいて、GCの発生時に解放ができず、OutOfMemoryErrorを引き起こしていました。

APMエージェント的には「管理サーバーに情報を送って解放」という流れだったのかと思いますが、流量が多すぎたのか、転送・解放が追いつかなかったようです。「メモリリークだった」という確証には至っていません。

アプリケーションエンジニアにとっても自分たちでコードを書いた部分ではなかったので、特定するのにかなり手間取りましたが、HeapDumpをEclipse Memory Analyzerで解析した所、見かけないクラスがSQLを格納したオブジェクトを掴んでいて「誰だコイツは!?」ってなった次第です。


Javaパフォーマンス

Javaパフォーマンス

*1:自分の環境はWindows7 64bitで12GBのメモリを積んでいますが、VMとツールの相性?からか、ツールが32bit版しか起動できず、その影響でXmxを2GBまでしか指定できませんでした

LANケーブルのツメ折れ対策品も意外と役立つ件

$
0
0

だいぶ前に上げたエントリの影響で、LAN関係のお買い上げがボチボチ観測される弊ブログです。
atsuizo.hatenadiary.jp

エントリ自体が3年前ってのが驚きですが、この零細ブログでも今も月に数個はお買上げ頂いている模様。
詳しく調べてないけれど、金額ではなく個数ベースでは「LANポートキャップ」が最も出ているんじゃないかというくらい。



ツメ折れ対応の歴史(自分史)

昔:LANケーブルのツメが折れたら我慢して使い続けつつ、ネットワーク越しの作業中にケーブルが抜けてストレスがMaxになって買い替え。

ちょっと前:ツメが折れにくいケーブルの登場。小売店等ではかなり普及してきたけど、まだまだ従来型のツメのLANケーブルを使っている所が圧倒的多数だよなー。会社のやつとか勝手に変えられないし。

最近:ツメ補修グッズあるじゃん!(いつからあるのかは知らない)


そんなオレを見ている玄人:「自作すれば大した問題じゃねえよ」


そう、LANケーブルを自作できる人は、「こんなもんいらねえよ」って思うかもしれません。
でも、LANケーブル自作できる人って、かなり少数派。


私も一時期は工具一式(カシメ、チェッカー、コネクタ)持っていましたが、壊れたPCを回収業者に引き取ってもらう際に、「まだ使えますよ」って言いつつ一緒に引き取っていただきました。

サンワサプライ カシメ工具(ラチエツト付き) HT-500R

サンワサプライ カシメ工具(ラチエツト付き) HT-500R



LANケーブル自作できるといっても、仕事で日々やっているわけではなく、熟練してるわけでもないので、「作業工数と品質」を考えたら、割に合わないんです。

買ってしまえば単価100円程度。人間、100円分の工数で何ができる?と。


壊れたツメを補修してくれるグッズ

基本的に、ツメが折れてしまったケーブルに対してかぶせるだけです。ケーブル本体の加工等は一切不要です。

どの商品も、10個売りで単価100円切るくらいですね。もっと少ない個数でも売っているものがありますが、単価が100円を超えるくらいには割高になります。

サンワサプライ RJ-45プラグSOS ADT-RJ45SOS-10

サンワサプライ RJ-45プラグSOS ADT-RJ45SOS-10

爪折れLANプラグの修復 プラグSOS 10個 青

爪折れLANプラグの修復 プラグSOS 10個 青


注意点としては、「ツメ折れ予防型のLANケーブル」でツメが折れてしまった場合に、ものによってはうまくハメられなさそうな構造になっていることでしょうか。
今のところ、運良くそういう組み合わせには出会っていませんが、念のため。

Kibanaを立ててみた

$
0
0

きっかけ

なんかKibanaが流行っているみたいなので、今更感はありますが、とりあえずいじってみることにしました。


多分、AWSでフルマネージドにおまかせの方がラクチンなんだろうなー、と思いつつ、RDSと同様、ローカルにそのまんま立ててイロイロ比較することになるんじゃないかと思うので、あえてローカルに立てて一通り触ってみることにしたわけです。


今回いじるターゲットとしては、こんな感じです。
1エントリで全部書くと大変なことになりそうなので、いくつかに分けて書きます。


なので、前にやった
atsuizo.hatenadiary.jp
のときみたいな、連載っぽい感じになります。



共通事項

エントリを分けて書きますが、特記がない限り、以下の環境で作業したものとなります。

Windows7OracleVMVirtualbox+RHEL6系+ElasticStack5.5(Fluentd/Embulkは執筆時点で最新のStableなもの)


正確にはOracleLinux6.9を使っていますが、たまたま手元にあったイメージがそれだったというだけで、同バージョンのRedhatCentOSと読み替えてもらって問題ないです。


目次

こんな感じになる予定です。
この冒頭エントリを書いている時点で、Fulentdのところまではやっているのですが、最後の方までたどり着けるか自信ない。。。とくにS3にやるところは、認証周りがめんどくさくなってローカルのLinuxじゃなくてEC2にIAMロールつけて済ませてしまうんじゃないかと。


  • はじめに(このページ)
  • Kibanaって何よ、って話
  • Kibana+Elasticsearchセットアップ
  • エージェント概要
  • Metricbeatを使ってみる
  • Packetbeatを使ってみる
  • Filebeatを使ってみる
  • Logstashを使ってみる
  • Fluentdを使ってみる
  • Embulkを使ってみる
  • JDBCでInputする
  • S3へOutputする
  • AmazonElasticsearchService(ES)で実現する
  • Kibanaでのグラフ作り
  • おわりに


Elasticsearch単体としての深い所に踏み込んでみたい気持ちもありますが、Kibanaを使うっていうのが目的だと、当面は「器」でしかないので、余力が出てきたら挑戦したいと思います。



当面、エントリ末尾にはこちらの本を紹介していきますが、この本の内容をなぞったものではありません。
次のエントリ「Kibanaって何よ、って話」でも触れますが、この本は2014年8月発行で、elasticsearchのバージョンが1.2.1ベースでの解説です。

このエントリ執筆に使った、現時点の最新のバージョンは5.5ですから!

Kibanaって何よ、って話 - Kibanaを立ててみた

$
0
0

外から見たKibana

www.elastic.co

があっさりとしていますが、要はオープンソースのログデータ解析/可視化ツールです。基本的に、リアルタイム検索エンジン「Elasticsearch」とセットで使われます。


独自のNode.js Webサーバーも付いている、ということで、別途Webサーバーを立てて設定、といった手間はないのがお手軽です。


特に時間軸のログの分析・可視化に強い印象です。

構造から見たKibana

KibanaはあくまでUI部分であり、表示の元となっているデータは、同社のElasticsearchに溜め込んだデータ(インデックス)となります。


Elasticsearch自身は、Restful APIと多用な言語に対応したライブラリを提供し、ApacheLuceneをベースとした高速でスケーラブルな検索・分析プラットフォームです。


Elasticsearchにデータを溜め込むところも、APIとライブラリを経由しますが、それに特化したエージェントプログラムを使うことが一般的*1であり、ElasticsearchとKibanaの開発元が提供するLogstashや、Elasticsearch同様のデータ検索・分析基盤を提供するTresure dataが提供するOSSであるfruentdなどを使います。


RDBMS脳からすると、
「ElasticsearchがDB本体で、KibanaはBI/OLAPツールのフロント、Logstash/fluentdはリアルタイムで動くETL」
くらいのイメージで良いかと思います。


Kibanaと自分

Kibanaというプロダクトは、2013年頃よりOSSとして開発、その開発者が後Elastic社に入社、といった経緯を辿っていますが、私がKibanaについて認知したのは2016年後半くらいからです。それまで、私の中では「存在していなかったもの」扱いですね。


Kibanaはログ分析・解析と同時に、サーバーリソースモニタリングにも使われるのですが、当初はそのサーバーモニタリングの観点でしか見てなかったので、正直、「(黒背景時代の)見た目カッコイイ」以外に、「これまであったCactiやZabbixと何が違うん?」という印象しか持っていませんでした。特にこのところはAWSばかり触っていることもあって、リソースモニタリングだけなら標準でセットアップ不要のCloudwatchがついてきますので、CactiやZabbixすら立てる必要がないわけで、尚更、その必要性がピンと来ないわけです。


ログ解析~可視化、という観点でも、RDBMS脳なので、「先にある程度集計した数値データをグラフにするだけならなんでも同じなのに、なんでKibanaそんなに持ち上げてるん?」という印象でした。


いや、まだその印象が拭いきれていないのですが、1つ意識が変わったことは、「(集計済)数値をそのままグラフにするだけなら、めんどくさいだけ。寧ろ未加工のデータの可視化にこそ本領を発揮するもの」ということです。


そしてそれは、自分が現在本業としているRDBMSが比較的苦手(集計・分析は関数等で簡単にできなくはないけど処理が重い)としている部分であり、RDBMSとElasticsearch/Kibanaは補完関係にある、ともいえます。


そんな感覚を持ちつつ、AWSが割と早い時期から「Amazon Elasticsearch Service(Amazon ES)」としてをKibanaとセットで提供していることへ関心が強くなったこともあり、今回、Kibanaを触ってみようと思った次第です。


Kibanaを取り巻く環境

Kibanaにかぎらずelasticの製品は公式ドキュメントがすべて英語ということで、翻訳に頼るか、先人(ブログ)に頼る事になりますが、ググってヒットする情報にバージョンが書いてないことが多く、プロダクトの進化が早いこともあって、割りと古い情報が多いです。


黒い背景のグラフでかっこいい感じの画面が、Kibana v3系でしょうか。その後Kibana4系でヘッダ部に黒を残しその他白背景、5系でほぼ真っ白になった感じですので、1つの目安になるかと思います。*2


それにしても、公式ドキュメントが英語のみというのはツライ。
書籍も日本語のものは、2014年3月と古い

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

が1冊あるだけ、あとはムックでですね。後者の方が、今回のコンセプトにはかなり近いですが、これも2014年8月。。。

フォーラムに日本語専用の板があるので、こちらを有効活用しましょう。
具体的に行き詰まっているところを示せば、結構な確率で回答していただけるようです。


そういえば、10年くらい前、ElasticsearchのベースになっているApacheLuceneを触る事になった際、日本語書籍は

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

の1冊しかなかったなー。当時扱ったバージョンとそんなに開きがなかったこともあって、めっちゃ読み込んだ思い出。

Elasticsearh&Kibana、5系以降で日本語の書籍出ないかなぁ。。。
本じゃなくてもいいけど、日本語で、割と深いところまで言及している、まとまった資料が欲しい。。。


Google翻訳に助けてもらいながら公式ドキュメントを読み進めていけばなんとかなるものの、やっぱりネイティブな言語で読めるってのは色々とラクだよね。


といった感じでグダる話は終わりにし、次回から、具体的に環境を作っていきます。

*1:エージェントの性能が要件を満たせない場合、独自に開発することも可

*2:デフォルトが変わった、というだけです。v5.5で昔ながらの黒画面を使いたい場合、既存のダッシュボードであれば、dashboard>個別のダッシュボード選択 > Edit > Option > Use dark themeをONとし、新規ダッシュボードすべてに適用したいのであれば、Management > Advanced Settings >dashboard:defaultDarkTheme をTrueにします。

Kibana+Elasticsearchセットアップ - Kibanaを立ててみた

$
0
0

まずは器を用意する

Kibanaを使うには、分析・可視化対象のデータを入れる器としてのElasticsearchを立て、それを参照させるようにKibanaを立て、また、器にデータを入れる仕組みを用意する、という順番で進んでいきます。

よって、ここでは、器としてのElasticsearch、器の中身を覗き込むKibanaの環境設定を行います。

ElasticSearch

公式ドキュメントのありかはここです。
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/install-elasticsearch.html


なお、この先も公式ドキュメントのURLを貼っていきますが、「/5.5/」の部分がバージョン番号になります。この数字の部分を、「/current/」とすると、その時点の最新GAバージョンのドキュメントが表示されます。



それにしても、プラットフォーム、インストール手段も豊富ですね。



アップグレードメンテナンスがし易いように、yumリポジトリを用意して、インストールすることにします。

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/rpm.html#rpm-repo

sudo vi /etc/yum.repos.d/elasticsearch.repo

以下内容を添付
[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

sudo yum -y install elasticsearch


サービス登録をして、起動しておきます。
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/rpm.html#rpm-running-init

sudo chkconfig --add elasticsearch
sudo service elasticsearch start


動作確認は、こんな感じで。
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/rpm.html#rpm-check-running

curl GET 'localhost:9200/'


とりあえず初回起動までに必要な手順はほんとうにコレだけでした。


次にKibana

同じく、アップグレードメンテナンスがし易いように、yumリポジトリを用意して、インストールすることにします。


マニュアル上ではこちらになります。
https://www.elastic.co/guide/en/kibana/5.5/rpm.html#rpm-repo

sudo vi /etc/yum.repos.d/kibana.repo

以下内容を添付
[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
ここまで

sudo yum -y install kibana


サービス登録をして、起動しておきます。
https://www.elastic.co/guide/en/kibana/5.5/rpm.html#rpm-running-init

sudo chkconfig --add kibana
service kibana start


動作確認は、GUI付きのLinuxを使っているので、こんな感じでブラウザから

http://localhost:5601

こうじゃっ。


え、もう普通にKibanaの画面見れたよ!
なお、Kibana5.5からは、ブラウザでクセスすると最初にサーバーサービスのステータスを表示してくれるようになったみたいです。


その後、しばらくハマる - 起動できなくなる!

ElasticSearchはデフォルトだとローカルホストからしか参照できないので、とりあえずVirtualBox内だけでの参照はツライ。

ってことで、ホストマシン側からブラウザで参照できるように、と思って設定開始。

/etc/elasticsearch/elasticsearch.yml

で、ネットワークを制限しているところを

#network.host: 192.168.0.1
network.host: 0.0.0.0

としてサービス再起動してあげればよいでしょうよ、と思ったら、起動プロセスで落ちるようになりました。


ログに出ていた手がかりはコレ

[1] bootstrap checks failed
[1]: max number of threads [1024] for user [elasticsearch] is too low, increase to at least [2048]

いろいろ探し回った挙句、ElasticSearch側の設定ではなく、ElasticSearchの要件にもとづいて設定する「OS」側の設定。


公式ドキュメントにもとづいて
/etc/security/limits.conf
に以下を追加してあげました。

elasticsearch    hard    nproc           2048
elasticsearch    soft    nproc           2048
elasticsearch    -       nofile          65536

今回の直接原因は上2つ。だけど、ネットワークの制限を緩めなければ、普通に起動するのよね。

3つ目は、調べたついでにドキュメントに記載があって、むしろnprocよりも重要であるかのように書いてあったので、追加。


次に、Kibana側もネットワーク制限しているので、

/etc/kibana/kibana.yml

#server.host: "localhost"
server.host: "0.0.0.0"

として再起動。
こちらはすんなり起動して、リモートホストからアクセスできました。


サーバーサイドの構築手順はここまでです。


ここから先は、器にデータを流し込まないと、何も進みません。
なので、いろいろなエージェントを使ってElasticsearchにデータを流し込む話に移ります。


エージェント概要 - Kibanaを立ててみた

$
0
0

データ収集の先鋒をどうするか

概要のところで説明したとおり、エージェント経由でElasticsearchに情報を収集するのですが、選択肢が結構多いですね。


よくある事例、記事だと、日本ではFluentdが圧倒的に多くて、次にLogstash。


FluentdもLogstashも、ファイルへの出力をリアルタイム監視して、設定ファイルにもとづいて変換して、Output先に送り届ける、ってのは同ですね。
CloudwatchLogsに慣れている身としては、awslogsと同じだなーとか思いつつ。


どちらもプラグインがたくさんあって、Input元、Output先との接続のコネクターがたくさんあるようなので、どっちを使っても出来ることに違いはなさそう。


シェアだとFluentdのほうがありそうなんですけど、elastic社「ELK Stack」って呼んでアピールしてます。「E=Elasticsarch、L=Logstash、K=Kibana」です。


これに倣って、日本で人気の高いFluentdを使った構成を「EFK」って呼ぶ人もいる模様。


なお、LogstashとElastic社が提供するスタック図において、Logstashと同じレイヤーに、Beatsというものがあります。
一概に説明しにくいのですが、「Logstashと同様にElasticsearchにデータ転送するだけでなく、Logstashに転送して、Logstashで加工・フィルタリングしてからElasticsearchに転送することも可。」というツールでした。

  • Logstash:フィルタ、加工など柔軟な設定が可能なエージェント。
  • Beats:あらかじめ用意されたセットにもとづいて情報収集、転送するエージェント。複雑な処理が必要な場合、Logstash経由で転送させる。Kibana上で表示させるためのテンプレートも含んでいる。


といった感じでしょうか。


同じレイヤといいつつ、中間レイヤとしても機能するので、Elastic社の図を鵜呑みにするとちょっとつまづきますね。


次回以降、Beats、LogstashといったElastic公式のスタック準拠で挑戦した後、人気の高い人気のFluentd、Fluentdと同じTresure Dataが提供するEmbulkも扱ってみたいと思います。

まとめ

Elasticsearch+Kibanaを使う際の、クライアントサイドモジュール

  • Beats:Elastic社が提供。「データシッパー(Data Shipper)」と呼ばれ、Elasticsearchに対するシンプルなデータ転送を行うエージェント。フィルタリングや加工など複雑な処理を施す場合、Logstashを間に噛ませる。
    • Filebeat:(ログ)ファイル
    • Metricbeat:システムや各種ミドルウェアのリソースメトリクス
    • Packetbeat:ネットワークパケット
    • Winlogbeat:Windowsイベントログ
    • Heatbeat:稼働状況監視
  • Logstash:汎用的なデータ収集エージェント。Elastic社が提供。
  • Fluentd:汎用的なデータ収集エージェント。Input-Output双方をプラグイン形式で拡張できる。TresureData社が提供。日本ではLogstashより人気が高い模様。
  • Embulk:バルクインサート用エージェント。TresureData社が提供。


Metricbeatを使ってみる - Kibanaを立ててみた

$
0
0

Metricbeatとは

システムの統計情報(Metric)を収集するbeatです。


いわゆるOSで取得できるCPUやメモリなどの情報、および、モジュールを通してApacheMySQLその他の統計情報も、ちょっとした設定をするだけで収集できる様になっています。


今回は、SystemとMySQLの情報をMetricbeatsで取得し、Kibanaのダッシュボードに表示する所を目指します。

MetricBeatのセットアップ

ダウンロードとインストー

https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-installation.html
に行くと、「yum使えるなら最新版がもっと簡単に使えるぜ(キリッ」って誘導されるので、そっちのURL参照で。
https://www.elastic.co/guide/en/beats/metricbeat/5.5/setup-repositories.html#_yum


内容を見ると、Elasticsearch本体と同じリポジトリのようなので、今回はElasticsearchとBeatsが同じ場所にある構成のときには特にすることはなく、いきなりyumでインストールできます。実運用の場合には、当然離れたところにbeatsをインストールすることになるかと思いますので、その際にリポジトリを登録することにしましょう。

sudo yum -y install metricbeat
設定ファイル

https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-configuration.html
Dockerじゃないので、こちら。

/etc/metricbeat/metricbeat.yml


デフォルトだと、

-moudle:system

という定義で、

  • cpu
  • load
  • filesystem
  • fsstat(FileSystemのサマリ)
  • memory
  • network
  • process

あたりは取ってくれるようになっています。


ApacheとかMySQLとかいったmodule定義はまた後ほどということで、まずはデフォルトで稼働確認するところを目指します。


取り急ぎ動かす上では出力先を指定することくらい。


今回はLogstashで加工することもなく、Elasticsearchに直接送り込みます。また、BeatsのインストールマシンとElasticsearchのインストールマシンも同じです。


リモートのElasticsearchに送り込むときは、

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["localhost:9200"]

の部分を該当サーバーに向けてあげるだけですね。


これはAWS Elasticsearch Serviceに送り込む時もEndpointを

 hosts: ["https://XXXXXXXXXX.ap-northeast-1.es.amazonaws.com:443"]

のように指定してあげれば良いようです。

テンプレート

https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-template.html
に書いてあるとおりなんですけど、どうやら、デフォルトでテンプレート「packetbeat.template.json」をロードしてくれる模様。

もちろんカスタム可能ですが、一旦、ここには手をつけずに、ロードしてみます。

curl -H 'Content-Type: application/json' -XPUT 'http://localhost:9200/_template/metricbeat' -d@/etc/metricbeat/metricbeat.template.json

このURLで、「/etc/metricbeat/metricbeat.template.json」の内容に基づくテンプレート「packetbeat」を登録する、という意味になるようですね。
消すときは

curl -XDELETE 'http://localhost:9200/metricbeat-*'

で削除できます。

beatsの起動、テスト

https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-starting.html

sudo /etc/init.d/metricbeat start


MetricBeatは開始したらすでにシステムの情報を取り始めているので、結果を見るだけです。

curl -XGET 'http://localhost:9200/metricbeat-*/_search?pretty'

このコマンドで、登録がうまくいっているかが分かります。

Kibanaダッシュボード設定

あらかじめ、Kibanaのダッシュボードテンプレートも用意されているので、それを適用してみます。
https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-sample-dashboards.html


yum/rpmインストールの場合のインストール先へ移動しつつ、インポートスクリプトを実行します。

cd /usr/share/metricbeat/
./scripts/import_dashboards


BeatsとElasticsearch/Kibanaが別々の場所にある場合は

./scripts/import_dashboards -es http://Elasticsearchのホスト:9200 -user user -pass password

のように、-esの後ろに宛先URL(elasticsearchのポート指定)をし、認証が必要な場合はそれぞれ引数付与してあげます。

scriptsの下にありますが、このimport_dashbordsはバイナリファイルみたいですね。なので、コレ自体のカスタマイズはできません。



Kibanaで確認

ブラウザで

http://localhost:5601

にアクセスすると、DiscoverにMetricbeatで収集した情報にもとづくグラフが表示されます。


MySQLの情報を取得する

デフォルトでは、Systemモジュールだけが有効、それ以外は、無効になっていますので、この設定を変更します。

個人的にはMySQLの状態監視に使いたい、しかもRDSということで、Elasticsearchからみても、Beatsから見てもリモートな監視対象となります。


そんな時の指定方法は、
https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-module-mysql.html
を参照しながら、

/etc/metricbeat/metricbeat.yml

metricbeat.modules:

の配下、「- module:system」と同じレベルのところに、「- module: mysql」の定義を追加することで対応できました。

- module: mysql
  metricsets: ["status"]
  hosts: ["tcp(RDSのエンドポイント:3306)/"]
  username: ユーザー
  password: パスワード

もちろん、使用するユーザーは、それなりにステータス情報が取れる権限を持っているものを使うことになります。

設定を入れたら、metricbeatを再起動させます。

sudo /etc/init.d/metricbeat start

これで、欲しかった情報がDashboardの 「Metricbeat MySQL」に表示されるようになります。


はっきり言ってしまうと、このダッシュボードで確認できる情報は、MySQL WorkbenchのDashboardと大差なかったです。
このテンプレでこの情報を表示するに至るまでの仕組みを理解し、より欲しい情報を思った通りに出力できるようになりたいものです。


MySQL以外のmoduleについても、
https://www.elastic.co/guide/en/beats/metricbeat/5.5/metricbeat-modules.html
に、使用方法が解説されています。


Packetbeatを使ってみる - Kibanaを立ててみた

$
0
0

Packetbeatとは

beatをインストールしたマシンのネットワーク・インターフェースを監視し、その内容を収集するbeatです。
ネットワークパケットの内容は、プロトコル毎に整理されます。


今回も、システム一般とMySQLの情報を取得することを目的としていますが、デフォルト設定でMySQL含む多くの情報を取得可能になっています。


ちょうど先日、elasticsearch勉強会で、elasticsearchの代理店でもあるアクロクエストさんがpacketbeatについてプレゼンを行い、構造とかチューニングポイントなどを解説してくれています。日本語でpakectbeatについてまとまった解説資料は世の中にとても少ないので、かなり貴重です。
https://www.slideshare.net/snuffkin/packetbeatio-t


PacketBeatのセットアップ

ダウンロードとインストー

https://www.elastic.co/guide/en/beats/packetbeat/5.5/packetbeat-installation.html#rpm-repo
に行くと、「yum使えるなら最新版がもっと簡単に使えるぜ(キリッ」って誘導されるので、そっちのURL参照で。
https://www.elastic.co/guide/en/beats/packetbeat/5.5/setup-repositories.html#_yum

内容を見ると、Elasticsearch本体と同じリポジトリのようなので、今回はElasticsearchとBeatsが同じ場所にある構成のときには特にすることはなく、いきなりyumでインストールできます。実運用の場合には、当然離れたところにbeatsをインストールすることになるかと思いますので、その際にリポジトリを登録することにしましょう。

sudo yum -y install packetbeat
設定ファイル

https://www.elastic.co/guide/en/beats/packetbeat/5.5/configuring-packetbeat.html


Dockerじゃないので、こちら。

/etc/packetbeat/packetbeat.yml


取り急ぎ動かす上では出力先を指定することくらい。


今回はLogstashで加工することもなく、Elasticsearchに直接送り込みます。また、BeatsのインストールマシンとElasticsearchのインストールマシンも同じです。


リモートのElasticsearchに送り込むときは、

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["localhost:9200"]

の部分を該当サーバーに向けてあげるだけですね。


これはAWS Elasticsearch Serviceに送り込む時もEndpointを

 hosts: ["https://XXXXXXXXXX.ap-northeast-1.es.amazonaws.com:443"]

のように指定してあげれば良いようです。


テンプレート

https://www.elastic.co/guide/en/beats/packetbeat/5.5/packetbeat-template.html

に書いてあるとおりなんですけど、どうやら、デフォルトでテンプレート「packetbeat.template.json」をロードしてくれる模様。

もちろんカスタム可能ですが、一旦、ここには手をつけずに、ロードしてみます。

curl -H 'Content-Type: application/json' -XPUT 'http://localhost:9200/_template/packetbeat' -d@/etc/packetbeat/packetbeat.template.json

このURLで、「/etc/packetbeat/packetbeat.template.json」の内容に基づくテンプレート「packetbeat」を登録する、という意味になるようですね。
消すときは

curl -XDELETE 'http://localhost:9200/packetbeat-*'

で削除できます。

beatsの起動、テスト。

https://www.elastic.co/guide/en/beats/packetbeat/5.5/packetbeat-starting.html

sudo /etc/init.d/packetbeat start

実際に、ネットワークトラフィックを発生させて、ネットワークパケットを拾わせてみましょう。

curl http://www.elastic.co/ > /dev/null

その後、

curl -XGET 'http://localhost:9200/packetbeat-*/_search?pretty'

で、データが登録されたことが確認できます。


Kibanaダッシュボード設定

あらかじめ、Kibanaのダッシュボードテンプレートも用意されているので、それを適用してみます。
https://www.elastic.co/guide/en/beats/packetbeat/5.5/packetbeat-sample-dashboards.html


yum/rpmインストールの場合のインストール先へ移動しつつ、インポートスクリプトを実行します。

cd /usr/share/packetbeat/
./scripts/import_dashboards


BeatsとElasticsearch/Kibanaが別々の場所にある場合は

./scripts/import_dashboards -es http://Elasticsearchのホスト:9200 -user user -pass password

のように、-esの後ろに宛先URL(elasticsearchのポート指定)をし、認証が必要な場合はそれぞれ引数付与してあげます。


scriptsの下にありますが、このimport_dashbordsはバイナリファイルみたいですね。なので、コレ自体のカスタマイズはできません。


AWS Elasticsearch ServiceにDashboardをインポートしたい場合、gitに公開されているものを使い、さらに出来上がったダッシュボードにカスタマイズしていくそうです。
https://github.com/elastic/beats-dashboards
こちらについては、現時点で内容は確認していませんが、ちょっと内容が古く、対応しているモジュールも少なそうです。。


Kibanaで確認

ブラウザで

http://localhost:5601

にアクセスすると、Discoverが選択されPacketBeatで収集した情報にもとづくグラフが表示されます。


MySQLが動いているサーバーに仕込んであげれば、「Mysql response times percentiles」「Most frequent MySQL queries」といった情報もとれます。
perfomance_schema使い慣れている人なら、あんまり必要ないかもしれませんが。


ユースケース的には、冒頭でお話したアクロクエストさんの資料にあるようなものが有力なのではないでしょうか。


Filebeatを使ってみる - Kibanaを立ててみた

$
0
0

Filebeatとは

beatをインストールしたマシン上のファイルを監視し、その内容を収集するbeatです。


いわゆる一般的なログファイル監視・収集ツールという位置付けですが、syslog、Apache2、nginx、mysqlについてはelasticsearchのインデックス生成テンプレート、および、kibanaダッシュボード生成のスクリプトが用意されている分、立ち上げがラク、といったところでしょうか。



FileBeatのセットアップ

ダウンロードとインストール

https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-installation.html#rpm-repo
に行くと、「yum使えるなら最新版がもっと簡単に使えるぜ(キリッ」って誘導されるので、そっちのURL参照で。
https://www.elastic.co/guide/en/beats/filebeat/5.5/setup-repositories.html#_yum


内容を見ると、Elasticsearch本体と同じリポジトリのようなので、今回はElasticsearchとBeatsが同じ場所にある構成のときには特にすることはなく、いきなりyumでインストールできます。実運用の場合には、当然離れたところにbeatsをインストールすることになるかと思いますので、その際にリポジトリを登録することにしましょう。

sudo yum -y install filebeat
設定ファイル

https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-configuration.html

Dockerじゃないので、こちら。

/etc/filebeat/filebeat.yml

収集対象については、デフォルトで/var/log/配下の「*.log」を監視するようになっています。

filebeat.prospectors:
- input_type: log
  paths:
    - /var/log/*.log
    #- c:\programdata\elasticsearch\logs\*


取り急ぎ動かす上では出力先を指定することくらい。

今回はLogstashで加工することもなく、Elasticsearchに直接送り込みます。また、BeatsのインストールマシンとElasticsearchのインストールマシンも同じです。


リモートのElasticsearchに送り込むときは、

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["localhost:9200"]

の部分を該当サーバーに向けてあげるだけですね。


これはAWS Elasticsearch Serviceに送り込む時もEndpointを

 hosts: ["https://XXXXXXXXXX.ap-northeast-1.es.amazonaws.com:443"]

のように指定してあげれば良いようです。

テンプレート

https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-template.html

に書いてあるとおりなんですけど、どうやら、デフォルトでテンプレート「filebeat.template.json」をロードしてくれる模様。

もちろんカスタム可能ですが、一旦、ここには手をつけずに、ロードしてみます。

curl -H 'Content-Type: application/json' -XPUT 'http://localhost:9200/_template/filebeat' -d@/etc/filebeat/filebeat.template.json

このURLで、「/etc/filebeat/filebeat.template.json」の内容に基づくテンプレート「packetbeat」を登録する、という意味になるようですね。
消すときは

curl -XDELETE 'http://localhost:9200/filebeat-*'

で削除できます。

beatsの起動、テスト

https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-starting.html

sudo /etc/init.d/filebeat start
curl -XGET 'http://localhost:9200/filebeat-*/_search?pretty'

このコマンドで、登録がうまく言っているかが分かります。

Kibanaダッシュボード設定

あらかじめ、Kibanaのダッシュボードテンプレートも用意されているので、それを適用してみます。
https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-index-pattern.html


yum/rpmインストールの場合のインストール先へ移動しつつ、インポートスクリプトを実行します。

cd /usr/share/filebeat/
./scripts/import_dashboards (-only-inde はいらない模様)

その後、/etc/filebeat/filebeat.ymlを編集して、使いたいmoduleに関する設定を追加する。
その際、同じ/etc/filebeat/にある「filebeat.full.yml」を参考(というかコピペして必要箇所を編集)にします。というか、filebeat.full.ymlに差し替えて必要箇所のみ有効化するのがよいでしょう。

Kibanaで確認

ブラウザで

http://localhost:5601

にアクセスすると、DiscoverにMetricbeatで収集した情報にもとづくグラフが表示されます。

MySQLの情報を取得する

ここでは、「-module:mysql」のブロックを有効にしてみます。

- module: mysql
  # Error logs
  error:
    enabled: true

    # Set custom paths for the log files. If left empty,
    # Filebeat will choose the paths depending on your OS.
    var.paths: [エラーログのファイル出力先]

    # Prospector configuration (advanced). Any prospector configuration option
    # can be added under this section.
    #prospector:

  # Slow logs
  slowlog:
    enabled: true

    # Set custom paths for the log files. If left empty,
    # Filebeat will choose the paths depending on your OS.
    var.paths: [スロークエリログのファイル出力先]

    # Prospector configuration (advanced). Any prospector configuration option
    # can be added under this section.
    #prospector:

MySQLのエラーログ、スロークエリログに対応しているのですが、両ログファイルのファイルパスを指定するようになっています。よってRDSに対してはこのままでは使えません。上記はオンプレにyumMySQLをインストールした場合のデフォルトパスを記載しています。


設定を入れたら、metricbeatを再起動させます。

sudo /etc/init.d/metricbeat start

これで、欲しかった情報がDashboardの 「Metricbeat MySQL」に表示されるようになります。

MySQL以外のmoduleについても、
https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-modules.html
に、使用方法が解説されています。

雑感

登録されてるテンプレート以外の任意のファイルを監視させるのに使えるのか使えないのか、正直良くわかりませんでした。
それなら「Logstash使え」で終了なのかもしれません。


登録されているテンプレに対応したログファイルの取込をやりたいなら、あっというまにセットアップが終わるので、かなりお手軽ですね。


Logstashを使ってみる - Kibanaを立ててみた

$
0
0

Logstashとは

さまざまなデータソースから情報を収集し、さまざまなstash=格納庫にデータを投入する機能を提供するツールです。


Elaticsearchの文脈で語る上では、「Elasticsearchにデータを投入するためのエージェント」という位置付けになりますが、Logstash自身としては、プラグインを通じてデータベースやSlack、メールや、AWS S3など様々な対象にアウトプットすることができます。


beatsとの大きな違いは、収集した情報を転送する前に加工することができる、という点です。


今回は、MySQLに対して定期的に問い合わせた「SHOW GLOBAL STATUS」の結果をファイルに出力したものをInputとし、Elasticsearchに投入するケースに挑戦します。
また、beatsと異なる機能である加工処理も入れてみたいと思います。

Logstashのセットアップ

ダウンロードとインストール

Logstashの利用にはJava8が必要なので、事前にインストールした後、Logstashのインストールを進めます。

https://www.elastic.co/guide/en/logstash/5.5/installing-logstash.html#_yum

例によってyumリポジトリからのインストールなのですが、ドキュメントの内容を見ると、Elasticsearch本体と同じリポジトリのようなので、今回はElasticsearchとLogstashが同じ場所にある構成のときには特にすることはなく、いきなりyumでインストールできます。実運用の場合には、当然離れたところにLogstashをインストールすることになるかと思いますので、その際にリポジトリを登録することにしましょう。


yumリポジトリの設定が整ったら、インストールをします。

sudo yum -y install logstash


公式ドキュメントによると、ここで一旦、簡単な稼働試験を行うことになります。
https://www.elastic.co/guide/en/logstash/current/first-event.html


logstashのインストール先ディレクトリにあるモジュールを実行しつつ、Input-Fileter-Outputのパイプラインを直接指定して実行する試験です


yum/rpmインストールだと以下のコマンドで実行することになりますが、起動にそこそこ時間がかかるので、
「The stdin plugin is now waiting for input:」
が表示されるまでしばらく待ちましょう。

/usr/share/logstash/bin/logstash -e 'input { stdin { } } output { stdout {} }'


「The stdin plugin is now waiting for input:」の後ろにも何か表示が出るかもしれませんが、そこは気にせずに、「Hello world」でもなんでもよいので入力してEnterキーを押し、入力した文字列の前にタイムスタンプが付加されることを確認してください。


確認が取れたら、「CTRL-D」で終了します。



設定ファイル

公式ドキュメントだと、このあと、「サンプルのログファイルをFilebeatからLogstash経由でElasticsearchに登録」というチュートリアルが入りますが、ここでは省略します。
サンプルデータが提供されていますので、一連の流れを体感するためには、一度やってみるのも良いと思います。
https://www.elastic.co/guide/en/logstash/current/advanced-pipeline.html


こちらでは、チュートリアルを飛ばして、Logstashで直接ファイルを読み取ってElasticsearchに登録するための流れを追いたいと思いますが、そのために編集していく設定ファイルの話に触れます。


このあたりのお話です。
https://www.elastic.co/guide/en/logstash/5.5/config-setting-files.html


まず、Logstashの設定は2段構えです。

  • logstash自身の設定

/etc/logstash/
logstash.yml :logstash自身の起動構成情報。パイプライン定義の位置なども管理。
jvm.options :logstash自身はJavaVM上で稼働するため、そのJVMのオプションを管理。
log4j2.properties:logstash自身のログ出力を管理するlog4jのオプションを管理。
startup.options :logstashのインストール構成オプションを管理。

  • /etc/logstash/conf.d/

XXX.conf:個別のパイプラインIn-Processing-Outの設定


今回のような使い方の場合、logstash.ymlはデフォルトのまま、必要な設定は/etc/logstash/cond.d/XXX.confを作っていく事になります。

なお、あとでもう一度出てくる話題ですが、logstashをサービスとして起動する際、/etc/logstash/conf.d/の中のファイルをすべて読み込むので、バックアップファイルなど余計なファイルを置かないように、との注意書きがドキュメントの中にあります。


先に、Logstashをserviceとして動かせるように、と思ったらハマった!

RHEL6系なら「service(または/etc/init.d) 」、RHEL7系なら「systemctl」と思っていて、serviceコマンドを叩いたら、「そんなサービスいねえぞコラ!」、/etc/init.d/logstashを叩いたら「そんなファイルが見つからねーぞコラ!」って怒られました。実際ファイル探したら、ないのよね。ググると悲鳴(英語)がたくさん。


結論としては、

service(init.d)じゃなくて、「initctl」で実行しろ!
https://www.elastic.co/guide/en/logstash/5.5/running-logstash.html#running-logstash-upstart
の意訳

とのことでした。サービス起動のための設定ファイルは「/etc/init/logstash.conf」です。


よくわからないのは、
initctl status logstash
を何度か実行すると、その度にpidが違う、というところでしょうか。


また、先に紹介したチュートリアルをやっているとき、filebeat ->ポート5043 -> logstashという動きをするのですが、双方起動しているのにfilebeatからlogstashへの接続がポート閉塞でリトライ発生しているログが見受けられるのも、仕様がよく分かっていません。


なお、この際、気をつけなくてはいけないのは

サービス(initctl)で起動する時、パイプライン定義のファイルは「/etc/logstash/conf.d/」の配下に配置したすべてのファイルを読み込むので、バックアップとかゴミファイルも置いてはいけない。
https://www.elastic.co/guide/en/logstash/5.5/config-setting-files.html#_pipeline_configuration_filesから超訳

ということです。


Logstashのパイプライン設定

サービス起動の話で遠回りしてしまいましたが、パイプライン=Input - Fillter - Outputの設定です。


文字通り、入力とフィルタリング(及び加工諸々)と出力の定義で、ファイルの基本構造もとてもシンプルです。

input {
    # input setting
}
filter {
    # fillter setting
}
output {
    # output setting
}

それぞれにプラグインがあり、プラグインごとにサポートするパラメータが違ったりスルので一概に説明は出来ませんが、公式ページで見られるLogstashの図解のイメージを表現する場所が、まさにこの設定ファイルである、と言って良いでしょう。
https://www.elastic.co/jp/products/logstash



MySQLで、定間隔でSHOW GLOBAL STATUSをロギングしたファイルをElasticsearchに登録する流れを追ってみたいと思います。


ということで、
input : データソースとなるファイルに関する情報
output : elasticsearch(hostname:9200)に関する情報
となります。


サービス起動設定済なので、/etc/logstash/conf.d/の下に、XXX.confとして作ります。


以下内容のシェルを、cronで1分間隔で実行するものとします。

mysql -u root -pパスワード -h ホスト名 -e ”SHOW GLOBAL VARIABLES;”  | sed -e 's/\t/\" \"/g' | sed -e 's/^/\"/g' | sed -e 's/$/\"/g' | sed -e "s/^/$(date '+%Y\/%m\/%d %H:%M:%S') /g" >> /var/log/mysql_global_status.log

logstashのconfを以下のように作成します。
/etc/logstash/conf.d/mysql_global_status.conf

input {
    file {
        path => "/var/log/mysql_monitor/show_global_status.log"
        start_position => "beginning"
        type => "mysql-status"
    }
}
filter {
    if [type] == "mysql-status" {
        grok {
            match => { "message" => '%{DATESTAMP:date} "%{DATA:Variable_name}" "%{INT:Variable_value}"' }
        }
    }
  }
output {
    if [type] == "mysql-status" {
      elasticsearch {
        hosts => [ "localhost:9200" ]
        index => "lgs-mysql-status-%{+YYYY.MM.dd}"
        manage_template => false
        template_name => "mysql-status"
      }
    }
#     stdout { codec => rubydebug }
}

最低限の指定しかしていませんが、各ブロックについて解説します。


■Input
最も汎用的な「file input plugin」を使います。
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html

loglotatedのように、ログローテションしてファイル末尾に数字を加えていくような仕組みにも対応しています。


■Filter
ちょっとクセがありますが、任意でログ出力フォーマットを定義したようなファイルに値しては、汎用的に解析できる「Grok filter plugin」を使います。

ファイルから読み込む行が、どのようなフォーマットで出力されているかを定義していきます。
今回のファイルのフォーマットは
「日付時刻(yyyy/mm/dd hh:mm:ss ”ステータス名(Variable_name)” ”ステータス値(Value)”」ですので、Grokの書式定義体にもとづいて「型:名称」を宛てて、上記のように指定します。

LogstashのGrokフィルタで使用できる定義体は、
https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns
を参照します。

Grokフィルタの構文チェックは、
http://grokdebug.herokuapp.com/
に、読み込ませたいデータと、Grok定義を入力すると、そのフィルタでデータをどう読み込まれるかが確認できます。

KibanaにGrok Debuggerが付いた、とのことですが、有償プロダクトである「X-Pack」に含まれる、ということらしく、試していません。

ちなみに Grok Debugger は X-Pack の機能としてリリースされました。X-Pack ってあの有償プラグインの?と思われる方いらっしゃるかもしれませんが、Grok Debbuger は BASIC サブスクリプションから利用できますので無償で利用可能です。
http://dev.classmethod.jp/server-side/elasticsearch/x-pack-grok-debugger/

はい、わけがわかりません。


クラスメソッドさんは普段から良質な情報を提供してくださっていますし、Elasticの代理店でもあるので、ウソ言っているとは全く思っていませんが、公式ページからもそんな風に読み取れる部分がなかったです。<追記>
https://www.elastic.co/subscriptions
こちらに、Subscriptionの種類と対応の一覧表があるのですが、「Basic-Free」のところに「Grok Debugger」のチェックが入っていましたので、X-Packを入れつつ無償で使える!ということでした。


日本語サイト
https://www.elastic.co/jp/subscriptions
だと「Grok Debugger」の表記がないので混乱していましたが、単に更新が間に合ってないだけのようです。




■output
Elasticsearchにデータを登録するので、「Elasticsearch output plugin」を使います。
登録先となるElasticsearchのサーバーの場所と、格納するindex名を指定します。


設定ファイルを保存後、いきなり起動させるのではなく、confファイルに構文エラーがないか、チェックすることができます。

/usr/share/logstash/bin/logstash -f confファイルの場所 --config.test_and_exit

括弧のとじ忘れ、誤字脱字で存在しないキーワードを指定、などといったものを検出し、該当箇所を案内してくれます。


正しい構文であれば、実際にLogstashを起動させると、Elasticsearchにindexが作成されてデータが投入されますので、Kibanaから「Management」>「Index Pattern」>「Create Index Pattern」の画面からIndex name or patternに「"lgs-mysql-status-*”」を入力してindexが検出されることを確認しましょう。そのままCreateすれば、「Discover」>「gs-mysql-status-*」を選択することで、実際に登録されてきたデータを確認することができます。




また、このままだと、どうやらValueの値が文字列として処理されてしまうようです。
文字列で取得された値は、条件検索して検出した件数(count)で処理する分には使えるのですが、その数字そのものをメトリクスとしてグラフに反映することが出来ないようなので、数値として扱えるようにしてあげます。


Beatsのところでtemplate.jsonを適用したのと同じように、テンプレートを定義してあげます。


今回はインデックスを「 index =>"lgs-mysql-status-%{+YYYY.MM.dd}"」で定義していますので、「"lgs-mysql-status-”」に該当するインデックスへの登録にはこのマッピングを適用する、というテンプレートを登録します。

curl -XPUT localhost:9200/_template/mysql-status -d '
{
  "template": "lgs-mysql-status-*", 
   "mappings": {
     "mysql-status": {
       "date_detection": false,
       "properties": {
         "@timestamp": {
           "type": "date"
         },
         "Variable_name": {
           "type": "text"
         },
         "Variable_value": {
           "type": "long"
         }
       }
      }
   }
}'

実際には、一度自動登録で作成されたマッピングを問い合わせて、出力結果を編集して、再登録という形でおこなっています。


コマンド一発でのテンプレート登録になっていますが、.jsonファイルに保存して、コマンドからファイルを読み込んで登録するのでも構いません。


仕様なのか、時間の関係なのか、うまく反映されないので、Logstashの停止、インデックスの削除、テンプレートの適用、Logstashの停止、Kibana->Managemen->Index PatternsからIndexの再検出、という手順を踏んでいます。

複数ファイルを取り扱う場合の注意!

前述の設定ファイルの記述において、Inputでtypeを定義し、Filter、Outputでif [type]=={}ブロックで記述しています。


同じ環境で1ファイルしか扱わないのであれば省略可能ですが、複数のファイルを扱い、それぞれファイルフォーマットが違ったり、Filterでの取り扱い方法、Output先のインデックスが異なる場合などは、インプットするファイル毎に、typeを使用して識別子をつけて上げる必要があります。


Logstashをサービスとして起動する際には/etc/logstash/conf.d/配下のファイルをすべて読み込むので、定義自体は1つのファイルの中で複数書いても、複数のファイルに分けて書いてもよいです。ただし、全体として1つの定義として機能する=複数ファイルに書いた場合、マージして1つのファイルになったものと同様に処理されるので、1ファイル内に1つしかInput/Fileter/Outputを書いていないからと言ってTypeを定義していないと、ファイルから取り込んだデータがeralticsearchに登録されるタイミングで自動マッピングが作動する際に、それぞれのFilterによるフォーマットの解釈結果がマージされたインデックスが作成される事があります。ですので、「あとで2つ目のファイルを扱うことになったから、最初に登録した設定ファイルも書き換えなくては!」とならないよう、常にType定義とIfブロックを使う習慣をつけておいたほうが良いかと思います。


公式ドキュメントでもifブロックを省略した記述例ばかりですので、それに倣ってしばらく試していたのですが、上記の他にもう1つ設定ファイルを作っていて、ずっとそちらと混在したマッピングが生成される状況から抜け出せず、Elasticの中の人にTwitterから公式フォーラム(https://discuss.elastic.co)経由で解決支援していただきました。


Elasticさんすばらしい。これからお客さんその他ネット界隈にプッシュしていきます!





fluentdを使ってみる - Kibanaを立ててみた

$
0
0

fluentdとは

別名「td-agent」であることからわかるように、Tresure Dataのフロントとなるログ収集エージェントという位置付けですが、やはり様々なプラグインを通じて柔軟な処理が可能となっており、こと日本においては、ログ収集管理のエージェントとしてLogstashより人気があるようです。


Elasticsearch+Kibanaと組み合わせるにあたり、Logstashを使う場合にELKと読んでいたのに対抗して、EFKと呼ぶ人もいるようです。


Logstashで扱ったMySQLのSHOW GLOBAL STATUSの結果ファイルを、今度はfluentd(td-agent)でelasticsearchに登録する流れを追ってみることにします。

手順に入る前に、うまく行かなかった話

Logstash編と同様、MySQLの「GLOBAL STATUS*1」を一定時間間隔で出力したファイルを使っているのですが、ダブルクオートで囲んだ数字は、elasticsearch側で文字列として認識されてしまい、なぜかMappingでは変換できませんでした。fluentdのformat定義の正規表現その他の設定で、うまく””を剥がして数値として扱うことができませんでした。


数値を文字列のママ認識させると、Kibanaで数値として分析できなくなってしまいます。


そんなわけで、ログ出力の仕様の時点で、数字はダブルクオートで囲まないように出力させた上で、formatの定義で正規表現を使ってうまく拾ってあげるようにして対応しました。

Logstashで読み込ませた時のログの例

2017/07/11 18:05:01 "Aborted_clients" "5269"
2017/07/11 18:05:01 "Aborted_connects" "190"
2017/07/11 18:05:01 "Binlog_cache_disk_use" "30646"
2017/07/11 18:05:01 "Binlog_cache_use" "162597"
2017/07/11 18:05:01 "Binlog_stmt_cache_disk_use" "0"
2017/07/11 18:05:01 "Binlog_stmt_cache_use" "2894"

fluentdで読み込ませた時のログの例

2017/08/07 13:48:01 Aborted_clients	40422
2017/08/07 13:48:01 Aborted_connects	422
2017/08/07 13:48:01 Binlog_cache_disk_use	32159
2017/08/07 13:48:01 Binlog_cache_use	472229
2017/08/07 13:48:01 Binlog_stmt_cache_disk_use	0


この辺、Logstashでは全然苦労しませんでした。。。。


Fluentdでそんなに苦しむことないよ、って話を知っている人は教えて欲しいです。


セットアップ

まず、Logstashがjavaベースであるのに対し、fluentdはrubyベースですが、fluentdの一式の中にRubyが含まれています。


Logstashも簡単でしたが、fluentd(td-agent)も、インストールするまでのところは非常に簡単です。elasticsearchへの登録にはプラグインを追加でインストールする必要があるので、そこまでの流れは以下の通りとなります。

curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh
/opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-elasticsearch

たったこれだけですね。これだけで、serviceとしても起動可能となります。

設定

Logstashと同様に、In-加工-outについて設定ファイルに定義をしていきます。


インストールした際に、すでに/etc/td-agent/td-agent.confにはデフォルトおよびサンプルの定義がたくさん書いてありますが、この末尾に追記する形で、以下内容を書き加えます。
fluentd自身の挙動を決める部をそのまま流用するため、解説省略します。



<source>
  type tail
  format /(?<logtime>\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}:\d{2}) (?<Variable_name>[^ ]*\t)(?<Variable_value>[^ ].*$)/
  path /var/log/mysql_monitor/show_global_status_2.log
  pos_file /tmp/mysql-status_2.pos
  read_from_head true
  tag mysql.status
</source>
<match mysql.status>
  type elasticsearch
  host localhost
  port 9200
  logstash_format true
  logstash_prefix fld-mysql-status
  type_name fld-mysql-status
</match>

構造をLogstashと比較すると、fluentdではブロックでLogstashのInputとFilter相当の定義を、ブロックでOutputの定義を行います。


fluentdの汎用ファイル読み取りでは、「tail」というtypeを使用します。
文字通りtailコマンドのようにファイルの末尾への情報追加を監視して処理をします。


Logstashでgrokを使用していたところを正規表現で定義します。
正規表現ですが、フィールド名(例:?)を合わせて指定する構文なので、そのまま正規表現を使用する訳にはいきません。
このfluentd用の正規表現形式のままチェックできるサイトがありますので、こちらで検証するのが良いかと思います。
Fluentular: a Fluentd regular expression editor




LogstashでInputのなかにTypeを定義、FilterとOutputでもTypeに応じた定義を記述したのと同様に、fluentdでは、Soruceでtagを定義し、matchのブロック宣言の中でそのtagを指定することで対応関係を表現、処理を制御します。


matchに定義するアウトプット先としてelasticsearchを使用するにあたり、定義する情報はLogstashとほぼ同じです。


ただし、別途インストールするプラグイン、という位置付けであるため、そのリファレンスはソースコードと一緒にgithub上で公開されています。(プラグイン紹介自体はfruentd本体のドキュメントとして存在しており、そこにelasticsearchプラグインgithubへのリンクもあります)

GitHub - uken/fluent-plugin-elasticsearch



データが取り込まれることを確認したら、マッピングが期待している通りになっているかを確認します。
おそらく、Logstashの時と同様に、「Variable_Value」が数値ではなく文字列扱いになってしまっています。まずはmapping定義を修正して、取り込み直してみましょう。


もしmappingだけでは修正できない場合、Logstashと同様に送り込む側、mapping両方修正が必要になるようです。mappingはLogstashのものを流用するとして、Fluentdの設定側を以下のように設定しますが、これにもプラグインが必要です。

/opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-typecast
vi /etc/td-agent/td-agent.conf

以下を追加
<match mysql.status>
  type typecast
  item_types Variavle_value:integer
  prefix typed
</match>

以下を修正
<match mysql.status> -- 修正前
  type elasticsearch
 ・・・

<match typed.mysql.status>  --修正後
 ・・・

事例を調べていて「fluent-plugin-typecast」を使うケースが多かったので、それに従ったのですが、fluentd公式サイトのプラグイン一覧では「fluent-plugin-filter_typecast」がCertifiedプラグインとして取り上げられており、その設定方法も違うので注意が必要です。


毎回紹介している、こちらの本、Fluentdについては、構成方法、運用ノウハウなど細かく紹介しています。


また、今回のようにEFK構成することをメインテーマに置いた書籍が2017年9月に発売されるということで、こちらも期待です。

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

*1:SHOW GLOBAL STATUS または SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS

Embulkを使ってみる - Kibanaを立ててみた

$
0
0

Embulkとは

「Fruentdのバッチ版」と呼ばれることが多いツールで、FruentdやLogstashが逐次生成されるデータをストリームとして扱って転送するのに対し、Embulkはほぼ変化のないデータの塊を転送するのに向いているエージェント、という位置付けになります。


開発しているのもFluentdのメインコミッターの一人ということで、Fruentdとセットで語られることが多いです。
ですが、今のところFluentdはTresuredata公式での取扱があるのに対し、Embulkはそのポジションには至っていない、関連OSSの1つ、という扱いのようです。


FluentdやLogstashと同様、プラグインによって様々なInput、Filter、Outputに対応しており柔軟に構成を作ることが可能となっています。


今回は、CSVファイルの中身を直接elasticsearchに取り込むところにチャレンジしてみます。


使用するのは、執筆時点の最新版「0.8.28」です。

セットアップ

EmbulkはソースおよびドキュメントともにGithub上で公開されています。
GitHub - embulk/embulk: Embulk: Pluggable Bulk Data Loader. http://www.embulk.org



EmbulkのドキュメントQuickStartに従って進めてみます。


今回はLinux上に立てますので、
https://github.com/embulk/embulk#linux--mac--bsd
に基づいて

curl --create-dirs -o ~/.embulk/bin/embulk -L "https://dl.embulk.org/embulk-latest.jar"
chmod +x ~/.embulk/bin/embulk
echo 'export PATH="$HOME/.embulk/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

としたあと、サンプルCSVを扱うコマンドを実行します。

embulk example ./try1
embulk guess ./try1/seed.yml -o config.yml
embulk preview config.yml
embulk run config.yml

これで、サンプルのcsvファイルと、それを取り扱うための設定ファイル(.yml)が設定されます。


このコマンドの意味を、ちょっとだけ説明しておきます。


「embulk example」コマンドでは、カレントディレクトリに「try1」ディレクトリを生成、設定ファイル「seed.yml」と、「csvディレクトリにtar.gzで固めたサンプルデータファイルを生成します。


「embulk guess」コマンドでは、「seed.yml」をもとに、完全な形式の設定ファイル「config.yml」をカレントディレクトリに生成します。


「config.yml」には「decoders: - {type: gzip}」が保管されていることから、「try/csv/」の中にtar.gzで保存されているファイルを処理できるようになっていることも見えます。


「embulk preview config.yml」は、いわゆるDry Runです。設定にもとづいてInputファイルの中身を正しくパース出来ているかを確認できます。ここでは、サンプルのcsvファイルの中身が4行、表示されます。


「embulk run」で、設定ファイルに基づいて実行されます。処理過程のログの中に、先程のpreviewで確認できた4行が表示されます。



さて、Embulkからcsvファイルの中身を読み込んでelasticsearchへ送り込んでKibanaへ表示させるのが目標ですが、Embulkのドキュメントの中に、ピンポイントでコレについて解説したページが用意されています。
http://www.embulk.org/docs/recipe/scheduled-csv-load-to-elasticsearch-kibana5.html


ご丁寧にElasticsearchのダウンロード&インストールの話から書いてありますが、こちらはすでに完了していますので、EmbulkでElasticsearchにOutputさせるプラグインの導入のところから進めます。
Scheduled bulk data loading to Elasticsearch + Kibana 5 from CSV files — Embulk 0.8 documentation


embulk gem install embulk-output-elasticsearch

このelasticsearch用プラグインにかぎらず、embulkはgemコマンドでプラグインを追加できるようになっています。


次に、csvファイルとseed.ymlを用意し、設定を行うのですが、先程使用したサンプルを流用したいと思います。

mkdir ./try2
mkdir ./try2/csv
cp ./try1/csv/* ./try2/csv/
vi ./try2/seed.yml

# 以下内容を記述
in:
  type: file
  path_prefix: "/root/./try2/csv/sample_"
out:
  type: elasticsearch
  index: embulk
  index_type: embulk
  nodes:
    - host: localhost


rootでやってますwというところは気にせずに、手続きを進めます。

embulk guess ./try2/seed.yml -o config.yml
embulk preview config.yml
embulk run config.yml 


これで完了です。


なお、「定期的に実行し、かつ前回からの差分(増えたファイル)のみ取り込みたい」という場合、

embulk run config.yml -c diff.yml

と実行すると、最後に取り込んだファイル名を「diff.yml」に保持するようになり、次回は(アルファベット順で)そのファイル以降から取込を行ってくれます。
このコマンドをcronなどに指定すれば、スケジューリング実行が可能となります。


このように、リアルタイム性を重視するならFluentdやLogstash、バッチによるバルクロードで対応するならembulkを使うなど、要求シーンによって使い分けが可能です。


サンプルCSVではない任意のCSVファイルを扱う場合、「embulk guess」で生成するconfig.ymlの結果から「columns:」を確認した後、意図した型に変換できていない所を含めてseed.ymlに記述してから、再度config.ymlを生成してあげましょう。


以下は、今回自動生成されたサンプルcsvについて「embulk guess」で生成されたconfig.ymlの中に生成されている列定義です。seed.ymlには全然書いていないところから、ここまで自動生成してくれます。

    columns:
    - {name: id, type: long}
    - {name: account, type: long}
    - {name: time, type: timestamp, format: '%Y-%m-%d %H:%M:%S'}
    - {name: purchase, type: timestamp, format: '%Y%m%d'}
    - {name: comment, type: string}


Embulkの公式の英語ドキュメント、コマンドラインオプションの説明があまりないのですが、日本人には嬉しいことにQiitaにめっちゃ詳しく書いてありますので、こちらを頼りにすると良さそうです。
qiita.com



あらたに取り込んでみたいcsvファイルがあったら、とりあえずざっくりとしたseed.yml書いてguessしてconfig.yml生成、previewでdry runして、どう認識されるか確認しながら、configの内容をseedにコピペして修正して、を繰り返すのがラクそうですね。
このあたり、すごい良くできていると思いました。


ちょうどこの原稿を書いている最中*1に、Voyage Groupさんの
techlog.voyagegroup.com
が公開され、好評のようです。

やっぱり、実運用で使っている方の記事が公開されるのは助かります。


*1:公開より数日前から書き溜めてます

JDBCでInputする - Kibanaを立ててみた

$
0
0

ファイルではなくDBの中身を取得

これまで、Logstashやfluentdが、「ファイル」を読み込んでelasticsearchに流し込む事例を扱ってきましたが、どちらも、「データベース」から直接読み取って、elasticsearchに流し込むことができます。


今回は、MySQLの中身を直接読み取ってElasticsearch/Kibanaに流し込むケースにトライします。


過去ブログで取り上げた「SHOW FULL PROCESSLIST(=SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST)」に取得のタイムスタンプをつけたものを、ファイルを経由せずにElasticsearchに取り込むようにします。


LogstashでJDBC経由でDBの中身をElasticsearchに流し込む手順

Logstashの場合「プラグイン」と呼んでいますが、デフォルトインストールパッケージに含まれるので、設定ファイルで指定してあげるだけで使えます。

ただし、JDBCドライバは別途必要になります。
ですので、MySQLJDBCドライバ「Conector/J」を入手しておきます。


執筆時点の最新版「5.1.43」は、以下のように取得、展開可能します。

wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.43.tar.gz
tar xzf mysql-connector-java-5.1.43.tar.gz
export CLASSPATH=/JDBCドライバのjarファイル展開先パス/mysql-connector-java-ver-bin.jar:$CLASSPATH

続いて、Logstashの設定をします。
こんな感じで、/etc/logstash/conf.d/の下の.confファイルを作成します。


テンプレート定義、指定は省略していますが、とりあえず数値として欲しい情報はElasticsearch側でNumberで認識されていました。

input {
  jdbc {
    jdbc_driver_library => "mysql-connector-java-5.1.43-bin.jar"
    jdbc_driver_class => "com.mysql.jdbc.Driver"
    jdbc_connection_string => "jdbc:mysql://MySQLサーバーのホスト:3306/INFORMATION_SCHEMA"
    jdbc_user => "MySQLにログインするユーザ名"
    jdbc_password => "パスワード"
    statement => "SELECT NOW() as logtime, ID as Session_id, USER as Session_User, HOST as Session_Host, DB as Session_Db, COMMAND as Session_Command, TIME as Session_Timer, STATE as Session_State, INFO as Session_Info FROM INFORMATION_SCHEMA.PROCESSLIST;"
    tracking_column => "logtime"
    schedule => "*/1 * * * *"
    type => "jdbc-mysql-processlist"
    last_run_metadata_path => "/var/log/logstash/.logstash_jdbc_last_run"
  }
}
output {
    if [type] == "jdbc-mysql-processlist" {
      elasticsearch {
        hosts => [ "localhost:9200" ]
        index => "lgs-jdbc-mysql-processlist-%{+YYYY.MM.dd}"
      }
    }
}
Input部

前半は、よくあるJDBCベースのプログラミングで必要な接続情報です。


実際に発行するSQLを「statement」に記述するわけですが、ファイルに出力するときはsedで加工して付与していたTimestamp情報をSQLの中で取得させるため、SHOWコマンドではなくInformation_schema.processlistテーブルから取得するSELECT文を使用し、冒頭でNOW関数を使っています。列の名前もElasticsearchにそのまま反映されるので、意図的にasで名前を変えています。

「tracking_column」では、前回取得との差を認識させるためのカラムを指定します。一般的なテーブルだt「最終更新日時」的な列を指定しますが、porcesslistテーブルには該当する列がなく、取得時に強制的にnow()で付与しているため、その列を指定しています。

ファイルから取得するときと違う特徴的なものが「schedule」です。
Linuxのcronと同様の形式で、SQLステートメントの実行間隔を指定できます。今回は「"*/1 * * * *"」つまり1分間隔です。

「last_run_metadata_path」は、最終実行時刻を保持するファイルの場所の指定です。
権限さえあればどこでもよいですが、デフォルトはホームディレクトリです。

Filter部

ファイルからの取込のときにはFilter部でgrokを書いていたのですが、今回はgrokなし、Filter部なしでイケてしまいました。細かな制御をするときにはJDBCでもFilter部を書くことになるかと思いますが、最低限の動作であれば、まったく必要ありません。

Output部

Fileのときと特に差はありません。
Fileのときは、MappingテンプレートをElasticsearchに定義して、そのテンプレートを使うように指定をいれましたが、今回はその部分を省略しても意図したデータ型で認識されていました。


ここまで設定したら、Logstashを起動してあげると、SQLステートメントの実行結果=Processlistの内容が、ElasticsearchのIndexに登録され、Kibanaからも確認できるようになります。


細かいパラメータなど

ここで取り上げなかった細かいパラメータ仕様などは、公式ドキュメントを作成してください。公式以外にも、各所ブログでチラホラと日本語解説記事が上がっています。
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html


fluentd編は?

ごめんなさい。記事化できるレベルでの検証作業が間に合いませんでした。


調べた範囲でいうと、Logstashとの違いは、

    • fluentdはRubyベースなので、JDBCドライバではなくRubyMySQLアクセス用モジュール経由で。
    • fluentdプラグイン開発が活発な一方で、どのプラグインを選んだらいいかわからない。
    • ファイルのtailのようなリアルタイムじゃなく、定期実行でよいなら、(Fluentdじゃなくて)Embulk+embulk-input-mysqlプラグインがラクそうw

といったところでしょうか。





一旦おしまい - Kibanaを立ててみた

$
0
0

Kibanaを立ててみた - なからなLifeにて当初予定していたもの全部は記事化できなかったのですが、一旦締めさせていただこうと思います。

以下テーマは、間に合わなかったので後ほど

Amazon Elasticsearch連携

AWS契約して、マネジメントコンソールからAmazonElasticsearchの画面に遷移して数クリックで立ち上がりますが、現時点で提供されているのが「5.3」まで、というのがちょっとね。


諸事情により、近々触る予定はあるので、その時の話をどこかでアウトプットできればと思います。
新しいの触った後に古いの触るの、複雑な心境ですね。

S3へアウトプットする

fluentdのプラグインリスト上にS3用は1つしかないので、これを入れて認証とS3 Buket情報入れてあげればいいだけなんですけどね。
実案件で使われている一方で、ほどよくテストできる環境がなかったので、一旦保留。

Kibanaでのグラフ作り

これ、ブログネタにしようとすると、ある程度具体的なシナリオと、それを表現するデータ、そして、大量の画面キャプチャが必要なんですよね。そこが最大のネック。
これもネタが用意できれば記事化しますが、ちょっと時間かかりそうです。


ずっと紹介してきたサーバ/インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築!] Software Design plusにも、グラフづくりのあたりの説明はそんなにないのと、そもそも最近Kibanaのグラフ作りの操作仕様が結構変わってたりして、あんまり良い情報が揃ってないんです。


その点では、一度紹介したElastic Stackで作るBI環境 誰でもできるデータ分析入門 (NextPublishing)が、わりとしっかりページを割いて解説しているので、急ぐ方にはこちらをお薦めします。



一連の作業、記事化を通じての、雑感

まだまだ比較検証したほうがいいものはあるのでしょうし、扱ったものにおいても、深みの足りない部分があるかと思います。実運用をガチにやっていれば欠かせないであろうパラメータも、今回は殆ど取り扱っていません。fluentdやLogstashの場合、転送や加工の負荷を考慮して、各サーバーに入れたエージェントから、一旦収集転送専用のサーバーに転送して、そこで加工してからElasticsearchに流し込む、という構成も一般的なようですが、そういった話にも踏み込めていません。


その辺は、もう少し理解度、経験値が溜まってから触れられたらと思います。



それにしても、今回、一連のプロダクトを触ってみて、どれもセットアップはかんたんになっているなー、と関心しました。環境立てる「だけ」なら、どれも数分で終わりますね。

「サーバレスで数クリックで環境構築」とか言われても、「それコマンド数回叩けば終わるし」ってレベルまで来てます。


サーバレスのメリットは、立ち上げ後の運用面の自動化の方がより重要になってくる、というのは、elasticsarchに限った話ではないです。「マネージドサービス」と呼ばれる、そのマネージの内容が、よりシビアに評価されていくようになるのかなと。


あと、結果的にサーバレスやXaasなものを使うことになったとしても、オンプレな状態で一通り手を動かしてみるというのは、やはり大事だなと思いました。ちょいちょいハマリどころでどっぷりハマって、新しいことを身に染み込ませていくわけです。

そして、今回全然触っていない、システムの成長にあわせたスケーラブルな構成のための設定なんかも重要になってきます。
そういうハマリどころ、ややこしいことの多くを最初からやらなくて良くしてくれているのがマネージド・サービスなわけで、本家のElasticCloudだったり、Amazon Elasticsearch Service(Amazon ES)だったりするわけです。


オンプレ構築・運用のツラみを知ってこそ、マネージド・サービスのありがたみ、何がメリットなのかが、よくわかるというものでしょう。


私自身はMySQLもいじっていて、一応検証用にPC上にVM立ててやってますけど、リードレプリカ立ててラグのこと気にしながらあれこれしたり、バックアップ・リカバリ計画立てたりするの、実案件でAmazon RDSにおまかせしてて、考えることが1/100くらいになって幸せを噛み締めてるところです。


マネージド・サービスで話を一番ややこしくしているのは、ElasticCloudもまたAWS上で展開されていて、それとは別にAmazon ESが提供されていることだったりして。:-p



クライアントサイドについては、日本ではfluentdが人気ですが、個人的にはLogstashが扱いやすいなと思いました。一番利用が多いファイル読み取りについても、fluentdのtailプラグインで指定するformatの正規表現まわりが意図したとおりに拾えなかったり、その他のプラグインを使うときも、「似たようなのがあった場合、どれを選んでよいか悩む」のもfluentdの特徴でしょうか。それだけプラグイン開発が容易であること、プラグイン開発含めたエコシステムが発達していることの裏返しだと思います。情報量の多さもfluentdに軍配が上がります。そのあたりも考慮しつつ、プロダクト選定をするのが大事かなと。


なお、今回、Kibanaを使う上でElasticsearchを立てるわけですが、Kibana用にIndex生成するという目的以外に全く使ってません。全文検索システムとして非常にパワフルなプラットフォームなのにもったいない!でも、語れるほどのノウハウもない!


本業がDBメインなインフラ屋さん?の私としては、全文検索はそれが得意なシステムに任せたほうがいい、と思っていますので、そっちのノウハウも溜めていきたいと思います。

最後に

一連の記事で参考にさせていただいた書籍を敬意を込めてもう一度紹介させていただきたいと思います。


高速スケーラブル検索エンジン ElasticSearch Server

高速スケーラブル検索エンジン ElasticSearch Server


その他、Qiitaその他各所ブログにて先人の知恵を公開されている多くの方々には、大変お世話になりました。
検証作業している最中に私が垂れ流していたTwitterでのぼやき(つぶやき)を拾って真摯にレスを下さったElasticの大谷さんにも感謝です。


今後もElasticsearchやKibana周りで新しい学びがあったり、バージョンアップしたElasticstack(6系アルファ版リリースされてるし)を触ったときなど、ブログエントリをあげていこうと思います。

MySQLのサーバーステータス変数の監視の話

$
0
0

mysqlクライアントから定期実行してたし、計算は別途やってた。

SHOW [GLOBAL ]STATUSで取れるのは、「サーバー起動からの累積値」または「コマンド発行時の瞬間値」という仕様のため、前者について推移を知りたいときは、
・定間隔でコマンド発行してファイルに吐く(ex: mysql -e "SHOW GLOBAL STATUS;">>mysql-statsus.log)
・前回との差分を計算(Excelとか使う
が必要だと思っていました。


今日の驚き

キッカケは、私も過去に参加したことがある、Oracle公式のトレーニング「初心者向け!MySQL 5.7入門」に参加されていた方のツイート。

(セミナー全体のまとめはこちらにあります )
MySQL 5.7 初心者向けセミナー ~チューニング基礎編、SQLチューニング編~ 20170814 - Togetterまとめ



えー。公式ドキュメントに、そんなの書いてあったっけー?






。。。コレか!

--relative, -r

--sleep オプションとともに使用された場合、現在値と以前の値の差異を表示します。このオプションは extended-status コマンドとのみ機能します。
(強調はこちらでつけたもの)
https://dev.mysql.com/doc/refman/5.6/ja/mysqladmin.html#option_mysqladmin_relative

って、記述はたったこれだけ。



ただ、mysqladminにすると、SHOWコマンドのときに使えたLikeによる絞り込みができなさそうなので、mysqlコマンドで定期実行するのと一長一短ぽい。



そして

http://downloads.mysql.com/presentations/20151208_02_MySQL_Tuning_for_Beginners.pdf

定期的に確認する例(15秒間隔で、ステータス変数の差分のみ表示)
shell> mysqladmin -u <ユーザー名> -p ex -i 15 -r | grep -v ‘0‘

公開資料(ダウンロード済)にも、ちゃんと書いてあった(泣)



「初心者向け」とか「入門」って書いてある本も、時々読み返そう!

やさしく学べるMySQL運用・管理入門【5.7対応】

やさしく学べるMySQL運用・管理入門【5.7対応】

「新しいLinuxの教科書」あれはいい本だ。

$
0
0

所属している会社は小さいし、そこそこ実績のある中途しか採用していないので、Linux入門者を相手にする機会はそうそうないです。


なので、ここで吠えておくことにします。


「新しいLinuxの教科書」あれはいい本だ。



新卒SE向け研修(特に文系も採用しているようなところで)のテキストとして使うもよし、とりあえず自由に使えるLinux環境立てられるようになったらあとは自分で写経しながら読んでおけ、でも、いい感じに使える内容が書かれていると思います。


また、体系的に学ぶこと無く、うまいことやり過ごしてきてしまった中堅以上のエンジニアが読めば、学び漏れていたこと、表面的にしか理解していなかった話ことのフォローアップにもつながるでしょう。


深すぎず浅すぎず、狭すぎず広すぎず、よくまとまってます。
深みが必要になれば、その領域を掘り下げた本に進めばいいですしね。シェル芸本とか。


同系統の本を読み比べたわけではないので、他の本でもよいのか、この本だから良いのか、といった相対的な評価はできないですが、よいものはよいと言っておきましょう。


新しいLinuxの教科書

新しいLinuxの教科書

Logstashでハマった - Kibanaを立ててみた:番外編

$
0
0

atsuizo.hatenadiary.jp

の際に扱っているLogstashですが、この時使用したファイルとは別のファイルを取り込もうとしてハマりました。

何が原因なのかログから見えにくい、ということもあり、こちらに記録を残しておきます。

「指定したファイルへのアクセス権」が足りなかった。。。

結論だけ言ってしまえば、それだけでした。。。


前回の例だと、

path => "/var/log/mysql_monitor/show_global_status.log"

となっているのですが、rootユーザで作業していた上に、完全にオリジナル(このために作った)なディレクトリ、パスなので問題が出なかったのですが、Apacheが標準的に出力するaccess_logを取り込もうとして失敗していました。


ApachehttpdYumLinuxにインストールした場合のデフォルトのログファイルパスを指定すると、以下のようになります。

path => "/var/log/httpd/access_log"

この時、access_logのファイル自体は

-rw-r--r-- 1 root root  815468 Sep 12 16:08 access_log

なのですが、このディレクトリは、

drwx------ 2 root     root        4096 Sep 11 14:21 httpd

となっており、root以外では読むことすら出来ません。


で、

drwxr-xr-x 2 root     root        4096 Sep 11 14:21 httpd

に変更すると、ディレクトリ配下に対してroot以外でも読み取りできるようになると。


ファイル自体の権限だけでなく、そのファイルがあるディレクトリの「実行権限:x」の状態がポイントですね。


Logstashの実行モードと権限

yumでインストールしたLogstashは、サービスとして起動(initctl start logstash)すると、実行ユーザーは「logstash」なので、/var/log/httpd/が見えず、その下のファイルを参照することができません。


サービスではなくフロントで起動(sudo /usr/share/logstash/bin/logstash -f 設定ファイル)すると、実行ユーザーは「root」なので、/var/log/httpd/access_logまできれいにアクセスできます。


なお、ログを見ると

Logstashログは、サービスで起動したときは、「/var/log/logstash/logstash-plain.log」にログが出力されますし、フロント起動した時は標準出力でコンソールに出力されます。

しかし、今回のハマリケースでは、どちらもエラーで落ちずに、以下までログが進んで、Logstashが普通に起動している状態まで進んでしまうので、何が起こっているかわかりにくいのです。

logstash.pipeline - Pipeline main started
Successfully started Logstash API endpoint {:port=>9600}

で、いつまでたってもElasticsearch側にデータが取り込まれないなー、となって、問題が発生していることに気づく感じです。


Logstashからみれば、「起動したけど、取り込むべきファイルが見えない(まだ生成されてない?)から待ってるよ」ってことなのかもしれませんが。

まとめ

yumでインストールしたLogstashのサービス起動時の実行ユーザーは「logstash」
・(Logstashをサービスで動かすときは特に)Inputのファイルおよびディレクトリへのアクセス権に注意する。
・「エラーなし、フロント起動だとElasticsearchへ取り込まれるのに、サービス起動だと取り込まれない」パターンは、インプットファイル/パスの権限を疑う。



Elaticsearch+Kibanaの新しい本、そろそろ発売ですね!

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

「Amazon Web Services負荷試験入門」は2つの面で良書だった

$
0
0

まさにT/Oなんだが


AWS本では珍しい「ワンテーマ」の本

世に数あるAWS本の多くは「入門として、広く浅く」か「最新(最近だとサーバレス)の特定技術であんなことも!こんなことも!」のいずれかに分類されるかと思いますが、この本は「AWS上に構築したシステムの負荷試験をどうやってやるか」という、とある1つのソリューションに特化した本ということで、これらとは一線を画しています。


特に前者については、もう出尽くし感があります。一部の本が改訂版を出していますが、既存サービスも進化しているAWSにおいて、古い情報のまま次の本が出てこないモードに入りつつあります。


技術書を書くような人は、基本的に新しいものを探求する人が多いので、画面キャプチャ取り直しという地味な作業がメインになりかねない改訂作業、新刊にしても知り尽くしている領域について執筆するという作業にたいするモチベーションの問題もあるかと思いますし、執筆企画を扱う出版社側も「目新しさ」を欠く本は企画を通しにくいです。


ワンテーマというのも、「広く遍く売りたい系」の出版社からすると、市場を自ら狭める行為なので、企画が通りにくいのではないかと思います。


技術評論社さん、この負荷試験本の企画を通してくれてありがとう」という感じです。


ネット界隈(Twitter&ブログ等)でもとても評判がよいようで、Amazon上での売上も上々のようです。
AWS本のこれから」にも少なからず影響する1つの事例とも考えられます。

AWSに限った話ではない「負荷試験」を語った本

そもそも、AWSということを抜きにしても、負荷試験をテーマにした本というのは少ないです。というか、システム試験についての本の一部で語られている程度のことが多いです。


若手のエンジニアや、整理された状態で学んだことがないままなんとなくやってきたエンジニアにとって、良い手引書となるでしょう。


負荷試験に対する考え方、負荷試験のアプローチといった概念、理論の話から、ApacheBench、JMeter、Locust、Tsungといった具体的なツールの扱い方まで一通り説明されているだけでなく、その試験作業の中で陥りがちなハマリどころ対処法についても言及されています。


この「ハマリどころ」というのは、負荷試験が不十分なまま使っているシステムで突然発生してエンジニアを振り回しがちな障害そのものだったりするので、開発・構築前に読んで知っておくだけでも予防効果が期待できるかと思います。


ガチンコで負荷試験に取り組んできた人だと「物足りない」という感想を持つかもしれませんが、はっきりいってこのレベルで整理された情報が圧倒的に不足していると思いますし、だからこそ好評をえているのだと思います。


物足りないと感じた人は、入口部分はこの本におまかせして、「負荷試験入門」の次のステップについての解説を、書籍とかブログとか、どこかでアウトプットしてもらえるとありがたいですね。


そんなわけで

おすすめです。



技術評論社さんの電子版直販サイトはこっち。
gihyo.jp

Viewing all 174 articles
Browse latest View live