第33章 集計ロギングのサイジングに関するガイドライン

Elasticsearch、Fluentd、Kibana (EFK) スタックは、OpenShift Container Platform インストール内部で実行されるノードとアプリケーションからログを集計します。デプロイされると、Fluentd を使用して、すべてのノード、プロジェクト、Pod からのイベントログを Elasticsearch (ES) に集計します。また、Kibana Web UI が一元化されており、ユーザーと管理者は集計されたデータを使用して、多彩な視覚化機能およびダッシュボードを作成できます。

Fluentd 一括アップロードにより JSON 形式でインデックスにログが記録されてから、Elasticsearch により検索要求が該当のシャードに転送されます。

集計ロギングスタックを OpenShift Container Platform にインストールする一般的な手順は、「コンテナーログの集計」に記載されています。インストールガイドを参照する際にいくつかの重要な事項に留意してください。

ロギング Pod をクラスター上に均等に分散させるため、空のノードセレクターを使用する必要があります。

$ oc adm new-project logging --node-selector=""

これは、後で実行されるノードのラベリングと共に、ロギングプロジェクトへの Pod 配置を制御します。これでロギングプロジェクトを作成できます。

$ oc project logging

Elasticsearch (ES) は、ノード障害に対する回復性を確保するために、少なくとも 3 つのクラスターサイズでデプロイする必要があります。これは openshift_logging_es_cluster_size パラメーターをインベントリーホストファイルに設定することで指定されます。

パラメーターの詳細の一覧については、「Ansible 変数」を参照してください。

既存の Kibana インストールがない場合は、kibana.example.com を openshift_logging_kibana_hostname への値として使用します。

イメージがレジストリーからすでに取得されているかどうかや、クラスターのサイズによっては、インストールに時間がかかる場合があります。

logging namespace 内部で、oc get all を実行してデプロイメントを確認できます。

$ oc get all

NAME                          REVISION                 REPLICAS      TRIGGERED BY
logging-curator               1                        1
logging-es-6cvk237t           1                        1
logging-es-e5x4t4ai           1                        1
logging-es-xmwvnorv           1                        1
logging-kibana                1                        1
NAME                          DESIRED                  CURRENT       AGE
logging-curator-1             1                        1             3d
logging-es-6cvk237t-1         1                        1             3d
logging-es-e5x4t4ai-1         1                        1             3d
logging-es-xmwvnorv-1         1                        1             3d
logging-kibana-1              1                        1             3d
NAME                          HOST/PORT                PATH          SERVICE              TERMINATION   LABELS
logging-kibana                kibana.example.com                     logging-kibana       reencrypt     component=support,logging-infra=support,provider=openshift
logging-kibana-ops            kibana-ops.example.com                 logging-kibana-ops   reencrypt     component=support,logging-infra=support,provider=openshift
NAME                          CLUSTER-IP               EXTERNAL-IP   PORT(S)              AGE
logging-es                    172.24.155.177           <none>        9200/TCP             3d
logging-es-cluster            None                     <none>        9300/TCP             3d
logging-es-ops                172.27.197.57            <none>        9200/TCP             3d
logging-es-ops-cluster        None                     <none>        9300/TCP             3d
logging-kibana                172.27.224.55            <none>        443/TCP              3d
logging-kibana-ops            172.25.117.77            <none>        443/TCP              3d
NAME                          READY                    STATUS        RESTARTS             AGE
logging-curator-1-6s7wy       1/1                      Running       0                    3d
logging-deployer-un6ut        0/1                      Completed     0                    3d
logging-es-6cvk237t-1-cnpw3   1/1                      Running       0                    3d
logging-es-e5x4t4ai-1-v933h   1/1                      Running       0                    3d
logging-es-xmwvnorv-1-adr5x   1/1                      Running       0                    3d
logging-fluentd-156xn         1/1                      Running       0                    3d
logging-fluentd-40biz         1/1                      Running       0                    3d
logging-fluentd-8k847         1/1                      Running       0                    3d

最終的には以下のようなセットアップになります。

$ oc get pods -o wide

NAME                          READY     STATUS      RESTARTS   AGE       NODE
logging-curator-1-6s7wy       1/1       Running     0          3d        ip-172-31-24-239.us-west-2.compute.internal
logging-deployer-un6ut        0/1       Completed   0          3d        ip-172-31-6-152.us-west-2.compute.internal
logging-es-6cvk237t-1-cnpw3   1/1       Running     0          3d        ip-172-31-24-238.us-west-2.compute.internal
logging-es-e5x4t4ai-1-v933h   1/1       Running     0          3d        ip-172-31-24-235.us-west-2.compute.internal
logging-es-xmwvnorv-1-adr5x   1/1       Running     0          3d        ip-172-31-24-233.us-west-2.compute.internal
logging-fluentd-156xn         1/1       Running     0          3d        ip-172-31-24-241.us-west-2.compute.internal
logging-fluentd-40biz         1/1       Running     0          3d        ip-172-31-24-236.us-west-2.compute.internal
logging-fluentd-8k847         1/1       Running     0          3d        ip-172-31-24-237.us-west-2.compute.internal
logging-fluentd-9a3qx         1/1       Running     0          3d        ip-172-31-24-231.us-west-2.compute.internal
logging-fluentd-abvgj         1/1       Running     0          3d        ip-172-31-24-228.us-west-2.compute.internal
logging-fluentd-bh74n         1/1       Running     0          3d        ip-172-31-24-238.us-west-2.compute.internal
...
...

各 ES インスタンスに割り当てられる RAM の容量はデフォルトで 8 GB です。openshift_logging_es_memory_limit は openshift-ansible ホストインベントリーファイルで使用されるパラメーターです。この値の半分が個々の elasticsearch Pod java プロセスのヒープサイズに渡されることに注意してください。

EFK のインストールの詳細はこちらを参照してください。

$ while read node; do oc label nodes $node logging-infra-fluentd=true; done < 20_fluentd.lst

$ oc label nodes 10.10.0.{100..119} logging-infra-fluentd=true

レート制限

Red Hat Enterprise Linux (RHEL) 7 では、systemd-journald.socket ユニットはブートプロセスで/dev/log を作成し、入力を systemd-journald.service に渡します。すべての syslog() 呼び出しはジャーナルに移ります。

Rsyslog は imjournal モジュールをジャーナルファイルのデフォルトの入力モードとして使用します。このトピックの詳細については、「Interaction of rsyslog and journal」を参照してください。

簡易テストハーネスを開発して、logger をクラスターノード上で使用し、システムログ内にさまざまなレートでさまざまなサイズのエントリーを記録しました。systemd-219-19.el7.x86_64 を搭載したデフォルトの Red Hat Enterprise Linux (RHEL) 7 インストールにおける所定のロギングレート (毎秒約 40 行) によるテストシミュレーションで、デフォルトのレート制限 rsyslogd に達しました。これらの制限を調整した後、ローカルジャーナルファイルが破損したため、エントリーの journald への書き込みが停止しました。この問題は以降のバージョンの systemd で解決されています。

スケールアップ

プロジェクトをスケールアップすると、デフォルトのロギング環境で調整が必要になる場合があります。systemd-219-22.el7.x86_64 に更新した後、以下を実行します。

$IMUXSockRateLimitInterval 0
$IMJournalRatelimitInterval 0

上記の行を /etc/rsyslog.conf に追加します。

# Disable rate limiting
RateLimitInterval=1s
RateLimitBurst=10000
Storage=volatile
Compress=no
MaxRetentionSec=30s

また、上記を /etc/systemd/journald.conf に追加します。

ここで、サービスを再起動します。

$ systemctl restart systemd-journald.service
$ systemctl restart rsyslog.service

これらの設定は、一括アップロードのバースト性を担う設定です。

レート制限を削除した後、システムロギングデーモンの CPU 使用率が高くなることがあります。以前はスロットルされていた可能性のあるメッセージが処理されるためです。

Rsyslog (ratelimit.interval、ratelimit.burst を参照してください) はジャーナルからのエントリー読み出しを 300 秒に 10,000 メッセージに制限するよう設定されます。経験則として、rsyslog レート制限を systemd-journald レート制限に調節しておくことを推奨します。

必要なスケールを最初のデプロイメントで指定しなかった場合、影響を最小限に抑えてクラスターを調整するには、更新したパラメーター値 openshift_logging_es_cluster_size でインベントリーファイルを更新してから、Ansible ロギング Playbook を再度実行します。詳細については、「Elasticsearch 管理操作の実行」のセクションを参照してください。

Elasticsearch インデックスはシャードとそれに対応するレプリカシャードのコレクションです。これにより ES は高可用性を内部に実装しているので、ハードウェアベースのミラーリング RAID のバリアントを使用する必要はほとんどありません。RAID 0 を使用して全体的なディスクパフォーマンスを向上することは可能です。

それぞれの検索要求は、インデックス内のそれぞれのシャードのコピーに一致する必要があります。各 ES インスタンスには独自のストレージが必要ですが、OpenShift Container Platform デプロイメントで提供できるのはすべての Pod で共有されるボリュームだけです。したがって、Elasticsearch は単一ノードで実装しないでください。

永続ボリュームを各 Elasticsearch デプロイメント設定に追加して、レプリカシャードごとに 1 つのボリュームを割り当てます。これは、OpenShift Container Platform では多くの場合、Persistent Volume Claim (永続ボリューム要求) によって実行されます。

PVC の名前は openshift_logging_es_pvc_prefix 設定に基づいて指定する必要があります。詳細は「永続的な Elasticsearch ストレージ」を参照してください。

以下に示すのは、OpenShift Container Platform 集計ロギングの容量計画のガイドラインです (サンプルシナリオ)。

前提条件:

ベースライン (1 分あたり 256 文字 15 KB/分)

ロギング環境に必要なロギングスループットおよびディスク容量の合計を計算するには、お使いのアプリケーションに関する知識が必要です。たとえば、アプリケーションが平均して 1 秒あたり 10 行、1 行あたり 256 バイトをロギングする場合、アプリケーションごとのスループットとディスク容量は以下のように計算されます。

 (bytes-per-line * (lines-per-second) = 2560 bytes per app per second
 (2560) * (number-of-pods-per-node,100) = 256,000 bytes per second per node
 256k * (number-of-nodes) = total logging throughput per cluster

Fluentd では systemd journal および /var/lib/docker/containers/ からのログを Elasticsearch に送信します。詳細はこちらを参照してください。

最適なパフォーマンスを得るには、ローカルの SSD ドライブの使用を推奨します。Red Hat Enterprise Linux (RHEL) 7 では、SATA ディスク以外のすべてのブロックデバイスについては deadline IO スケジューラーがデフォルトです。SATA ディスクについては、デフォルトの IO スケジューラーは cfq になります。

ES 用のストレージのサイジングは、インデックスの最適化方法よって大きく変わります。このため、必要なデータ量とアプリケーションログデータの集計方法を事前に検討しておく必要があります。一部の Elasticsearch ユーザーは、絶対的なストレージ使用率をおよそ 50% に維持し、常に 70% 未満にする必要があることを確認しています。これは、大規模なマージ操作時に Elasticsearch が応答しなくなるのを回避するのに役立ちます。