ユーリ・ブッシュメレフ「丸太の収集と配達の分野における熊手の地図」 - 報告書の転写

ログはシステムの重要な部分であり、期待どおりに動作している (または動作していない) ことを理解するのに役立ちます。 マイクロサービス アーキテクチャでは、ログの操作は特別なオリンピックの別の分野になります。 大量の質問を一度に解決する必要があります。

• アプリケーションからログを書き込む方法。
• ログをどこに書き込むか。
• 保存および処理のためにログを配信する方法。
• ログを処理および保存する方法。

現在普及しているコンテナ化技術を使用すると、問題を解決するための選択肢の領域に、熊手の上に砂が追加されます。

これはまさに、ユーリ・ブッシュメレフの報告書「丸太の収集と配達の分野における熊手の地図」の転写が述べていることである。

気にしない人は猫の下にいてください。

私の名前はユーリ・ブシュメレフです。 私はラザダで働いています。 今日は、ログをどのように作成し、どのように収集し、そこに何を書くのかについて話します。

私たちはどこから来たのですか？ 私たちは誰ですか？ Lazada は、東南アジア 1 か国で No.4 のオンライン小売業者です。 これらすべての国は、当社のデータセンターに分散されています。 現在、合計 80 つのデータセンターがありますが、これが重要なのはなぜですか? なぜなら、いくつかの決定は、センター間のつながりが非常に弱いという事実によるものだからです。 私たちはマイクロサービスアーキテクチャを採用しています。 すでに 20 個のマイクロサービスがあることに驚きました。 ログを使ってタスクを開始したとき、ログは 6 個しかありませんでした。さらに、かなり大きな PHP のレガシー部分もあり、これも我慢しなければなりません。 現在、これらすべてにより、システム全体で XNUMX 分あたり XNUMX 万を超えるメッセージが生成されています。 次に、私たちがこの状況にどのように対処しようとしているのか、そしてなぜそうなるのかを説明します。

この 6 万件のメッセージを何とか処理しなければなりません。 彼らに対して何をすべきでしょうか？ 必要なメッセージは 6 万件:

• アプリから送信する
• 配達を受け入れる
• 分析と保管のために提供します。
• 分析する
• 何らかの方法で保管します。

XNUMX 万件のメッセージが表示されたとき、私はほぼ同じように見えました。 なぜなら、私たちはほんの数ペニーから始めたからです。 アプリケーションログがそこに書き込まれていることは明らかです。 たとえば、データベースに接続できませんでした。データベースには接続できましたが、何も読み取ることができませんでした。 しかし、これに加えて、各マイクロサービスはアクセス ログも書き込みます。 マイクロサービスに到着するすべてのリクエストはログに記録されます。 なぜこれを行うのでしょうか? 開発者はトレースできることを望んでいます。 各アクセス ログには、traceid フィールドが含まれており、これを使用して特別なインターフェイスがチェーン全体を巻き戻し、トレースを美しく表示します。 トレースはリクエストがどのように行われたかを示し、これは開発者が未確認のガベージに迅速に対処するのに役立ちます。

これをどうやって生きていくか？ ここで、オプションの分野、つまりこの問題が一般的にどのように解決されるかについて簡単に説明します。 ログの収集、送信、保存の問題を解決する方法。

アプリケーションから書き込むにはどうすればよいですか? さまざまな方法があることは明らかです。 おしゃれな仲間たちが教えてくれたように、特にベストプラクティスがあります。 私たちの祖父が私たちに言ったように、オールドスクールにはXNUMXつのタイプがあります。 他の方法もあります。

ログ収集の状況もほぼ同じです。 この部分を解決するための選択肢はそれほど多くありません。 すでにたくさんありますが、まだそれほど多くはありません。

しかし、配信とその後の分析により、バリエーションの数が爆発的に増え始めます。 ここでは各オプションについては説明しません。 主なオプションは、このトピックに興味がある人なら誰でもよく知っていると思います。

Lazada でどのようにそれを行ったのか、そして実際にすべてがどのように始まったのかを説明します。

XNUMX 年前、私は Lazada に来て、丸太に関するプロジェクトに派遣されました。 こんな感じでした。 アプリケーション ログは stdout と stderr に書き込まれました。 すべてがファッショナブルな方法で行われました。 しかし、開発者がそれを標準フローから外した後、どういうわけかインフラストラクチャの専門家がそれを理解するでしょう。 インフラストラクチャの専門家と開発者の間には、「ああ...分かった、シェルを使ってファイルにラップすればそれで終わりだ」と言うリリース担当者もいます。 そして、これらすべてがコンテナーに入っていたため、彼らはそれをコンテナー自体で包み、その中にカタログをマッピングしてそこに置きました。 それが何をもたらしたのかは誰にとっても明らかだと思います。

とりあえずもう少し見てみましょう。 これらのログはどのようにして配信されたのでしょうか? 誰かが td-agent を選択しました。これは実際には Fluentd ですが、完全に Fluentd ではありません。 この 4 つのプロジェクトの関係はまだわかりませんが、ほぼ同じもののようです。 そして、この fluentd は Ruby で書かれており、ログ ファイルを読み取り、ある種の規則性を使用してログ ファイルを JSON に解析します。 それから私はそれらをカフカに送りました。 さらに、Kafka では、API ごとに 4 つの個別のトピックがありました。 なぜ 4 なのか? ライブがあるため、ステージングがあり、stdout と stderr があるためです。 開発者はそれらを作成し、インフラストラクチャ開発者は Kafka でそれらを作成する必要があります。 さらに、Kafka は別の部門によって管理されていました。 そのため、API ごとに XNUMX つのトピックを作成するようにチケットを作成する必要がありました。 誰もがそれを忘れていました。 一般的に、ゴミと大騒ぎがありました。

次にこれをどうしたでしょうか? カフカさんに送りました。 その後、Kafka からのログの半分が Logstash に飛んできました。 丸太の残りの半分は分割されました。 あるグレイログに飛んだ人もいれば、別のグレイログに飛んだ人もいた。 結果として、これらすべてが XNUMX つの Elasticsearch クラスターに入りました。 つまり、この混乱はすべてそこで終わったのです。 そんなことしないでください！

上から見るとこんな感じです。 そんなことしないでください！ ここでは、問題のある領域がすぐに番号でマークされます。 実際にはもっとたくさんありますが、6 つは本当に問題があり、何らかの対処が必要です。 それらについては、今度別途説明します。

ここ (1,2,3) ではファイルを書き込みます。したがって、ここには一度に XNUMX つの rake が存在します。

最初の (1) は、それらをどこかに書く必要があるということです。 API にファイルに直接書き込む機能を与えることが常に望ましいとは限りません。 API はコンテナー内に分離されることが望ましく、読み取り専用であることがさらに望ましいです。 私はシステム管理者なので、これらのことについては少し違った見方をしています。

2,3 番目のポイント (XNUMX) は、API に大量のリクエストが届いていることです。 API は大量のデータをファイルに書き込みます。 ファイルが増えています。 それらを回転させる必要があります。 そうしないと、そこにディスクをストックできなくなるからです。 これらはシェルを介してディレクトリにリダイレクトすることによって作成されるため、ローテーションすることは好ましくありません。 それを見直す方法はありません。 ハンドルを再度開くようにアプリケーションに指示することはできません。 なぜなら、開発者はあなたを愚か者のように見るからです。 通常、標準出力に書き込みます。」 インフラストラクチャ開発者は、copytruncate を logrotate に変更しました。これは、単にファイルのコピーを作成し、元のファイルを転写するだけです。 したがって、通常、これらのコピー処理の間にディスク容量が不足します。

(4) 異なる API には異なる形式がありました。 それらはわずかに異なりますが、正規表現を別の方法で記述する必要がありました。 これらすべてがパペットによって制御されていたため、多数のクラスが独自のゴキブリを抱えていました。 さらに、ほとんどの場合、td-agent はメモリを消費し、愚かになり、動作しているふりをして何もしない可能性があります。 外から見ても、彼が何もしていないことは理解できませんでした。 せいぜい、彼は転んで、後で誰かが彼を拾うだろう。 より正確に言うと、アラートが届き、誰かが手でそれを上げに行きます。

(6) そして最もゴミと無駄があったのは elasticsearch でした。 古いバージョンだったので。 当時は専属のマスターがいなかったからです。 フィールドが重複する可能性のある異種ログがありました。 異なるアプリケーションからの異なるログが同じフィールド名で書き込まれる可能性がありますが、内部には異なるデータが存在する可能性があります。 つまり、XNUMX つのログには、レベルなどのフィールドに整数が含まれます。 別のログにはレベルフィールドに文字列が含まれています。 静的マッピングがない場合、これは非常に素晴らしいことです。 elasticsearch でインデックスをローテーションした後、文字列を含むメッセージが最初に到着する場合、私たちは通常どおり生活しています。 ただし、最初のメッセージが Integer から到着した場合、String から到着した後続のメッセージはすべて単純に破棄されます。 フィールドのタイプが一致しないためです。

私たちはこれらの質問を始めました。 私たちは責任のある人たちを探さないことに決めました。

しかし、何かをしなければなりません! 明らかなことは、基準を確立する必要があるということです。 すでにいくつかの基準がありました。 少し遅れていくつか始めました。 幸いなことに、その時点では、すべての API に対応する単一のログ形式がすでに承認されていました。 これは、サービス間の対話のための標準に直接書き込まれます。 したがって、ログを受け取りたい場合は、この形式でログを記述する必要があります。 誰かがこの形式でログを書き込まない場合、私たちは何も保証しません。

次に、ログの記録、配信、収集の方法について統一規格を策定したいと考えております。 実際、どこに書いてどうやって届けるか。 理想的な状況は、プロジェクトが同じライブラリを使用することです。 Go 用には別のロギング ライブラリがあり、PHP 用には別のライブラリがあります。 私たちが持っている人は皆、それを使うべきです。 現時点では、これについては 80% 成功していると言えます。 しかし、サボテンを食べ続ける人もいます。

そして、そこ (スライド上) に「ログの配信に関する SLA」がかろうじて表示され始めます。 まだ存在していませんが、現在開発中です。 なぜなら、インフラストラクチャが、これこれの形式でこれこれの場所に書き込むと、XNUMX 秒あたり N メッセージ以下であれば、ほぼ確実にこれこれの場所に配信できると指定すると、非常に便利だからです。 これにより、多くの頭痛が軽減されます。 SLA があるなら、これは本当に素晴らしいことです。

どのようにして問題を解決し始めたのでしょうか? 主な問題は td-agent にありました。 ログがどこに行ったのかは不明でした。 配達されていますか？ 彼らは行きますか？ そもそも彼らはどこにいるのでしょうか？ したがって、最初の点は td-agent を置き換えることにしました。 ここでは、何に置き換えるかについてのオプションを簡単に説明しました。

Fluentd。 まず、私は前の仕事で彼に遭遇しました、そして、彼はそこでも定期的に落ちました。 第二に、これはプロフィール上のみで同じことです。

ファイルビート。 それは私たちにとってどのように便利でしたか？ それは Go で行われており、私たちは Go について多くの専門知識を持っているからです。 したがって、何か起こっても、自分たちで何とか追加することができます。 だからこそ、私たちはそれを受け入れませんでした。 そのため、自分で書き直そうとする誘惑さえなくなります。

システム管理者にとっての明らかな解決策は、あらゆる種類の syslog をこの量 (syslog-ng/rsyslog/nxlog) に保存することです。

あるいは、独自の何かを書くこともできますが、これと filebeat は破棄されました。 何かを書くならビジネスに役立つものを書いた方が良いです。 ログを配信するには、既製のものを使用する方が良いでしょう。

したがって、実際の選択は、syslog-ng と rsyslog のどちらを選択するかということになりました。 私が rsyslog に傾いたのは、単に Puppet に rsyslog のクラスがすでに存在しており、それらの間に明らかな違いが見つからなかったからです。 syslog って何ですか、syslog って何ですか。 はい、ドキュメントの質が悪いものもあれば、より優れたものもあります。 こちらはこの方法で実行でき、もう一方は別の方法で実行できます。

rsyslog についても少し説明します。 まず、モジュールがたくさんあるのでかっこいいです。 人間が読める RainerScript (最新の構成言語) を備えています。 標準ツールを使用して td-agent の動作をエミュレートでき、アプリケーションには何も変更が加えられないという素晴らしい特典です。 つまり、td-agent を rsyslog に変更し、その他はすべてそのままにしておきます。 そして、すぐに動作する納品を受け取りました。 次に、rsyslog の mmnormalize は素晴らしい機能です。 ログを解析できますが、Grok や正規表現は使用できません。 抽象構文ツリーを作成します。 コンパイラがソースを解析するのとほぼ同じ方法でログを解析します。 これにより、作業が非常に速くなり、CPU の消費もほとんどなくなり、一般的に非常に優れた機能です。 他にもたくさんのボーナスがあります。 それらにこだわるつもりはありません。

rsyslog には他にも多くの欠点があります。 ボーナスとほぼ同じ額です。 主な問題は、調理方法を知る必要があることと、バージョンを選択する必要があることです。

私たちはログを UNIX ソケットに書き込むことにしました。 /dev/log にはありません。そこには混乱したシステム ログがあり、journald はこのパイプライン内にあるからです。 それでは、カスタムソケットに書き込んでみましょう。 別のルールセットに添付します。 何も干渉しないようにしましょう。 すべてが透明でわかりやすいものになります。 まさにそれが私たちがやったことです。 これらのソケットを含むディレクトリは標準化され、すべてのコンテナに転送されます。 コンテナは必要なソケットを認識し、開いて書き込むことができます。

なぜファイルではないのでしょうか? みんな読んでるから バドゥシェチカに関する記事、ファイルを docker に転送しようとしたところ、rsyslog を再起動した後にファイル記述子が変更され、docker がこのファイルを失ったことが判明しました。 他の何かを開いたままにしますが、書き込みを行っているソケットは開きません。 私たちは、この問題を回避すると同時に、ブロッキングの問題も回避することにしました。

Rsyslog は、スライドに示されているアクションを実行し、リレーまたは Kafka にログを送信します。 カフカは古いやり方を踏襲しています。 リレー - 純粋な rsyslog を使用してログを配信しようとしました。 メッセージ キューを使用せず、標準の rsyslog ツールを使用します。 基本的には機能します。

ただし、この部分 (Logstash/Graylog/ES) にそれらを押し込む方法には微妙な違いがあります。 この部分 (rsyslog-rsyslog) はデータセンター間で使用されます。 これは圧縮された TCP リンクです。これにより、帯域幅を節約でき、それに応じて、チャネルが詰まったときに別のデータ センターからログを受信する可能性が何らかの形で高まります。 なぜなら、私たちには何もかもが悪いインドネシアがあるからです。 ここに絶えず問題が存在します。

アプリケーションから記録したログが最後に到達する可能性を実際に監視するにはどうすればよいかを考えました。 指標を作成することにしました。 rsyslog には独自の統計収集モジュールがあり、これにはある種のカウンターが含まれています。 たとえば、キュ​​ーのサイズや、これこれのアクションで到着したメッセージの数を表示できます。 あなたはすでに彼らから何かを得ることができます。 さらに、設定可能なカスタム カウンターがあり、たとえば、一部の API が記録したメッセージの数が表示されます。 次に、rsyslog_exporter を Python で記述し、それをすべて Prometheus に送信してグラフを構築しました。 Graylog メトリクスが本当に欲しかったのですが、まだ設定する時間がありませんでした。

何が問題でしたか? ライブ API が 50 秒あたり 12 個のメッセージを書き込んでいることを (突然!) 発見したときに問題が発生しました。 これはステージングのないライブ API のみです。 また、Graylog では XNUMX 秒あたり XNUMX メッセージしか表示されません。 そして当然の疑問が生じた：遺体はどこにあるのか？ このことから、Graylog では対処できないという結論に達しました。 調べてみると、確かに、Graylog と Elasticsearch ではこのフローを処理できませんでした。

次に、途中で見つけたその他の発見です。

ソケットへの書き込みはブロックされます。 どうやってそうなった？ 配信に rsyslog を使用していたとき、ある時点でデータ センター間のチャネルが故障しました。 ある場所では配達が停止し、別の場所では配達が停止しました。 これらすべては、rsyslog ソケットに書き込む API を備えたマシンに到達しています。 そこには行列ができていました。 その後、UNIX ソケットに書き込むためのキュー (デフォルトでは 128 パケット) がいっぱいになりました。 そして、アプリケーション内の次の write() はブロックされます。 Go アプリケーションで使用するライブラリを見ると、ソケットへの書き込みはノンブロッキング モードで行われると書かれていました。 何もブロックされていないことを確信していました。 私たちが読んでいるから バドゥシェチカに関する記事それについて書いた人。 しかし、瞬間があります。 この呼び出しの周りには無限ループもあり、メッセージをソケットにプッシュしようとする試みが絶えず行われていました。 私たちは彼に気づきませんでした。 ライブラリを書き直す必要がありました。 それ以来、何度か変更されましたが、現在ではすべてのサブシステムのブロックが解消されました。 したがって、rsyslog を停止しても、何もクラッシュすることはありません。

キューのサイズを監視する必要があります。これは、この熊手を踏まないようにするのに役立ちます。 まず、いつメッセージが失われ始めるかを監視できます。 次に、配送に問題があるかどうかを監視できます。

そしてもう 10 つの不快な瞬間です。マイクロサービス アーキテクチャでは XNUMX 倍の増幅が非常に簡単です。 受信リクエストはそれほど多くありませんが、これらのメッセージがグラフに沿ってさらに移動し、アクセス ログが発生するため、実際にはログの負荷が約 XNUMX 倍に増加します。 残念ながら、正確な数字を計算する時間がありませんでしたが、マイクロサービスとはそういうものです。 このことを念頭に置いておかなければなりません。 現時点では、ログ収集サブシステムが Lazada で最も負荷がかかっていることがわかりました。

elasticsearchの問題を解決するにはどうすればよいですか? すべてのマシンを回ってログを収集する必要がないように、ログを XNUMX か所にすばやく取得する必要がある場合は、ファイル ストレージを使用します。 これは動作することが保証されています。 どのサーバーからでも実行できます。 そこにディスクを挿入し、syslog をインストールするだけです。 この後は、すべてのログが XNUMX か所に集まることが保証されます。 その後、elasticsearch、graylog、その他をゆっくりと構成できます。 ただし、すべてのログはすでに存在しており、さらに、十分なディスク アレイがある限りログを保存できます。

私のレポートの時点では、スキームは次のようになり始めました。 ファイルへの書き込みは事実上停止しました。 おそらく、残りの部分はオフにするでしょう。 API を実行しているローカル マシンでは、ファイルへの書き込みが停止されます。 まず、ファイル ストレージがあり、非常にうまく機能します。 第 XNUMX に、これらのマシンのスペースは常に不足しており、常に監視する必要があります。

Logstash と Graylog を使用したこの部分は、本当に効果的です。 したがって、それを取り除く必要があります。 何かを XNUMX つ選択する必要があります。

Logstash と Kibana を廃棄することにしました。 セキュリティ部門があるからです。 なんのつながり？ これは、X-Pack を使用しない Kibana と Shield を使用しない Kibana では、ログへのアクセス権を区別できないということです。 だからこそ、Graylog を採用しました。 全てが揃っています。 好きではないですが、効果はあります。 新しいハードウェアを購入し、そこに新しい Graylog をインストールし、厳密な形式のすべてのログを別の Graylog に転送しました。 私たちは、異なるタイプの同一フィールドの問題を組織的に解決しました。

新しい Graylog には正確に何が含まれていますか。 すべてを docker に書き込んだだけです。 私たちは大量のサーバーを導入し、7 つの Kafka インスタンス、2.3 つの Graylog サーバー バージョン 5 (Elasticsearch バージョン 100 が必要だったので) を展開しました。 これらはすべて、RAID 中に HDD から取得されたものです。 140 秒あたり最大 XNUMX 万メッセージのインデックス作成速度が確認されました。 XNUMX 週間あたり XNUMX テラバイトのデータという数字が見られました。

そしてまた熊手！ 今後6つの販売を予定しております。 メッセージ数は XNUMX 万件を超えました。 グレイログには噛む時間がありません。 何とかして私たちは再び生き残らなければなりません。

こうして私たちは生き残ったのです。 さらにいくつかのサーバーと SSD を追加しました。 今のところ、私たちはこのように生きています。 現在、私たちはすでに 160 秒あたり XNUMX 個のメッセージを処理しています。 まだ限界には達していないので、実際にどれだけの利益が得られるかは不明です。

これらは私たちの将来の計画です。 これらの中で、最も重要なのはおそらく高可用性です。 まだありません。 複数の車両が同じように構成されていますが、これまでのところ、すべてが XNUMX 台の車両を介して行われています。 それらの間でフェイルオーバーを設定するには時間がかかります。

Graylog からメトリクスを収集します。

レート制限を設けて、帯域幅やその他すべてを犠牲にしないクレイジーな API を XNUMX つ用意します。

そして最後に、これだけのサービスを提供できるように、開発者と何らかの SLA を締結します。 もっと書いたら、ごめんなさい。

そしてドキュメントを書きます。

簡単に言えば、私たちが経験したすべての結果です。 まず、規格です。 第二に、syslog はケーキです。 第三に、rsyslog はスライドに書かれているとおりに動作します。 それでは、質問に移ります。

質問.

質問: なぜ取らないことにしたのですか... (ファイルビート?)

答え: ファイルに書き込む必要があります。 本当はしたくなかったのです。 API が XNUMX 秒あたり数千のメッセージを書き込む場合、XNUMX 時間に XNUMX 回ローテーションしたとしても、これは依然としてオプションではありません。 パイプで書くこともできます。 開発者は私にこう尋ねました。「私たちが書いているプロセスがクラッシュしたらどうなりますか?」 私は彼らに何と答えるべきか見つからず、「まあ、分かった、それはやめましょう」と言いました。

質問: ログを HDFS に書き込まないのはなぜですか?

答え：これは次の段階です。 私たちは最初にそれを検討しましたが、現時点ではこれを行うためのリソースがないため、長期的な解決策として保留されています。

質問: 列形式の方が適しています。

答え： わかりました。 私たちは両手を挙げて賛成です。

質問: rsyslog に書き込んでいます。 そこでは TCP と UDP の両方を使用できます。 しかし、UDP の場合、どうやって配信を保証するのでしょうか?

答え：ポイントは100つあります。 まず、私はログの配信を保証するものではないことをすぐに皆さんに伝えます。 なぜなら、開発者がやって来て、「そこに財務データを書き始めましょう。何かが起こった場合に備えて、どこかに置いておいてください」と言うと、私たちは「素晴らしいです！」と答えるからです。 ソケットへの書き込みのブロックを開始し、これをトランザクションで実行しましょう。そうすれば、あなたはそれを私たちのためにソケットに置くことが保証され、私たちがそれを相手側から確実に受信できるようになります。」 そして現時点では、誰もがすぐにそれを必要としなくなりました。 必要がない場合、どのような質問をすればよいでしょうか? ソケットへの書き込みを保証したくない場合、なぜ配信を保証する必要があるのでしょうか? 私たちは全力を尽くしています。 可能な限り最良の方法で提供するよう努めておりますが、XNUMX% 保証するものではありません。 したがって、財務データをそこに書き込む必要はありません。 このためのトランザクションを含むデータベースがあります。

質問: API がログに何らかのメッセージを生成し、制御をマイクロサービスに転送するときに、異なるマイクロサービスからのメッセージが間違った順序で到着するという問題に遭遇したことがありますか? これは混乱を引き起こします。

答え: 順番が違うのは普通のことです。 これに備えて準備する必要があります。 ネットワーク配信では順序が保証されないため、これには特別なリソースを費やす必要があります。 ファイル ストレージを使用する場合、各 API はログを独自のファイルに保存します。 というか、rsyslog がそれらをディレクトリに分類します。 各 API には独自のログがあり、そこにアクセスして確認し、このログのタイムスタンプを使用して比較できます。 Graylog を参照すると、タイムスタンプによってソートされます。 そこではすべてがうまくいきます。

質問: タイムスタンプはミリ秒単位で異なる場合があります。

答え: タイムスタンプは API 自体によって生成されます。 実際、これが重要な点です。 NTPがあります。 API はメッセージ自体にタイムスタンプを生成します。 rsyslog では追加されません。

質問: データセンター間の相互作用はあまり明確ではありません。 データセンター内では、ログがどのように収集され、処理されたかが明らかです。 データセンター間のやり取りはどのように行われるのでしょうか? それとも、各データセンターは独自の生活を送っているのでしょうか?

答え： ほとんど。 我が国では、各国が XNUMX つのデータセンターに配置されています。 現時点では、XNUMX つの国が異なるデータ センターに配置されるような分散は行っていません。 したがって、それらを組み合わせる必要はありません。 各センターにはログリレーが内蔵されています。 これは Rsyslog サーバーです。 実際には管理マシンが XNUMX 台あります。 彼らも同じ態度です。 しかし今のところ、トラフィックはそのうちの XNUMX つを通過するだけです。 すべてのログを集約します。 万が一に備えてディスクキューを用意しています。 ログをダウンロードして中央データセンター (シンガポール) に送信し、そこから Graylog に送信されます。 そして、各データセンターには独自のファイル ストレージがあります。 接続が失われた場合に備えて、すべてのログがそこに保存されています。 彼らはそこに残るでしょう。 それらはそこに保管されます。

質問：異常事態が発生した場合、そこからログを受信しますか？

答え：そこ（ファイルストレージ）に行って見てもいいよ。

質問: ログが失われていないことをどのように監視しますか?

答え: 私たちは実際に彼らを失いつつあり、それを監視しています。 モニタリングは XNUMX か月前に開始されました。 Go API が使用するライブラリにはメトリクスがあります。 彼女は、ソケットに書き込むことができなかった回数を数えることができます。 現在、そこには賢いヒューリスティックがあります。 そこにはバッファがあります。 そこからソケットにメッセージを書き込もうとします。 バッファがオーバーフローすると、バッファの削除が開始されます。 そして、彼はそれらのうちの何個を落としたかを数えます。 そこでメーターがオーバーフローし始めれば、それがわかります。 これらは現在、prometheus にも登場しており、Grafana でグラフを見ることができます。 アラートを設定できます。 しかし、誰に送るかはまだ明らかではない。

質問: elasticsearch では、ログを冗長性を持って保存します。 レプリカは何個ありますか?

答え：一行。

質問：これは一行だけですか？

答え: これはマスターとレプリカです。 データは XNUMX つのコピーに保存されます。

質問: rsyslog バッファ サイズを何らかの方法で調整しましたか?

答え: データグラムをカスタム UNIX ソケットに書き込みます。 これにより、すぐに 128 キロバイトの制限が課せられます。 これ以上書き込むことはできません。 これを標準に書き込みました。 ストレージにアクセスしたい人は 128 キロバイトを書き込みます。 さらに、図書館は遮断され、メッセージが遮断されたというフラグが立てられます。 メッセージ自体の標準には、録音中にメッセージが途切れたかどうかを示す特別なフィールドがあります。 したがって、この瞬間を追跡する機会もあります。

質問: 壊れた JSON を書きますか?

答え: パケットが大きすぎるため、壊れた JSON は中継中に破棄されます。 または、Graylog は JSON を解析できないため破棄されます。 ただし、修正する必要があるニュアンスがあり、それらはほとんどが rsyslog に関連しています。 すでにいくつかの問題を記入しましたが、まだ取り組む必要があります。

質問：なぜカフカ？ RabbitMQ を試してみましたか? Graylog はそのような負荷の下では失敗しますか?

答え: Graylog ではうまくいきません。 そして、Graylog は私たちのために形になりつつあります。 彼は本当に問題があるよ。 彼は変わった人だ。 そして実際、それは必要ありません。 rsyslog から elasticsearch に直接書き込んでから、Kibana を確認したいと考えています。 しかし、警備員との問題を解決する必要があります。 これは、Graylog を捨てて Kibana を使用する場合の開発で可能なオプションです。 Logstash を使用する意味はありません。 rsyslogでも同じことができるからです。 そして、elasticsearchに書き込むためのモジュールがあります。 なんとかGraylogと共存していこうと思っています。 少し調整もしました。 しかし、まだ改善の余地があります。

カフカについて。 これが歴史的に起こった方法です。 私が到着したとき、それはすでにそこにあり、ログがすでに書き込まれていました。 単にクラスターを立ち上げて、そこにログを移動しただけです。 私たちは彼のマネージャーであり、彼の気持ちを知っています。 RabbitMQ に関しては... RabbitMQ ではうまくいきません。 そして、RabbitMQ が形になりつつあります。 本番環境にありますが、問題がありました。 さて、販売前に彼らは彼を魅了し、彼は通常通りに働き始めました。 しかし、それまでは本番環境にリリースする準備ができていませんでした。 もう 0.9 点あります。 Graylog はバージョン AMQP 1.0 を読み取ることができ、rsyslog はバージョン AMQP XNUMX を書き込むことができます。 そして、その両方を実現できる単一のソリューションは存在しません。 どちらか一方です。 したがって、現時点ではカフカのみです。 しかし、それは独自のニュアンスもあります。 なぜなら、私たちが使用しているバージョンの rsyslog の omkafka は、rsyslog からかき出したメッセージ バッファ全体を失う可能性があるからです。 今のところは我慢です。

質問: Kafka は既に持っていたので使用していますか? もう何の目的にも使用されていませんか？

答え: Kafka は、データ サイエンス チームによって使用されています。 これは完全に別のプロジェクトであり、残念ながらそれについては何も言えません。 私は知らない。 データ サイエンス チームによって運営されました。 ログが作成されたとき、独自のログをインストールしないように、それを使用することにしました。 現在、Graylog を更新しましたが、古いバージョンの Kafka が含まれているため、互換性が失われています。 私たちは自分たちで始めなければなりませんでした。 同時に、各 API のこれら XNUMX つのトピックを削除しました。 すべてのライブに対して XNUMX つの広いトピックを作成し、すべてのステージングに対して XNUMX つの広いトピックを作成し、すべてをそこに配置しました。 Graylog はこれらすべてを並行してかき出します。

質問: なぜソケットを使ったこのシャーマニズムが必要なのでしょうか? コンテナ用の syslog ログ ドライバーを使用してみましたか?

答え: この質問をした時点では、港湾労働者との関係は緊張していました。 docker 1.0 または 0.9 でした。 Docker自体が奇妙でした。 第二に、ログもプッシュすると...私は、すべてのログがそれ自体、つまり docker デーモンを介して渡されるのではないかという未検証の疑いを持っています。 XNUMX つの API がおかしくなると、残りの API は stdout と stderr を送信できなくなります。 これがどこにつながるのかわかりません。 ここでDocker syslogドライバを使う必要はないのではないかと感じるレベルで疑問を感じます。 当社の機能テスト部門には、ログを含む独自の Graylog クラスターがあります。 彼らは Docker ログドライバーを使用しており、すべて問題ないようです。 しかし、彼らはすぐに GELF を Graylog に書き込みます。 私たちがこれらすべてを開始した時点では、それが機能することだけが必要でした。 おそらく後で誰かが来て、それがXNUMX年間うまく機能していると言ったとき、私たちは試してみます。

質問: データセンター間の配信は rsyslog を使用して行います。 なぜカフカではないのでしょうか？

答え：実際には両方やってます。 理由は XNUMX つあります。 チャネルが完全に停止している場合、すべてのログは、圧縮形式であってもそのチャネルをクロールできません。 そして、Kafka を使用すると、プロセス中にそれらを単に失うことができます。 これが、これらのログの詰まりを取り除く方法です。 この場合、Kafka を直接使用しているだけです。 適切なチャネルがあり、それを解放したい場合は、その rsyslog を使用します。 しかし実際には、適合しなかったものをそれ自体がドロップするように構成できます。 現時点では、どこかで rsyslog 配信を直接使用し、どこかで Kafka を使用するだけです。

出所： habr.com