Elasticsearch、Kibana、Logstash、Beats、FilebeatおよびそのロゴはElasticsearch BVの商標であり、米国およびその他の国で登録されています。
本文中では®は表記しておりません。
我々の長年運用するシステムではサーバおよびアプリケーションの増加に伴い、ログ管理の煩雑さが問題視されるようになりました。
この問題を解消するためにElastic Stackによるログの収集・格納・検索を開始しました。
Elastic Stackを選んだ理由は、無料ライセンスで使用できる機能が豊富でスモールスタートに向いており、オンプレミス環境での使用が可能だったためです。
Elastic Stackを導入した結果、ログ管理の煩雑さは軽減されました。
同じ課題を抱えている方には、是非Elastic Stackを導入し、ログ管理の煩雑さから解放されて欲しいと思います。
しかし、Elastic Stackを導入するハードルは低くはありません。主な理由は以下の2つです。
本ドキュメントを読んでいる多くの方がElastic Stackを初めて利用することになると思います。 Elastic Stackを学習するための資料は公式ドキュメントをはじめ数多く存在しますが、 ログの収集の用途でElastic Stackを運用するために必要な情報がまとめられた、体系的なコンテンツは多くありません。
初学者は膨大なドキュメントを読み漁りながら、全体的なフローとして何を実践しなければならないのかを判断し、そのために自分が必要な情報が何なのかを見極める必要があります。
上記作業はかなりの時間と労力がかかるものですし、手順に間違いや漏れがあってもそれに気づきにくく、手戻りの元となります。
実際に我々のプロジェクトで最初にElastic Stackを利用しようとした際には、以下のような課題がありました。
本ドキュメントは、そのような経験をもとに、Elastic Stackを利用したログの収集の設計ノウハウをまとめたものです。
本ドキュメントを読むことで、Elastic Stackを使ったログの収集の仕組みの設計を行う際に、以下の2つの効果を得られるのではと考えています。
結果として、Elastic Stackを導入する際の学習コストが下がることを期待しています。
本ドキュメントはElastic Stackを用いてログの収集・格納・検索を行いたいと考えているアプリケーション開発者、インフラ技術者を想定しています。
また、Elasticの製品ページなどを読みElasticsearch、Kibana、Logstash、Beatsそれぞれの役割を理解している方を想定しています。
本ドキュメントでは下図のように、サーバ上のログファイルに出力されているログをElasticsearchに収集し、Kibanaで閲覧する仕組みの設計を目指します。
以下については記載しません。
本ドキュメントでは、「Elastic Stackを構築するための設計」と、構築されたElastic Stackの上で「新規のログを収集・格納するための設計」という、2章に分けて設計ノウハウを記載します。 「Elastic Stackを構築するための設計」では、Elastic Stackの構成の検討から、運用を見据えた設計までを記載します。初期構築時および、ログ量の増大、性能劣化による構成の見直し時に実施することを想定しており、以下の設計内容を記載しています。
「新規のログを収集・格納するための設計」では、構築したElastic Stackに新規のログデータを投入する際に検討が必要な事柄について記載します。集約するログが増える度に実施することを想定しており、以下の設計内容を記載しています。
まずは使用するElastic Stackのサブスクリプションを選択します。 Elastic StackのサブスクリプションについてはElastic Stackサブスクリプションを参照してください。ベーシックまでは無料で利用できます。運用途中でのサブスクリプションの変更は可能です。
■推奨設計
Elastic Stackの運用をサポートする機能が含まれるため、ベーシックまたはベーシック以上のサブスクリプションプランを選択してください。elastic社のホームページから取得したパッケージを使用する場合はデフォルトでベーシックプランが選択されます。
なお、本ドキュメントはベーシック以上のサブスクリプションプランを利用することを前提に記載します。
Elasticsearchはクラスタ構成を推奨しています。クラスタを構成する1つのElasticsearchプロセスをノードと呼びます。Elasticsearchでは1サーバに1プロセス起動することを推奨していますので、結果的に1ノード=1サーバとなります。 ノードは以下に記述する役割を持ちます。1つのノードが複数の役割を持つことも可能です。
ノード設計では各役割のノードをいくつ用意するかを検討します。高性能、高負荷になるほどノードの設計は重要になります。
各役割の検討の観点を記載します。
ログの種類数 * 保存日数 * 2 / (JVMメモリサイズ（GB） * 20 ) + 1 左記の計算結果の小数点を切り捨てた数をデータノード数の目安としてください。■推奨設計
Elasticsearch Architecture Best Practices | Elastic Videosにて紹介された構成を記載します。
■非推奨設計
■留意事項
構成の設計ではElasticsearch、Kibana、Logstash、Filebeatのサーバ構成と通信プロトコルを検討します。
各製品のサーバ構成の検討の観点を記載します。
次に通信プロトコルの検討の観点を記載します。
Elastic Stackの製品間ではHTTPまたはHTTPSプロトコルが使用できます。どちらを使用するか検討してください。
Elastic Stackの構成要素間がインターネット越しになる場合はHTTPSの使用を検討してください。
■留意事項
サーバ設計ではElastic Stackをインストールするサーバの物理メモリおよびElasticsearchとLogstashに割り当てるJVMメモリ、CPUコア数、ディスク、OS、その他インストールするパッケージを検討します。
サーバリソースの検討の観点を記載します。
ログサイズ(GB) * 1.1 * 1.25 / ノード数（GB）を目安としてください。1.1はElasticsearchに格納する際のオーバーヘッドです。次にOSの検討の観点を記載します。
Elastic Stackは製品によって対応しているOSが異なります。下記のページより対応OSを確認し適したものを選択してください。もしくは既存サーバのOSが対応しているかを確認してください。
Support Matrix（Product and Operating System）：https://www.elastic.co/jp/support/matrix
最後にその他インストールするパッケージの検討の観点について記載します。
ElasticsearchとLogstashはJDKを使用します。
JAVA_HOMEを設定してください。なお、使用可能なJDKについてはSupport Matrix（Product and JVM）を参照してください。■推奨設計
Elasticsearch Serviceで推奨されている構成を記載します。
| プロダクト | JVMメモリ | 物理メモリ | CPUコア数 | ディスク |
|---|---|---|---|---|
| Elasticsearch（データノード） | 2GB | 4GB | 不明 | 120GB |
| Elasticsearch（マスター候補ノード） | 500MB | 1GB | 不明 | 不明 |
| Elasticsearch（MLノード） | 500MB | 1GB | 不明 | 不明 |
| Kibana | – | 1GB | 不明 | 不明 |
ただし、上記はデータ量に応じてスペックを上げていくことを前提にしています。
柔軟にスペックを変更できない環境の場合は、初回構築から最大スペックでサーバ構築することをお勧めします。
■非推奨設計
認証設計ではElasticsearchの認証方法およびロールの設計を行います。 デフォルト設定では認証機能を使用しませんが、以下の場合は認証機能を使用する必要があります。
Elasticsearchの認証方式と検討の観点を記載します。
Elasticsearchの権限管理はロールベースで行われます。 ロールの設計では、Elasticsearchのロールの設計および、ロールの作成を行います。 Elasticsearchにはデフォルトでいくつかのロールが作成されています。Elasticsearch Reference [7.5] ＞ Secure a cluster ＞ User authorization ＞ Built-in rolesで確認できます。 ロールが不足していれば新規に設計、作成してください。
Elastic Stackが出力するログの種類とログローテーションの設計をします。
Elastic Stackが出力できるログについて記載します。
| ログの種類 | デフォルトの出力設定 | ログローテーション機能 | デフォルトのローテーショントリガー | デフォルトの保存履歴 | 概要へのリンク |
|---|---|---|---|---|---|
| サーバログ | ON | 有り | 1日もしくは128MB | 2GB | – |
| デプリケーションログ | ON | 有り | 1G | 4ファイル | Deprecation logging |
| 検索遅延ログ | OFF | 有り | 1G | 4ファイル | Search Slow Log |
| インデックス遅延ログ | OFF | 有り | 1G | 4ファイル | Index Slow Log |
| 監査ログ | OFF | 有り | 1日 | – | Elasticsearch Audit Trail and Log File Filter Policies Explained |
ログは通常のフォーマットおよびJsonフォーマットのログを出力できます。
遅延ログはインデックスごとに設定できるため、構築時に検討する必要はありません。
Kibanaではデフォルトのログ出力先が標準出力になっています。
| ログの種類 | デフォルトの出力設定 | ログローテーション機能 | デフォルトのローテーショントリガー | デフォルトの保存履歴 | 概要へのリンク |
|---|---|---|---|---|---|
| サーバログ | ON | 無し | – | – | – |
| 監査ログ | OFF | 無し | – | – | Audit Logging |
| ログの種類 | デフォルトの出力設定 | ログローテーション機能 | デフォルトのローテーショントリガー | デフォルトの保存履歴 | 概要へのリンク |
|---|---|---|---|---|---|
| アプリケーションログ | ON | 有り | 100MB | 30ファイル | – |
| 遅延ログ | OFF | 有り | 100MB | 30ファイル | Slowlog |
ログは通常のフォーマットまたはJsonフォーマットのログを出力できます。フォーマットの変更はlogstash.ymlにlog.format: jsonを追記することで変更できます。
| ログの種類 | デフォルトの出力設定 | ログローテーション機能 | デフォルトのローテーショントリガー | デフォルトの保存履歴 | 概要へのリンク |
|---|---|---|---|---|---|
| アプリケーションログ | ON | 有り | 起動時 | 7ファイル | – |
Kibanaで閲覧したい情報を検討します。
検討するのは以下のような内容です。
FilebeatにはApacheなど、よく利用されるミドルウェアのログを簡単に収集するためのモジュールがあります。利用できるモジュールについては Filebeat Reference [7.5] ＞ Modules を参照してください。
Filebeatモジュール使用の検討では、Filebeatモジュールを用いてログを収集するかどうか検討します。
Filebeatモジュールはいくつかのコマンドを実行するだけでログを収集することができます。収集したログがどのようにElasticsearchに登録されるか、どのようなダッシュボードが作成されるかはKibanaのデモサイトで確認することができます。
ただし、以下に記載するCASE1のような使い方はできないため、注意してください。
Filebeatモジュールを使用し、Logstashを使わない場合は以下に記載するインデックス単位の設計とフィールド設計、FilebeatとLogstashの構成（オプション）の実施は不要です。モジュールとして定義された設定が利用されます。
レプリカ設計、シャード設計、ライフサイクル設計ではモジュールのデフォルト設定で良いか検討してください。デフォルト設定から変更することも可能です。
FilebeatとLogstashの構成では、1サーバで複数ログを取り込む場合、FilebeatとLogstashをどのような構成にするのか決定します。
構成は次の3つから選択できます。
■シングルパイプライン処理方式
Filebeatで複数のファイルを読み取り、Logstashの単一のパイプラインに渡す方式です。 単一のログを取り込む場合と処理フローは変わりませんが、LogstashのFilter部分の設定が複雑になり、管理しにくい状態になる可能性があります。 Filterでの処理がほぼ無い場合にお勧めの方式です。
■マルチパイプライン処理方式
Filebeatで複数のファイルを読み取り、Logstashにはログに対応したパイプラインを用意する方式です。パイプラインへの振り分けはLogstashのPipelineプラグインを利用します。 Filterをログごとに管理できますので、ログごとにFilterでの処理がある場合にお勧めの方式です。
ただし、後続のパイプラインへイベントをコピーして渡す仕組みのため、他の方式よりもメモリの使用量が増加することに注意してください。パイプラインを多段にすることは、避けるべきだと考えます。
■マルチFilebeat処理方式
Filebeatプロセスを複数起動し、LogstashにはFilebeatプロセスに対応したパイプラインを用意する方式です。
プロセスが増えるため、管理が煩雑となります。またモニタリング機能が使用できなくなります。 １つのFilebeatプロセスでは処理しきれないほどのログ量がある場合にのみ採用してください。
インデックス単位の設計では、収集するログを格納するインデックスを決定します。 今後の集計を考慮して、同じヴィジュアライズで表現したいデータは同じプレフィックスとなるようにインデックス名を決定するのがいいでしょう。
■サンプル設計
インデックスは以下の命名規則とし、格納するデータも命名に合わせました。
システム名 + “-” + ミドルウェア／アプリケーション名 + “-” + ログの種類 + “-” + サブシステム名 + “-” + 日付
例) xxxx-apache-access-backend-2019.12.01 xxxx-apache-access-frontend-2019.12.01
apache tomcaterror accessフィールド設計ではインデックスに含める項目と項目の階層構造、項目名、項目の型を設計します。閲覧したい情報の検討で洗い出した項目を定義してください。
Elasticsearchでは動的に項目を増減でき、フィールドの型もデータ投入時にElasticsearchが推測してくれるため、フィールド設計は不要に思えるかもしれません。 しかし、項目の型を決定し、Elasticsearchのテンプレート機能を使用してElasticsearchによる型の推測を抑止するのは以下の2つの点でとても重要です。
■推奨設計
項目名はElasticが提供するモジュールなどと合わせて、小文字のスネークケースを推奨します。
項目の型は下記のいずれかを使用してください。
Elasticsearchには上記の型以外も存在します。全量は下記を参照してください。必要があれば他の型の使用を検討してください。
https://www.elastic.co/guide/en/elasticsearch/reference/7.5/mapping-types.html
KibanaのLogs機能を使用する場合、最低限以下の項目を定義することを推奨します。 Logsのデフォルト設定となっている項目であり、またFilebeat7.5のモジュールでは下記の項目を持つ仕様になっているため、Filebeatモジュールの併用がしやすくなるためです。
| 項目名 | 項目の説明 |
|---|---|
| @timestamp | ログに刻印されているログ出力日時 |
| event.created | Elasticsearchに登録された日時 |
| event.dataset | モジュールとログの種類（apache.access、apache.errorなど） |
| log.level | ログレベル |
| message | ログメッセージ |
レプリカ設計では、インデックスごとにレプリカの数を決定します。
レプリカとは簡単に説明するとインデックスのコピーです。レプリカ数を1と設定すると、オリジナルのインデックスに対して、コピーされたインデックス（レプリカ）が1つ別ノードに保存されます。
レプリカは主に次の2つの理由で重要です。
■推奨設計
レプリカ数1（デフォルト設定）を推奨します。 データノード数が1つの場合は、レプリカ数0を推奨します。レプリカが作成できずElasticsearchのステータスが常にyellowになるためです。レプリカ数0を設定している場合はステータスがgreenとなります。
シャード設計では、インデックスごとにシャード数を決定します。
『Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。 Elasticsearchではインデックス作成の際にシャード数を設定します。 既存のインデックスのシャード数を変更することは出来ないため、最初のドキュメントをインデックスに投入する前にシャード数を決定しなければなりません。 最初はインデックスのサイズからシャード数を算出するにあたって、それぞれのシャードのサイズの目安を30GBにします。』
（Amazon Web Services ブログ：Amazon Elasticsearch Service をはじめよう: シャード数の算出方法より）
■推奨設計
以下の計算によりシャード数を算出します。
シャード数 = インデックスのサイズ / 30GB + 1 ※ 小数点以下切り捨て
ここまで推奨設計、サンプル設計と同じ設計の場合、1日に出力されるログの量が30GB以下の場合は、シャード数は1（デフォルト値）を推奨します。
Elasticsearchのインデックスライフサイクル管理ではインデックスを以下の4つの状態で管理します。
インデックスにはそれぞれライフサイクルポリシーを設定できます。 ライフサイクルポリシーでは状態が変わるトリガーおよび、状態が変わった時に実行するアクションを定義できます。
ライフサイクル設計ではこのライフサイクルポリシーを決定します。
■推奨設計
インデックス単位の設計でインデックスを日次で分けている場合、ライフサイクルポリシーはHotからDeleteへ直接推移する設定を推奨します。 ライフサイクル設計ではインデックスの保存日数のみ決定すれば良いです。
一方、インデックスを時間で分割しておらず永遠に肥大化し続ける場合、ロールオーバーの設計を合わせて行う必要があります。
インデックス設計後、再度データノード数が妥当か検討します。
1ノードのディスクサイズは1.5TB以下が望ましいです。
データノード数 = （全ログサイズ（GB) * 1.1 * 1.25 / 1.5TB） + 1 ※ 小数点以下切り捨て
全インデックスのシャード数を算出します。Elasticsearchではレプリカ数分シャードがコピーされます。従ってインデックスのシャード数は以下の式で算出できます。
インデックスのシャード総数 = インデックスのシャード数 * ( レプリカ数 + 1 ）
例えばApacheのアクセスログをシャード数1、レプリカ数1、xxxx-apache-access-backend-yyyy.MM.ddというインデックス単位で10日分保存している場合、 1つのインデックスのシャード総数は2となります。また、10日分保存するため、インデックスは最大10個存在するので、Apacheのアクセスログのシャード総数は 2 * 10インデックス = 20 となります。
1データノードあたりのシャード数はヒープメモリ1GBあたり20未満にすることが推奨されています。
データノード数 = 全ログのシャード総数 / (ヒープメモリサイズ（GB） * 20 ) + 1 ※ 小数点以下切り捨て
データ量によるノード数の決定およびシャード数によるノード数の決定の結果、ノード数が多い方に合わせてデータノード数を決定します。
本ドキュメントは以下の文書を基に作成しました。
Elasticsearch Reference [7.5]
https://www.elastic.co/guide/en/elasticsearch/reference/7.5/index.html
Kibana Guide [7.5]
https://www.elastic.co/guide/en/kibana/7.5/index.html
Logstash Reference [7.5]
https://www.elastic.co/guide/en/logstash/7.5/index.html
Filebeat Reference [7.5]
https://www.elastic.co/guide/en/beats/filebeat/7.5/index.html
Elasticsearchリファレンス [5.4] ＞ 始めてみよう ＞ 基本概念
https://www.elastic.co/guide/jp/elasticsearch/reference/5.4/gs-basic-concepts.html
Elastic Stackの標準構成（ロギング編）
https://www.elastic.co/jp/blog/elastic-stack-standard-deployment-for-logging
Elasticsearchの運用に関する典型的な4つの誤解
https://www.elastic.co/jp/blog/how-to-configure-elasticsearch-cluster-better
Elasticsearchクラスターのシャード数はいくつに設定すべきか？
https://www.elastic.co/jp/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
Amazon Web Services ブログ：Amazon Elasticsearch Service をはじめよう: シャード数の算出方法
https://aws.amazon.com/jp/blogs/news/get-started-with-amazon-elasticsearch-service-how-many-shards-do-i-need/
本ドキュメントではElastic Stackを用いたログ収集の設計ノウハウについて記載しました。
Elastic Stackでは集約したログを可視化する以外にも、レポート、アラート、機械学習に利用することができます。
是非本ドキュメントを参考にElastic Stackを導入して頂き、より良いサービスの提供にご活用頂きたいです。
本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。
Copyright 2018 TIS Inc.keyboard_arrow_up