2020/12/17に行われたElasticsearch勉強会のLTです。 Stack Monitoringで使われる"xpack.monitoring.collection.enabled"パラメータのお話です。

1. Stack Monitoringの設定パラメータの謎
’xpack.monitoring.collection.enabled’は何をするもの？
@tetsuyasd
2020/12/17
Elasticsearch勉強会 #39 LT
#elasticsearchjp

2. Who am I ?
2
名前: 惣道 哲也 （そうどう てつや）
Twitter: @tetsuyasd
所属: 日本ヒューレット・パッカード株式会社 Pointnext事業統括
職務: オープンソース関連いろいろ（調査、検証、構築、提案）
- Cloud / Container / Data Analytics / etc…
#elasticsearchjp

3. ElasticStackの監視の方法が変わります
バージョン6.3以前の監視方法が非推奨に
新しくMetricbeatを全面的に利用した方法へ
(以前の方法は”Legacy Monitoring”、新しい方法
は”Metricbeat Monitoring”とも呼ばれる)
3#elasticsearchjp
本日12/17のElastic Stackアドベント
カレンダーで日比野さんが解説
https://www.creationline.com/blog/h-hibino/39618

4. ElasticStackの監視の方法が変わります
そういえば最近Monitoring使おうとするとこんな画面出ませんか？
4#elasticsearchjp
（Metricbeatの導入面倒だなぁ。。）
意地でもLegacy Monitoringをするぞ！
ポチッ
Turn on monitoringを押せばLegacyでできるものの
最後までMetricbeat Monitoringが推奨と表示して
少し不安にさせる仕掛け

5. ElasticStackの監視の方法が変わります
デフォルト設定とか、ちょっとわかりにくいですよね。。
5#elasticsearchjp
xpack.monitoring.enabled: true
xpack.monitoring.collection.enabled: false
誤解を恐れずにわかりやすく表現するとこういうこと（監視自体は有効だが収集する設定のみoff）
※7.8.0以降、xpack.monitoring.enabled設定はdeprecatedになりました。

6. Legacy Monitoringのアーキテクチャ
自クラスタもしくは監視用クラスタへ監視対象情報を次のインデックス名で蓄積する
– .monitoring-es-7-yyyy.mm.dd
– .monitoring-kibana-7-yyyy.mm.dd
– .monitoring-logstash-7-yyyy.mm.dd
– .monitoring-beats-7-yyyy.mm.dd
6#elasticsearchjp
自クラスタ or 監視クラスタに
.monitoring-*インデックスが
作成される

7. Legacy Monitoringのアーキテクチャ
デフォルトのenabled設定パラメータが多くて複雑。。
7#elasticsearchjp
[elasticsearch.yml]
xpack.monitoring.collection.enabled: true
xpack.monitoring.elasticsearch.collection.enabled: true
[kibana.yml]
xpack.monitoring.enabled: true
xpack.monitoring.kibana.collection.enabled: true
[logstash.yml]
xpack.monitoring.enabled: true
下線部はデフォルトがfalseの設定項目
この他kibana,logstashには送信先ES情報の設定もあります。
ここがfalse(default)
だと何も集めない

8. Metricbeat Monitoringのアーキテクチャ
Metricbeatが監視用クラスタへ監視対象情報を次のインデックス名で蓄積する
– .monitoring-es-7-mb-yyyy.mm.dd
– .monitoring-kibana-7-mb-yyyy.mm.dd
– .monitoring-logstash-7-mb-yyyy.mm.dd
– .monitoring-beats-7-mb-yyyy.mm.dd
8#elasticsearchjp
Metricbeatが監視対象情報を「pull」して収集、転送する

9. Metricbeat Monitoringのアーキテクチャ
9#elasticsearchjp
[elasticsearch.yml]
xpack.monitoring.collection.enabled: true
xpack.monitoring.elasticsearch.collection.enabled: false
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/configuring-metricbeat.html
Metricbeatがpullで集
めてくれるからfalseで
いいのでは？？
■今日の主題：公式ドキュメント記載のパラメータ設定手順↓が意味不明。。
ESだけ明示的にfalse
にする意味は？？

10. わからないので聞いてみました(discuss)
10#elasticsearchjp
https://discuss.elastic.co/t/258237

11. つまりこういうこと
11#elasticsearchjp
基本的にはMetricbeatが監視対象情報を収集してくれている
現時点、唯一例外としてCluster Alert（.monitoring-alerts-*)のみこの仕組みで収集できていない
– Cluster Alerts: X-Pack Alertsの有効化で自動生成されるアラート(バージョン、ステータス等の警告）
[elasticsearch.yml]
xpack.monitoring.collection.enabled: true
xpack.monitoring.elasticsearch.collection.enabled: false
近い将来のリリースでCluster Alertsも
Metricbeatで収集可能になり、それにより
このパラメータも設定不要になるそうです
このtrueは.monitoring-alertsのみ
を収集するためだった

12. まとめ
12
Stack Monitoringのアーキテクチャは過渡期ともいえます。
一過性のわかりにくい設定パラメータもあるんだなと思いました。
今回自分の中でも理解がかなり深まりました。
– 参考URL
– 日比野さんのアドベントカレンダー(12/17)
https://www.creationline.com/blog/h-hibino/39618
– Metricbeat Monitoringの公式ドキュメント(7.10)
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/configuring-metricbeat.html
– Discuss: No need to set `xpack.monitoring.collection.enabled` to true when using metricbeat-based stack monitoring?
https://discuss.elastic.co/t/258237

13. ご清聴ありがとうございました

14. 14
本資料に関するお問い合わせ
14
@tetsuyasd
Mailto: tetsuya.sodo@hpe.com
本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。
本発表内容に関して、ご質問等があればお問い合わせ下さい。
また、内容に関しては個人の意見に基づくものであり、所属組織団体の公式見解とは異なる場合がございます点、ご了承
下さい。