# [elasticsearch](https://www.elastic.co/jp/elasticsearch)

やんごとなき理由により某組織のネットワーク管理を予算ほぼゼロで保守する必要性があり，
数百のネットワーク機器のlogの収集・検索・可視化等を１箇所で行うため，Elastic社の[Elastic Stack](https://www.elastic.co/jp/elastic-stack)のうち[elasticsearch](https://www.elastic.co/jp/elasticsearch)の運用の備忘録を残す．
ChatGPTとかがない時代に試行錯誤して構築したので，最適化されていないと思うがデータフローの概念図はこんな感じ．

![](elasticstack.jpg)

elasticstack全体が多機能なので使いこなせていないが，ログの収集・検索・可視化は上記の流れで実現可能．


## elastic search installation

[Install Elasticsearch with Debian Package](https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html#deb)を参考にinstallする．elasticsearchをinstallしたらlogstash, kibanaも一緒にインストールしておくと良いだろう．


```
# systemctl start elasticsearch
# systemctl enable elasticsearch
```

起動確認は

```
curl -u elastic localhost:9200
Enter host password for user 'elastic':
...
```

デフォルトのuserは
user:elastic
pass:elastic

パスワードの変更は

```
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
```

で変更できる．

[Set up basic security for the Elastic Stack](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html)
より最低限のセキュリティーセットアップを実行．

## データの保存先

`/etc/elasticsearch/elasticsearch.yml`で

```
# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /var/lib/elasticsearch
path.data: /hddpool/elasticsearch
```

のようにすれば良い．

## データの移行

[Migrating data](https://www.elastic.co/guide/en/cloud/current/ec-migrating-data.html) を参考にすればdataの移行は可能だと思う．


## Lucene indexの制限（現在非推奨）

ファイヤーウォールのログをlogstash -> elasticsearch へ送る際に次の様なerrorが出ていた．

```
     Could not index event to Elasticsearch. status: 400, action: (省略) \"reason\"=>\"Number of documents in the index can't exceed [2147483519]
 ```

どうやら，elasticsearchの一つのindexに対するdocumentとの登録上限があるようで概ね 2^31 = 2147483648 程度しか登録できないようだ．これはelasticsearchが使っている[Lucene indexの制約](https://discuss.elastic.co/t/elasticsearch-throwing-number-of-documents-in-the-index-cannot-exceed-2147483519/242512)によるらしく現在もこの制約がある．
まあ，一つのindexに対して登録されたドキュメントが膨大だと検索に時間がかかる様になるので仕方ないのかもしれない．

解決方法としてindexの名称を異なるものに変更すれば良いが，手動でlogstash.ymlを変更するのも面倒だし恒常的に監視していないので，半年毎などで自動でindex名称を変更するようにしても良いかもしれない．
もしかするとlogstash側ですでにそのような機構が用意されているかもしれないがとりあえずは再indicesし始めたので，おいおい対策を考える．


```
# curl -u elastic "http://localhost:9200/_cat/indices?v"
```

で docs.countに登録ドキュメント量が記載されているので，これを定期的に確認して対処するしかないかな．
ファイヤーウォールのlogが概ね30分で484541あるのでざっくり概算すると92日でdocument limitationに到達する．従って，indexは２ヶ月に１回程度の頻度で更新しないとダメだな．あるいはファイヤーウォールののindecing をやめるか．
とりあえず，crontabに
```
00 6 1 */3 * /bin/bash /etc/logstash/conf.d/rename-index-mfwlog.sh
```
を追記して3ヶ月毎に1度indexの名前を更新する．

```
# curl -u elastic "http://localhost:9200/_cat/indices?h=h,s,i,id,p,r,dc,dd,ss,creation.date.string"
```
でindexを作成した日時がわかる．

(ES-Datastream)=
## DataStream

cronでelasticsarchのindexを差し替えていたが，elasticsearch 7からdatastream + ILMロールオーバーで自動的にindexを更新してくれるようなので修正した．

```
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    data_stream            => true
    data_stream_type       => "logs"    # 必須
    data_stream_dataset    => "***"     # 任意
  }
}
```

logrolloverの設定はkibanaのDev Toolで
```
GET _ilm/policy/logs
```
で確認できる．ここではデフォルトの` "max_age": "30d", "max_primary_shard_size": "50gb"` をそのまま使う．ファイヤーウォールのlogは概ね２日程度でロールオーバされる見込み．

```{toctree}
:maxdepth: 1

another_page