今日の Kubernetes へのログイン (それだけではありません): 期待と現実

2019 年現在、Kubernetes でのログ集約の標準ソリューションはまだありません。 この記事では、実際の実践例を使用して、私たちの検索、遭遇した問題、およびその解決策を共有したいと思います。

ただし、最初に予約しておきますが、ログを収集することで、顧客ごとに理解できる内容は大きく異なります。

• 誰かがセキュリティと監査ログを見たいと思っています。
• 誰か - インフラストラクチャ全体の集中ログ。
• また、バランサーなどを除いて、アプリケーション ログのみを収集するだけで十分な場合もあります。

以下は、さまざまな「ウィッシュリスト」をどのように実装したか、そしてどのような困難に遭遇したかについてのカットです。

理論: ロギングツールについて

ロギング システム コンポーネントの背景

ロギングは大きな進歩を遂げ、その結果、ログを収集および分析するための方法論が開発され、今日私たちが使用しているものになっています。 1950 年代に戻ると、Fortran は標準入出力ストリームの類似物を導入し、プログラマーがプログラムをデバッグするのに役立ちました。 これらは、当時のプログラマーの作業を容易にした最初のコンピューター ログでした。 今日、私たちはそれらの中にログシステムの最初のコンポーネントを見ます - ログのソースまたは「プロデューサー」.

コンピューター サイエンスは静止していませんでした。コンピューター ネットワークが登場し、最初のクラスターが誕生しました。複数のコンピューターで構成される複雑なシステムが動作し始めました。 現在、システム管理者は複数のマシンからログを収集する必要があり、特殊なケースでは、システム障害を調査する必要がある場合に備えて OS カーネル メッセージを追加できます。 集中ログ収集システムを説明するために、2000 年代初頭に発行された RFC 3164、remote_syslog を標準化しました。 これは、別の重要なコンポーネントがどのようにして現れたかです。 ログコレクター そしてその保管場所。

ログの量が増加し、Web テクノロジーが広く導入されるにつれて、ユーザーにどのようなログを表示する必要があるかという疑問が生じました。 シンプルなコンソール ツール (awk/sed/grep) は、より高度なコンソール ツールに置き換えられました。 ログビューア - XNUMX番目のコンポーネント。

ログの量が増加したため、別のことが明らかになりました。ログは必要ですが、すべてではないということです。 また、ログが異なれば必要な保存レベルも異なります。5 日で失われる可能性のあるログもあれば、XNUMX 年間保存する必要があるログもあります。 そこで、データ フローのフィルタリングとルーティングを行うコンポーネントがロギング システムに追加されました。これをロギング システムと呼びます。 フィルタ.

ストレージもまた、通常のファイルからリレーショナル データベース、そしてドキュメント指向のストレージ (Elasticsearch など) へと大きな進歩を遂げました。 そのため、ストレージはコレクターから分離されました。

最終的には、ログという概念自体が、歴史のために保存したい一種の抽象的なイベントの流れにまで拡張されました。 というか、調査や分析レポートの作成が必要になった場合に備えて……。

その結果、比較的短期間のうちに、ログ収集はビッグ データのサブセクションの XNUMX つと呼ぶにふさわしい重要なサブシステムに発展しました。

かつては普通の印刷物が「ロギング システム」として十分だったとしても、今では状況は大きく変わりました。

Kubernetes とログ

Kubernetes がインフラストラクチャに導入されたとき、ログ収集という既存の問題も回避されませんでした。 ある意味、インフラストラクチャ プラットフォームの管理は簡素化されただけでなく、同時に複雑化しました。 多くの古いサービスはマイクロサービスへの移行を開始しています。 ログのコンテキストでは、これはログ ソースの数の増加、その特殊なライフ サイクル、およびログを通じてすべてのシステム コンポーネントの関係を追跡する必要性に反映されています...

今後を見据えると、残念ながら、Kubernetes には他のすべてのオプションと比較できる標準化されたロギング オプションは存在しないと言えます。 コミュニティで最も人気のあるスキームは次のとおりです。

• 誰かがスタックを展開します EFK (Elasticsearch、Fluentd、Kibana);
• 誰かが最近リリースされたものを試しています ロキ または使用します ロギングオペレータ;
• 私達 (おそらく私たちだけではないでしょうか?..) 私自身の開発にはほぼ満足しています - ログハウス...

原則として、K8s クラスターでは次のバンドルを使用します (セルフホスト型ソリューションの場合)。

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + ログハウス.

ただし、インストールと構成の手順については詳しく説明しません。 その代わりに、それらの欠点と、ログ一般の状況に関するよりグローバルな結論に焦点を当てます。

K8s のログを使って練習する

「日々の記録」、皆さんは何人いらっしゃいますか？

かなり大規模なインフラストラクチャからログを一元的に収集するには、かなりのリソースが必要となり、ログの収集、保存、処理に費やされます。 さまざまなプロジェクトを運営する中で、さまざまな要件やそれに伴う運用上の問題に直面しました。

クリックハウスを試してみよう

5000 秒あたり XNUMX 行を超えるログを非常に頻繁に生成するアプリケーションを備えたプロジェクトの集中ストレージを見てみましょう。 彼のログを ClickHouse に追加して作業を開始しましょう。

最大限のリアルタイム性が必要になるとすぐに、ClickHouse を備えた 4 コア サーバーはディスク サブシステム上で過負荷状態になります。

このタイプの読み込みは、ClickHouse でできるだけ早く書き込もうとしているためです。 また、データベースはこれに反応してディスク負荷が増加し、次のエラーが発生する可能性があります。

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

ことは事実である MergeTree テーブル ClickHouse では (ログ データが含まれています)、書き込み操作中に独自の問題が発生します。 これらに挿入されたデータにより一時パーティションが生成され、その後メイン テーブルとマージされます。 その結果、記録はディスク上で非常に負荷がかかることが判明し、また、上記で通知を受けた制限の対象となります。1 秒間にマージできるサブパーティションの数は 300 個までです (実際には、これは 300 個の挿入です)毎秒）。

この動作を回避するには、 ClickHouse に書き込む必要があります できるだけ大きな部分で、1 秒に 2 回を超えないようにします。 ただし、大量の書き込みを行うと、ClickHouse での書き込み頻度を減らす必要があることがわかります。 これにより、バッファ オーバーフローやログの損失が発生する可能性があります。 解決策は Fluentd バッファを増やすことですが、メモリ消費量も増加します。

注意: ClickHouse を使用したソリューションのもう XNUMX つの問題点は、私たちの場合 (ログハウス) のパーティショニングが接続された外部テーブルを通じて実装されているという事実に関連していました。 マージテーブル。 これは、メタテーブルがすべてのパーティション (明らかに必要なデータが含まれていないパーティションであっても) を反復処理するため、長い時間間隔でサンプリングする場合、過剰な RAM が必要になるという事実につながります。 ただし、このアプローチは、ClickHouse の現在のバージョンでは時代遅れであると安全に宣言できます (c 18.16).

その結果、すべてのプロジェクトに ClickHouse でリアルタイムにログを収集するのに十分なリソースがあるわけではないことが明らかになりました (より正確には、ログの分散が適切ではないでしょう)。 さらに、以下を使用する必要があります。 アキュムレータこれについては後で説明します。 上記のケースは実際にあります。 そして当時、私たちはお客様に適し、遅延を最小限に抑えてログを収集できる、信頼性が高く安定したソリューションを提供できませんでした...

Elasticsearchについてはどうですか?

Elasticsearch は重いワークロードを処理することが知られています。 同じプロジェクトで試してみましょう。 これで、負荷は次のようになります。

Elasticsearch はデータ ストリームをダイジェストすることができましたが、そのようなボリュームを Elasticsearch に書き込むと、CPU が大幅に消費されます。 これはクラスターを組織することによって決定されます。 技術的にはこれは問題ではありませんが、ログ収集システムを動作させるためだけにすでに約 8 コアを使用しており、システム内に高負荷のコンポーネントが追加されていることが判明しました...

結論: このオプションは正当化できますが、それはプロジェクトが大規模で、その管理者が集中ログ システムに多大なリソースを費やす準備ができている場合に限られます。

そこで当然の疑問が生じます。

本当に必要なログは何ですか?

アプローチそのものを変えてみましょう。ログは情報を提供すると同時に、内容を網羅するものではありません。 каждое システム内のイベント。

成功しているオンライン ストアがあるとします。 どのログが重要ですか? たとえば、支払いゲートウェイからできるだけ多くの情報を収集することは素晴らしいアイデアです。 ただし、製品カタログ内のイメージ スライシング サービスからのログすべてが当社にとって重要であるわけではありません。エラーと高度な監視だけで十分です (たとえば、このコンポーネントが生成する 500 件のエラーの割合)。

そこで私たちは次のような結論に達しました。 集中ログが常に正当化されるわけではない。 多くの場合、クライアントはすべてのログを 5 か所に収集したいと考えますが、実際には、ログ全体から、ビジネスにとって重要なメッセージの条件付き XNUMX% のみが必要となります。

• たとえば、コンテナー ログのサイズとエラー コレクター (Sentry など) のみを構成するだけで十分な場合があります。
• 多くの場合、エラー通知と大規模なローカル ログ自体がインシデントを調査するのに十分な場合があります。
• 私たちは、機能テストとエラー収集システムだけを使って対応するプロジェクトがありました。 開発者はログ自体を必要としませんでした。エラー トレースからすべてを確認していました。

人生のイラスト

別の話が良い例として役立ちます。 私たちは、Kubernetes が導入されるずっと前に開発された商用ソリューションをすでに使用していたクライアントのセキュリティ チームからリクエストを受けました。

集中ログ収集システムと企業の問題検出センサーである QRadar を「友達にする」必要がありました。 このシステムは、syslog プロトコル経由でログを受信し、FTP から取得できます。 ただし、fluentd 用のremote_syslog プラグインと統合することはすぐにはできませんでした。 （結局のところ、 私たちは一人ではありません)。 QRadar のセットアップに関する問題は、クライアントのセキュリティ チーム側にあることが判明しました。

その結果、ビジネスクリティカルなログの一部は FTP QRadar にアップロードされ、残りの部分はリモート syslog 経由でノードから直接リダイレクトされました。 このために私たちはこうも書きました 簡単なチャート - おそらく、誰かが同様の問題を解決するのに役立つでしょう...結果として得られたスキームのおかげで、クライアント自身が重要なログを受信して​​（お気に入りのツールを使用して）分析し、ログシステムのコストを削減し、節約できるのはログシステムのコストだけです。先月。

別の例は、してはいけないことをよく示しています。 加工のための当社のクライアントのXNUMXつ それぞれの ユーザーからのイベントを複数行に作成 非構造化出力 ログの情報。 ご想像のとおり、このようなログは読み取りにも保存にも非常に不便でした。

ログの基準

このような例から、ログ収集システムの選択に加えて、次のことが必要であるという結論につながります。 ログ自体も設計します！ ここでの要件は何ですか?

• ログは、機械可読形式 (JSON など) である必要があります。
• ログはコンパクトであり、考えられる問題をデバッグするためにログの程度を変更できる必要があります。 同時に、実稼働環境では、次のようなログレベルでシステムを実行する必要があります。 警告 または エラー.
• ログは正規化する必要があります。つまり、ログ オブジェクトでは、すべての行が同じフィールド タイプを持つ必要があります。

構造化されていないログは、ログをストレージにロードするときに問題が発生し、処理が完全に停止する可能性があります。 例として、エラー 400 の例を次に示します。これは、多くの人が Fluentd ログで確実に遭遇するものです。

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

このエラーは、タイプが不安定なフィールドを、既製のマッピングを使用してインデックスに送信していることを意味します。 最も単純な例は、変数を含む nginx ログ内のフィールドです。 $upstream_status。 数値または文字列を含めることができます。 例えば：

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

ログには、サーバー 10.100.0.10 が 404 エラーで応答し、要求が別のコンテンツ ストレージに送信されたことが示されています。 その結果、ログの値は次のようになりました。

"upstream_response_time": "0.001, 0.007"

この状況は非常に一般的であるため、別個に説明する価値さえあります。 ドキュメント内の参照.

信頼性についてはどうですか？

例外なくすべてのログが重要な場合があります。 このため、上で提案/議論した K8 の典型的なログ収集スキームには問題があります。

たとえば、fluentd は有効期間の短いコンテナーからログを収集できません。 私たちのプロジェクトの 4 つでは、対応する注釈によると、データベース移行コンテナは XNUMX 秒未満存続し、その後削除されました。

"helm.sh/hook-delete-policy": hook-succeeded

このため、マイグレーション実行ログはストレージに含まれていませんでした。 この場合、政治が役に立ちます。 before-hook-creation.

もう XNUMX つの例は、Docker ログのローテーションです。 ログに積極的に書き込むアプリケーションがあるとします。 通常の状況では、すべてのログを処理できますが、問題が発生するとすぐに (たとえば、上記で説明した形式が正しくない場合)、処理が停止し、Docker がファイルをローテーションします。 その結果、ビジネスクリティカルなログが失われる可能性があります。

だからこそ ログストリームを分離することが重要です、最も価値のあるものをアプリケーションに直接送信して安全性を確保します。 さらに、いくつかの機能を作成することは不必要ではありません。 ログの「蓄積」、重要なメッセージを保存しながら、ストレージが一時的に利用できなくなっても耐えることができます。

最後に、私たちが忘れてはいけないのは、 サブシステムを適切に監視することが重要です。 そうしないと、fluentd が次のような状態に陥る可能性があります。 CrashLoopBackOff 何も送信しないため、重要な情報が失われる可能性があります。

所見

この記事では、Datadog のような SaaS ソリューションについては取り上げません。 ここで説明されている問題の多くは、ログ収集を専門とする営利企業によって何らかの方法ですでに解決されていますが、さまざまな理由から誰もが SaaS を使用できるわけではありません。 （主なものはコストと152-FZへの準拠です）.

集中ログ収集は一見単純なタスクのように見えますが、決してそうではありません。 次のことを覚えておくことが重要です。

• 詳細にログを記録する必要があるのは重要なコンポーネントのみですが、他のシステムに対して監視とエラー収集を構成できます。
• 不必要な負荷を追加しないように、本番環境のログは最小限に抑える必要があります。
• ログは機械で読み取り可能で、正規化されており、厳密な形式である必要があります。
• 本当に重要なログは、メインのログとは別の別のストリームで送信する必要があります。
• ログ アキュムレータを検討する価値があります。これにより、高負荷のバーストを回避し、ストレージ上の負荷をより均一にすることができます。

これらの単純なルールをどこにでも適用すれば、重要なコンポーネント (バッテリー) が欠けている場合でも、上記の回路が動作することが可能になります。 このような原則に従わない場合、このタスクにより、ユーザーとインフラストラクチャがシステムの高負荷の (同時に非効率な) 別のコンポーネントに簡単に誘導されてしまいます。

PS

私たちのブログもお読みください:

• «loghouse の紹介 - Kubernetes でログを操作するためのオープンソース システム";
• «KubeCon'19 からの Kubernetes エコシステムのリリース: JFrog Container Registry、IBM の Kui、Loki 1.0.0…";
• «モニタリングと Kubernetes (レビューとビデオ レポート)'。

出所： habr.com