検証

ブラウザから KibanaのWebコンソールにアクセスし、Discoverページに移動します。
http://192.168.91.133:5601
kibana-menu

filebeatで転送したログデータが表示されます。
kibana-logopen

データが表示されず、以下の画面が表示される場合は表示時間内に出力対象ログがない状態です。
赤枠のいずれかのアイコンを押下し、データが存在する期間を指定してください。
no_results_found3

データが存在する期間を指定します。
date

左ペインのカテゴリを押下すると、データの内訳が表示されます。

対象項目をグラフィック化したい場合は、①の枠下端のVisualizeを押下してください。

複数の項目を組み合わせてログを整形したい場合は、②のaddアイコンを押下することで③の部分に列が追加され。最大6列まで増やすことができます。
各行のログは④の矢印アイコンを押下することで詳細がプルダウンできます。

今回の検証では、sshdログ、MariaDB認証/クエリログを組み合わせて以下のように整形しました。



このログより、以下が読み取れます。

・DBサーバへhoge, hoge2, rootアカウントで認証試行
・アクセス元はいずれも192.168.91.1
・12時46分10秒にrootアカウントでログイン成功
・12時48分35秒にDBにアクセス成功し、以下のコマンドを発行してDBデータを閲覧

> show databases;
> use geodata;
> show tables;
> select * from param;
アクセス元IP、ログイン後のDB内での行動が追えました。

以上で検証は終了です。

 


まとめ

Elastic Stackを導入する際の注意点や気付いたこと。
・beatsはjavaが導入されていなくても動くのが強みである。
企業サーバ等でjavaを入れられない事情がある場合にはクライアントエージェントとして重宝する。

・Elastic社では今回検証したElasticSearch+Logstash+Kibana+beatsの4製品セットでの運用を推奨しているが、ElasticSearch+Logstash+Kibana構成による”ELK”環境でも問題なく動作する。ただし、Logstashの稼働にはjavaが必要なのでクライアントエージェントとしての汎用性は若干落ちる。

・今回検証したのはbeatsの内のfilebeatのみだがネットワークパケットを対象としたpacketbeat、ディスク/CPU/Memory使用状況等のマシンデータを対象としたMetricbeatなども有効利用できる。

・ElasticSearchの安定稼働にはCPU・メモリ等のマシンリソースが高いレベルで必要であり、チューニングも必須である。

Metricbeatを利用することでクライアントリソース使用状況をKibanaで可視化して監視することも可能であるが、Kibanaのデータ参照先であるElasticSearch自体のリソース監視も必要となるため、「監視システム自体のリソース監視が必要」ということにも成り得る。

メモリ ヒープ・スワップサイズや最大ファイル展開数の設定は環境に合わせてチューニングすることをお勧めします。

・セキュリティおよび監視、レポート機能の追加パッケージとしてX-Packが公式から公開されている。

Elastic StackのフルSSL化や監視の設定容易化により利便性が格段に上がりそうです。