はじめに #
前回はElastic Agentの基本的な設定を確認しましたが、今回はElastic Agentを追加して実際にlog収集するまでを確認します。
今回は分かりやすい、SSHのauth.logをElastic Searchに収集してみます。
1. Agentの追加 #
1.Integrationsの追加
auth.logを集めるためにIntegrationsからSystemを追加します。Data streamsのnamespaceはここで設定することができます。今回は検証環境ということでstgを設定しておきます。
2. Integrationsの設定変更
今回他の設定は変更しませんが、必要に応じてlogをParseをするProcessorsの設定や、収集するlog、metricの取捨選択ができます。
3. 新しいPolicyの作成
Integrationsを既存のhost(Policy)か、新しいhostに追加するか聞かれるので新しいhostを選択します。
Collect system logs and metricsをONにすると、Agentか稼働するOSのSystem情報を収集してくれますが、今回手動でSystemを追加するため重複しないようにOFFにします。
この状態でSave and continueを選択すると、Agentを新規追加するか聞かれるので、Add Elastic Agent to your hostsを選択します。
4. Agentをinstall
Agentを任意のhostにinstallする方法が出るので、これに従ってAgentをinstallします。
今回docker composeで構築したので、urlがhttp://fleet-server:8220とdockerNW内でのみ名前解決できる様になっています。
これを回避するためにはAgentインストール先の/etc/hostsに記載してアクセスできるようする必要があります。
今回は/etc/hostsにfleet-serverとelasticsearchのIP(コンテナが稼働しているHostのIP)を記載しておきます。
root@ubuntu:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ubuntu
192.168.1.203 fleet-server elasticsearch
installが成功するとElastic Agent has been successfully installed.が出力されます。
curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.14.3-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.14.3-linux-x86_64.tar.gz
cd elastic-agent-8.14.3-linux-x86_64
sudo ./elastic-agent install --url=http://fleet-server:8220 --enrollment-token=T3BUZEdKRUJzY3dZYVJLZmNObHg6WGdPM1lYcVZTbWU1d3NQaUFBemF6UQ== --insecure
### 省略 ###
Successfully enrolled the Elastic Agent.
[== ] Done [3s]
Elastic Agent has been successfully installed.
以下のエラーが出た場合は、--insecureオプションを追加しましょう。
Error: connection to fleet-server is insecure,
strongly recommended to use a secure connection
(override with --insecure)
データが正常に取得できれば、Fleetに追加されるようになります。
2. logの確認 #
Data streams名は今回logs-system.auth-stgとしたので、Discoverから確認するとSSHの履歴がちゃんと保存されていることが分かります。
3. Discoverの確認 #
Integrationsの便利な点として、自動でDashboardが作成されます。今回のauth.logではSSH login attemptsというDashboardが作成されています。
このDashboardではSSHの失敗logや、失敗した場合のアクセス元(今回は192.168.1.2とprivateIPなので判別できませんが)等が確認でき非常に便利です。
4. Metricsの確認 #
Elastic Agentではmetricbeatsも内包しているので、SystemのIntegrationではmetricsも収集されています。
5. ILMの作成 #
[第1回]で紹介したようにDatastreamsのlog保持設定はIndex Lifetime Manager(ILM)によって実施されます。これを新しく作成してみます。
1. ILMを作成
Index Lifecycle Policies等で検索し、Create Policyを選択します。
2.任意のPolicyを作成
まずPhaseを選択します。Phaseの説明は以下の図や、公式ページに詳しく記載されているので、省略しますがデータの重要度とコストに応じて変化させましょう。
価格差、性能差がどのように生まれているかは以下になります。またNodeを独自で構築している場合は、Hot用のNodeは性能(CPU/MEM/Storage)を高く、Warm用はNodeの性能を低くすることで更にカスタマイズ可能です。
| phase | 説明 | reference |
|---|---|---|
| Hot | デフォルト。shard数、replica数に応じて性能、コストが決まる。 | link |
| Warm | shard数が1に減る + セグメントが1つにマージされることで検索性能が低下するが、データが圧縮されコスト・CPU使用量減に | link |
| Cold | repica数が0になりデータが半減されコスト減に。データの修復が必要な場合はsnapshotから実施 | link |
| Frozen | nodeのローカルストレージからデータは消去し、検索は全てsnapshotから実施。snapshotの置き場所をS3等に指定することコスト減 | link |
今回はdockerでElastic Searchが1nodeしかなくphase分けをする意味もないので、2日で削除するようにします。
6. Index templateの設定 #
作成したILM等の適用はIndex Templateから実施します。
1. 現在のIndex templateの確認
Index managementの画面からDatastreamsの設定を確認し、使っているtemplateを特定します。今回はlogs-system.authです。
2. Index templateの設定を見る
Previewタブの"lifecycle"をみると、現在使っているILMが分かるのILMを変更したい場合はこの値を変更することになります。
3. Component templatesを見る
Integrationsから自動生成された、Index templateはManagedのタグがついており変更することはできません。
従ってComponent templateを変更していくことになります。
Component templateとは？
Index templateの一部だけをComponent templateとして分割することで、よりIndex templateを再利用しやすくした仕組み
今回のIndex templatelogs-system.authは以下の6つのcomponentから生成されています。この中で@customが付いたものが自由でカスタムできるtemplateになります。
4. @customの変更
logs-system.auth@customのcomponent templateを探します。もし存在しない場合は新規作成しましょう。
Data retentionでデータの保持期間を設定できますが、ILMが優先されるのでOFFにしておきます。
Index settingsで今回はILMの変更とshard,replica数を変更してみます。index:から始めなくてもOKです。
他の設定は今回変更せずに作成します。
5. 変更後のIndex templateの確認
Component templateの変更が反映されているかは、再度Index templateのpreviewから確認することができます。今回は"name": "delete-after-2days"なっておりちゃんと反映されていることがわかります。
logs-system.auth@packageで書かれた設定はlogs-system.auth@customで上書きされる形になります。
6. 変更後Indexへの反映
上記手順で設定した仕組みは即時反映ではなく、次のIndexが作られる時に初めて効果がでます。
例えばreplica数を1にしたはずなのに、r UNASSIGNEDとなっていることからも分かります。
$ curl -s -XGET -u "elastic:changeme" 'http://localhost:9200/_cat/shards' | grep auth
.ds-logs-system.auth-stg-2024.08.03-000001 0 p STARTED 534 533.7kb 533.7kb 172.18.0.2 elasticsearch
.ds-logs-system.auth-stg-2024.08.03-000001 0 r UNASSIGNED
これを回避するためには現状のILMポリシーに合わせて、次のIndexが作られるまで待つか、Indexを移行するか等の選択肢がありますが、今回は手っ取り早く現在のData streamsを削除します。(もちろんデータは消えます。)
これで新しくlogが作成されれば、自動で再度datastreamsが作成されて、indexも同時に再作成されます。
# replicaが消えた
$ curl -s -XGET -u "elastic:changeme" 'http://localhost:9200/_cat/shards' | grep auth
.ds-logs-system.auth-stg-2024.08.11-000001 0 p STARTED 7 32.9kb 32.9kb 172.18.0.2 elasticsearch
おわりに #
第1回と、今回で新しいlog取得手法のElastic AgentとData streamsについては紹介できたかと思います。
今までのBeatsやLogstashでのlog収集とはだいぶ設定項目が異なり戸惑うので、主要な要素を抑えておく必要がありそうです。
第3回では、vSphere Integration、
第4回では、kubernetes Integrationの紹介をしたいと思います。
他にもlogをParseするProcessorsや、Elastic cloud on k8sなどを紹介するかもです。