
プロジェクトのステージング環境のログが検索しにくいため、EFKの管理ログを構築する予定だが、EFKのメモリ消費量が大きく、新たにクラウドサーバを追加するのは費用対効果が悪いため、ローカル(16Gメモリ)に構築する予定。
それは何ですか? イーエフケー
EFKは1つのソフトウェアではなく、一連のソリューションであり、そのすべてがオープンソースソフトウェアです。 エラスティックサーチ
ログの記録と検索を担当。ファイルビート
ログの収集を担当。キバナ
インターフェイスを担当。
- 1.Elasticsearch Elasticsearchはオープンソースです。分散型検索エンジンこのシステムは、データの収集、分析、保存という3つの主要な機能を提供する。その機能には、分散、ゼロ・コンフィギュレーション、自動ディスカバリー、自動スライシング・インデックス作成、インデックス・レプリカ・メカニズム、レストフル・スタイル・インターフェイス、複数のデータソース、自動検索ロードなどがある。
- 2.ファイルビート ファイルビートは、次の製品の一部です。 ビートログデータは収集され、アップロードされる。
Elasticsearch
そしてログスタッシュ
そしてレディス
などのプラットフォームがある。 - 3.Kibana Kibanaはログ分析のためのユーザーフレンドリーなウェブインターフェースを提供し、重要なデータログの集約、分析、検索を支援します。
環境ステータス
- 1.地元の環境:ウィンドウズ10インテル(R) Core(TM) i5-7500 CPU、16G RAM。
- 2.リモート環境:SUSE Linux Enterprise Server 11、使用可能メモリ1G未満
- 3.ローカルでVMを起動できるが、クラウドサーバーを追加購入する余裕がない。
初期構想
これには現在3つの考え方がある:
- 1.Elasticsearch、Kibana、Filebeatをローカルで起動し、サーバはFTPを起動してローカルネットワークドライブにマッピングし、Filebeatはネットワークドライブからログを読み込むように設定します。
- 2.ローカルでElasticsearchとKibanaを起動し、リバースプロキシツールFRPを使ってElasticsearchのポート9200をパブリックネットワークに公開し(フォレンジックの設定に注意)、リモートでFilebeatを起動してローカルのElasticsearchに出力する。
- 3.ローカルでElasticsearch、Kibana、Logstash、リモートでFilebeatとRedisを起動し、FilebeatはリモートでRedisに出力し、LogstashはローカルでRedisから読み込んでElasticsearchに転送する。
プログラムの特定
これら3つの選択肢すべてに抵抗がある:
- 1.不安定なマッピング、頻繁な切断、遅すぎるI/O速度
- 2.リバースプロキシツールは企業では使用できない
- 3.より複雑な構成
Elasticsearch、Kibana、Filebeatをローカルで起動し、rsyncコマンドをループさせ、サーバにSSH接続してローカルでログをインクリメンタルに同期する!
大騒ぎ
Elasticsearch、Kibanaはリソース消費が大きいため、Windows環境で起動することにした rsyncはLinuxのため、仮想Ubuntu環境でのみ起動可能 FilebeatはUbuntu環境でのロギングのため、I/O効率化のため、Ubuntu環境でも起動した
EとKの活性化
Kibanaのインストール
https://www.elastic.co/guide/en/kibana/current/windows.html
Elasticsearchのインストール
https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-install.html
このチュートリアルで使用するコンフィギュレーションは以下の通りです:
network.host:[_local_、_site_]。
http.ポート: 9200
サーバーのポート: 5601
server.host: "0.0.0.0"
elasticsearch.url: "http://localhost:9200"
仮想マシンの起動
ここでは、Vagrant を使って起動し、Virtualbox と Vagrant をインストールして、以下のように Vagrantfile を作成します。
Vagrant.configure("2")を実行する |config|)
config.vm.box = "ubuntu/xenial64"
config.vm.providerは "virtualbox "です。
vb.memory = "8192"
do |vb| vb.memory = "8192
do |vb| vb.memory = "8192" end
同じディレクトリで実行する 浮浪者
そして vagrant ssh
仮想マシンに接続する。
ファイルビートの開始
ファイルビートのインストール
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.3.2-amd64.deb
sudo dpkg -i filebeat-6.3.2-amd64.deb
ファイルビートの設定
sudo vim /etc/filebeat/filebeat.yml
これは一般的な設定ですので、ご自身のプロジェクトのログ形式に合わせて適切なプラグインを設定してください。 10.0.2.2
ホストを表します。Virtualbox + Vagrant を使っている場合は変更しないでください。
ファイルビート.inputs.
- タイプ: ログ
有効: true
パス
- /home/vagrant/logs/* に設定します。
filebeat.config.modules: パス: ${path.config}/modules.d/*.yml
パス: ${path.config}/modules.d/*.yml
reload.enabled: false
setup.template.settings: index.number_of_shards
index.number_of_shards: 3
setup.kibana.
host: "10.0.2.2:5601"
setup.template.name: "ファイルビート"
setup.template.pattern: "filebeat-*"
setup.template.pattern: "filebeat-*" output.elasticsearch.
hosts: ["10.0.2.2:9200"] を指定します。
index: "filebeat-%{+yyyy.MM.dd}"
先にElasticsearchとKibanaを起動していることを確認し、Filebeatを起動します。sudo service filebeat start
サーバー側からのログの増分同期
まず、サーバーでssh_keyログインが有効になっている必要があります。Ubuntuでは、サーバーの authorized_keys
真ん中だ。
はこびだす 屏風
これはターミナル・セッションを開くもので、ターミナルが終了してもコマンドは終了しない。
(ショートカットキー | 趣旨 |
F2 | 新しいウィンドウを作成する |
F3 | 前のウィンドウに切り替える |
F4 | 前のウィンドウに切り替える |
F7 | 現在のウィンドウの印刷情報の履歴を参照する |
F6 | 屏風を舞台裏に行かせる。 |
Ctrl + F6 | 現在のウィンドウを閉じる |
インクリメンタル同期を実現するために、以下のコマンドを修正して実行する:
while true;do rsync -rtv --include "**.log" --exclude "*.*" --append -e "ssh -p " @:/var/logs /home/vagrant;sleep 5;done;
これは長いコマンドなので、コマンドの説明がある:
- 1.
真の
ループ実行 - 2.
-テレビ
rは再帰的なディレクトリ、tは同期されるファイルの更新時刻を保持、vは同期に関する詳細情報を出力する冗長モード(-vvでさらに冗長モード)。 - 3.
--include "**.log" --exclude "*.*"
ログファイルのみの同期 - 4.
--追加
ファイルサイズを比較し、超過分のみを同期するインクリメンタル同期。 - 5.
-e "ssh -p "
カスタムSSHプログラムのコマンドライン、カスタムポート - 6.
/var/logs /home/vagrant
サーバーの/var/logsディレクトリをローカルの/home/vagrantディレクトリに同期します。 - 7.
スリープ5
サーバー帯域幅の過剰使用を避けるため、各セッションの終了時に同期を5秒間停止する。
rsyncコマンドの使い方については、https://www.cnblogs.com/f-ck-need-u/p/7221713.html。
花を散らす
F6を押してループをバックグラウンドに切り、しばらく待ってから、http://localhost:5601/。

過去のログが大量にある場合、最初の起動後に大量のログが処理され、短時間に大量のログをチェックアウトするのが普通である。