昨日は「第26回Elasticsearch勉強会「メトリック/ログ分析編」」という勉強会に参加してきました。
会場は富士通クラウドテクノロジーズ株式会社さんのニフクラウンジでした。
富士通クラウドテクノロジーズ株式会社さんはNiftyの法人向けクラウドサービスが分離されてできた会社さんですね。 www.nifcloud.com
Elasticsearch勉強会について
勉強会のグループ概要を引用すると
全文検索、リアルタイム解析システムelasticsearchについての勉強会用のコミュニティです。
また、Elasticが提供しているKibana、Logstash、Beatsについても扱います。
前回の参加報告はこちらです。こちらも併せてどうぞ。
参加してみて
今回、新しいステッカーを作成されたとのことで、会場で配布されていました。
新作ステッカー、頂きました！六角形！ #elasticsearchjp pic.twitter.com/L0oZNyRWz3
— kabukawa (@kabukawa) 2018年11月21日
また、Elastic 7.0のPioneer Programが開始されたというアナウンスもされました。
7のα版が出るようだhttps://t.co/2WyMfjMYbm
— ひがっしー (@tklogyk) 2018年11月21日
#elasticsearchjp
登壇者の募集も随時行われているようです。
もう26回目！スピーカー随時募集中！ https://t.co/OzJHgmrgnP #elasticsearchjp
— j-yama (@j__yama) 2018年11月21日
アドベントカレンダーへの参加も募集されています。
今年も作りましたー。参加お待ちしています！ #elasticsearchjp / Elastic stack (Elasticsearch) Advent Calendar 2018 - Qiita https://t.co/dlSLgnEZyz
— Jun Ohtani (@johtani) 2018年10月31日
1. (elasticビギナーが考えた）beatsを使った監査サービスの提案
Kazuyuki Ondaさん
個人メモ
背景 セキュリティインシデント発生 現状の対策とするべきこと ・防御はある程度実装済み(100%防御は無理) ・突破したものは検知できなければ対応が不可能 必要なのは検知 セキュリティ侵害発覚までの日数 平均520日(2015年、APAC) 何らかの検知する仕組み 要件 第三者から指摘される前に侵害に気付ける ・侵入 ・システム設定の変更に気付ける ・リアルタイムな通知は不要 その他はおいおい 環境要件 ・OSはすべてLinux ・対象ノードの地域/場所はバラバラ ・インターネット接続されている 提案準備 最初はこんな仕組みを考えていた elastic stackという考えはなかった 時は流れて数ヶ月 別件で syskigを可視化したい ELKにたどり着く beats? とりあえずインストールしてみた ・とりあえずできたけど、これでいいのか？ ・Kibanaのvisualizeをどう設定する？ そうだ、トレーニングに行こう PoCを兼ねてデモサイトを作る 見積もり＆デザイン ・インフラの洗濯とデザイン (AWS？VPS) 仕入れが発生するので超重要 インフラの検討 断然Elastic Cloudを使いたい ・X-Pack Securityが使える ・運用負荷が低い 早速Elastic cloudを使ってみた ドキュメントでポート番号を変える方法が見つからない クラウドサービスで変更できないのでは？ インフラの検討 スケールは不要なのでVPS 但しストレージだけS3 どこのVPSにするか？ ストレージはSSDがつ容量が大きい インスタンスをたくさん建てられる 固定のグローバルIPが使える 最終的な構成案 3台のマシンで冗長化 Route53でラウンドロビン セキュア＝可用性、機密性 イニシャル 導入作業費 ランニング 基本料金 Filebeat auditbeat 今後の課題 ・監査しないと意味がない ・月1回のレポートを検討 ・メンテナンスを可能な限り自動化 elastic意外のパッケージは自動アップデート ・ディスク容量 使いつつサイジング ・さらなる可用性 ・機能拡張 metric beat、packet beat ・結果 せめて勉強会に協力しよう
2. Logstashとともに振り返る、やっちまった事例ごった煮
フューチャーアーキテクト株式会社 日比野恒 さん
www.slideshare.net
個人メモ
ごった煮と言うほどごった煮感はない 包み隠さずやる LogStash 日本はFluentdが多いけど、世界的にはLogStash お世話になっているプラグイン ログ分析用Codec Netflowを使ったパケット分析 秒間2万ドキュメント オンプレ環境のNutanix上に仮想マシンとしてLogstashのノードを構築 NetFlowとは 性能問題発生 障害切り分け パケットのパースエラー？→なし パケットサイズ差分なし ルーター側のパケットは落ちてない どこで落ちているのか？ pipelineアーキテクチャ どこにどのようにメモリが使われているか？ OSのメモリチューニング →解決せず 仮想マシンのリソース拡張 input udpの性能に影響する設定値 pipelineの性能に影響する設定値 やってみないとどこにボトルネックが来るかわからない 大量フローがないと性能検証ができないので本番環境でないと見えてこない NewFlowを履く機種によってもLogstashに与える性能不可が違った System Load30を超えるとdrop始める傾向あり トラブルシュートしながらのチューニング
3. 「ElasticsearchのQueryが遅い時のトラブルシューティングとその対処」
[資料はアップされたら追加します]
個人メモ
遅い理由は様々 Step1 Slow Queryを特定する index slow log ドキュメントの追加、indexing search slow log slow query APIから設定 SlowQueryを分析する 遅いQueryをPrifilingして具体的に何が遅いかを特定する Step2 遅いQueryの再設計 Query結果スコア ElasticSearchは指定されたパラメータでQueryスコアを出す そのスコアでソートし、高い順に指定された Queryの再設計
まとめ
今回のテーマはメトリック/ログ分析ということで、実運用での知見などを共有していただきました。 ただ、前提知識があまりなかったので、話されていた各種製品やプラグインなどについてもう少し勉強していかないと話についていけなかったなぁ、と思いました。 仕事で使っていた時はElasticsearchのみでプラグインもほぼ使用していなかったのですが、他の製品と組み合わせて使ったり、足りない機能を補ってくれるプラグインを入れれば、もっといろんな事ができたのかもしれないということも思いました。
次回までに、もう少し基本的なことを勉強していかなければ。
