「：中国2019 DevOpsチームは、クラウド市場の評価ベンダーIDCMarketScapeを」報告書を10月30日には、世界の権威あるデータは、会社IDCがリリース研究します。豊かで実践力、そして高品質なサービスの提供とプラットフォームの安定性とJingdongは雲のシーンは、優れた結果を達成し、「主要なプレーヤー」（中核会社）の位置の間で。
JingdongはクラウドDevOpsチームの能力を作成し、耐える厳しいテストを繰り返し618,11.11が変化し、高品質の効率的な配信に対応するための柔軟性を確保するために、大規模で複雑なビジネスシナリオJingdongはグループのための電気の供給を促進し、彼らのビジネス慣行に由来します。さまざまなニーズに応じたヘルプ顧客に柔軟でカスタマイズされたソリューションを実装ツールチェーン製品のプラットフォーム製品と組み合わせた複雑なシーンの運用および保守要件の自動化をサポートします。
最初の二つのテーマ別の要素は、私たちはあなたと共有にした大規模なエンタープライズクラスの監視システムの設計とシステムの可観測とデータストレージを監視します。ログクエリサービス：今日、我々はDevOpsチームクラウド、DevOpsチームと我々はもう一つの重要な要素で共有し続けることにより、Jingdongは着陸の練習を紹介します。
ログの追跡は、ビルドのソフトウェアへのプロジェクトの礎石の一つであるシステムの安定動作の本質的な部分である、DevOpsチームの標準オプションとなっています。ここでは、Jingdongはユン李DevOpsチームのプラットフォームのチャットログのクエリサービスを練習します。
最初の顧客には、顧客サービス、ユーザーのニーズを解決するために、次の段階に分けユン李ログクエリサービスの開発への献身の原則は、ログインします。
シーンワン：あなたは現在正常に動作して独自のアプリケーションを決定するために、アプリケーションログをチェックする必要がある、または、彼らは問題が発生した際に、アプリケーションログ情報の出力を表示することによって、問題を特定する必要があります。
ユーザーのニーズのために、我々が開発し、提供しているオンサイトログクエリ機能を。
シーンログとは何ですか？その犯罪現場ログ。一般的なシーン、それはありますか？もちろん、ユーザアプリケーションのホストが展開されています。
私たちは、ホスト上のユーザのログを照会するアプリケーションのためのオンサイトログクエリ機能を提供します。この機能は、ログの下で、デフォルトのディレクトリ指定で有効になって、カスタムパスの拡張をサポートしています。
- 仕様のディレクトリ：/エクスポートは/ログ/ $のappName / $ instanceNameのは/、ユーザホストでのログファイルは、このディレクトリは自動的にページの列は、クエリにユーザーのクエリにファイルを選択します。$ AppNameは、ユーザーのアプリケーション名を表し; $ instanceNameのは、アプリケーションのデプロイメントのインスタンス名を表します。
- 例えばユーザー定義のパス、：/export/test.log、ため、システムの面で私たちのために、このパスのログ情報は、手動で入力したログ・パスに必要かどうかを確認した後、クエリ操作を実行するために、ユーザーのニーズ、「非標準」であります。
ログクエリ図のシーンファイル選択例。
サイト検索機能をログに記録する方法
一般的に、我々は、彼らが、ホストがそれを行う方法である上のログを表示する必要があると思いますか？最初のステップは、多くの場合、ホストへのSSHログインで、その後のgrepコマンドを使用して、クエリの内容を指定します。はい、私たちのライブログは、キーワードクエリを入力し、ユーザーはオンサイトのログページを照会するログファイルを選択し、このプロセスのプラットフォームであることをポイントクエリボタンです。セキュリティ上の理由から、SSH認証キー認証ではなく、私たちは、パスワード認証を使用します。もちろん、SSH接続を介しているので、それは22個のホストポートを開くようにユーザーに要求する必要があります。
SSHで遭遇したログのクエリフィールドの問題
たとえば、ホストがあるVPCで一部のユーザー、ダイレクトアクセスよりもSSH、どのようにそれを行うには？これプロキシ設定の束を維持するために徐々にリードする、プロキシを設定され、この問題を解決することができる方法、と考えてください。
改善
新しい制御システムのゼロの社内クラウドの翼の出現により（ゼロ制御システム、作られたホスト上で次のゼロエージェントに介してホスト上の操作の数のタスクがある）、サイトのログクエリは、新しい実装を持っていますあなたはそう使用する前に、制御システムログを達成するための方法の下で髪のタスクに、制御システムのAPIを呼び出すことができますsshのHTTP接続の代替、もはやキーに依存しない、とsshのプロキシ設定の束を維持するために、不要になりましたA。ああ、私は見てリフレッシュの多くを感じます。
新しいジレンマ
実装を変更した後、我々は、ユーザーが多くの単一のケースをログに記録し、クエリが失敗した原因のデータのクエリ量がゼロエージェントの制限を超える転送した場合、データの量は、トレードオフ、またはユーザーが必要であるという新たな問題を発見しましたログの長さ調整、又はストリップを示すデータの数を減らし、そしてそのような履歴ログを使用するなど異なるクエリ方法、のいずれかの動きはもちろん、これが唯一の好都合の尺度であり、クエリを導入することができ、履歴ログ機能はするものではありませんこの問題を解決するには作成されました。
シーン2：複数のマシン上のユーザー・アプリケーションの導入、ユーザーがマシン上で、いつログ検索を行う（例えば、帯域幅、メモリ、CPUなど）、独自のリソースを消費したくない、集中型検索のための複数のマシンにログインする必要があります。
このためには、ユン李の履歴ログのクエリがされて入ってきました。我々は最後の7日間で履歴ログのサポートは、検索ログを期待しています。
あなたの検索、速やかにログデータの収集、集中ストレージを取るために、我々最初の必要性を集中したいので。ここジャーナル購読操作を行うには、ユーザーのニーズ、実際には、あなたがキャプチャするアプリケーションの下でサービスをログに記録するログファイルデータを伝えることです。
ログデータは、グラフフロー：
図は、ログデータをユーザに流れて、ユーザーのサブスクリプションを反映しています。データ記憶媒体は、2つが含まれていることが分かる、1は1つがES、前カフカに、最終的にはESへのデータ・キャッシュで、カフカです。ElasticSearchがESと呼ばれ、それが検索エンジンに分散オープンソースであり、私たちの歴史のログクエリ機能を実現するES強力な検索機能の手段です。
ログ・エージェント、FWDとインデクサモジュールを導入するために、上記の次の図。
- エージェント・ログ、ユーザーのホストアプリケーション上で展開され、ログ収集クライアント雲の翼、。これは、動的にユーザの加入情報、リアルタイムのログデータの収集とデータがFWDモジュールに報告を発見することができます。内部ログ剤封入rsyslogの、ユーザのログ取得は、構成および起動と停止手順のrsyslogのを制御することによって達成されます。Linux上rsyslogのは、より成熟したシステムログ収集ツールである、我々は可能性も、当然のことながら、収集アプリケーションレベルのログに使用しました。
- FWDは、このモジュールは、ログ・エージェントを報告し、カフカに転送データを受信するための責任があります。ログエージェントをデカップリングし、カフカ、ホストの数万人とカフカ直接接続を回避する上で、その値の嘘、カフカが変更されることがあり、我々は唯一の必要性をない、いくつかの変更やアップグレードを行うには限られたFWDを与えますログ・エージェントのすべてを統一するためにアップグレードしてください。
- インデクサは、モジュールは、ESを移動カフカからのログデータを担当し、ポーターデータとして見ることができます。自然インデクサは、その入力がカフカで、rsyslogのある出力ESです。rsyslogのは非常に強力見つかりませんか？このモジュールはシンプルですが、非常に重要です。何特に問題となっていることは、それは多くの場合、どちらか打つメモリを食べるか、仮死の仕事をしないということです。それは仕事、ESおよびその他のデータ及びませんが、どうしようもなくする必要はありません、ESノーデータ、内容を確認するには、no履歴ログは、問題があまりにも深刻です。繰り返し調査・分析した後、最終的に起因する遅いチームにメッセージキューの作用によるものであることが判明し、キューの設定rsyslogのを繰り返し素直に仕事、そして楽しいの後に、男は最終的に喜んでいくつかの調整を行いました。時々使用することは困難ではない、容易に入手可能なツールが、我々は使用しません。
ESインデックスはじめに
インデックス・ログ2019年10月21日：インデックスから切っても切れないESストレージは、インデックスは、その日の例のインデックスを作成するために粒度の私たちの最初の日に従ったものです。しかし、ログの量が増加すると、その日によってインデックスは、毎回クエリは、検索が大きすぎると、特にスロークエリにつながる、ユーザーエクスペリエンスは非常に悪いです。クエリのパフォーマンスを向上させるために、その後、例えば、時間の粒度にインデックスを置く：インデックスログ-2019-10-21-13を。
時間指標を確認する方法
それは時間インデックスであるため、ESインデックスレポートを読んで、何人かの人々はそれを取るためにどのように具体的には、この時間は疑問を持っていること？それのユーザからのログメッセージの解析？そうではありません。フォーマットが変化するユーザーのログ時間は、ユーザログからの解析時間は明らかに非現実的です。
それは、インデックスを決定するために、現在の輸送時間に応じてますか？この場合、データ処理がタイムリーでない場合には、カフカメッセージバックログは、15：00のデータとしてユーザがログインするとおそらくダイに対するインデックス時間一貫性のない、時間が16:00ので、インデックスに配置することができます検索データに時間の15ポイントが少ないと予想データよりも発見されました。
ここでは、データのそれぞれを説明するために、我々はログエージェントの取得は、ログの内容に加えて、そのようなタイムスタンプが記録されている部署名、アプリケーション名、ログファイルのパス、タイムスタンプ、など、いくつかのメタ情報となりますログ収集は、などのリアルタイムキャプチャ、時間およびアプリケーションでユーザーがログインがほぼ同等とみなすことができる。この時点での時間。インデックスデータの前に、タイムスタンプは、特定のインデックスのタイムスタンプによって決定される解析します。したがっても存在カフカメッセージのバックログがあるだけでなく、正しいデータを確保する場合にはインデックスが所望のログに格納することができます。
図の履歴ログクエリの例。
履歴ログが直面する問題
ログの量が増加すると、ESのストレージリソースが不十分な状況であることを恥ずかしい問題があります。これは、ユーザーの皆様と一緒に問題を解決するための努力が必要です。
シーン3：一部のユーザーが......ある日突然、必要なデータなど3ヶ月、6ヶ月として、彼らのアプリケーションログが、より重要なことを長期保存への希望を感じ、あなたはログサービスを表示するには、下のデータファイルをダウンロードすることができます。
このユーザーの需要に対処するために、私たちの練習は、日付によって、ユーザのログを保存し、その後、必要に応じて日付を指定されたクエリとダウンロードログファイルへのユーザーのためのフロントページ内のログのダウンロード機能を提供することです。ここでは、ログのダウンロードと呼ばれる私たち抽象化機能。
アイデアの実現には、ダウンロード機能のログを記録します
ダウンロードログおよびコア前提は長期保存のためにログファイルに散乱情報をマージすることです。
私たちはそこカフカに格納されたデータ、データソースを収集する前に、次のステップは、合併問題に保存したデータをプルダウンすることです。我々はHDFSを選んだの冒頭ではい、記憶媒体（行うには長期保存は明らかに非現実的であると、ESは武器を取得することで、ストレージのコストが高すぎます）。
この目的のために、我々は、我々は道をストリーミングスパークを使用するため、以下のリアルタイムを要求し、カフカからconsumerGroup消費データを果たし、スパークジョブプログラムを書いて、2分ごとに、データは、その後、オフラインで引っ張られたら計算。メッセージのメタデータは、タイムスタンプと、ログ収集・パスを含んでいるので、我々は簡単にHDFSファイルに追加されたログを決定することができます。最終ダウンロードhttpfsでHDFSからファイルをログに記録します。
HDFSストレージと同じように、ログの量の増加に伴って、リソース不足の問題が出て表示されます。最後に、我々はJingdongはクラウドオブジェクトストレージOSSを対象店舗。もちろん、HDFSに格納されている初期データは作業はまだ非常に便利です計算した後、次のタスクは、OSS、OSSにHDFS上のファイルをダウンロードしてからのようなユーザーにダウンロードリンクを生成することです。これは暫定HDFSの役割に相当し、文書が大幅HDFSの貯蔵圧力を緩和、念のデータがされているダンプOSSは、HDFSのファイルを削除することができ作る、あまりにも長い間維持する必要があります。
ログローテーション（HDFS-> OSS）の問題が発生し、解決策
ユーザログファイルが大きいとOSSにログ・ダンプを行うことで、我々は問題が発生した、など、ユーザーが自分のホスト上で実行切削ログインすることができるが、我々はAでカフカにデータを収集しているため我々は1つのHDFSファイルに-道路を直すことをログメッセージの後、同等の、メッセージのストリップをログに記録します。より頻繁に日のログファイルストレージに近い、といくつかのアプリケーションログの印刷は、このファイルの究極の合成は、それがHDFSからOSSにダウンロードしたり、圧縮してアップロードされたそうかどうか、いくつかのさらに100Gよりも、比較的大きくなります操作は、より多くの時間がかかることが、また、より多くのディスクスペースを占有します。ユーザーの場合は、大きなファイルの処理をダウンロードする事が面倒になります。
この問題を解決するために、我々は、単一のHDFSファイルサイズが1G未満であることを保証する、HDFSファイル切断を達成するために、処理ロジックスパークジョブを調整します。このような大きなファイルを複数の小さなファイルに分割されます。複数の小さなファイルは、同時ダンプので、全体の効率が大幅に強化されます。ユーザーは、はるかに高速ダウンロードするように、通常はこれ以上300メガバイト以上のファイルは、圧縮されません。
図ダウンロードの模範的なログ
OSSは、永続ストレージを行うと、欠点があるダンプに必要である、ログは一日のリアルタイムでダウンロードすることができないが、これは特に緊急の問題ではありませんが、一日のログログを照会したり、以前の履歴ログで導入できるというシーン理由ビューを取得するためのクエリ機能。
シーン4：特定のストレージニーズ - ユーザーが、私はあなたが集中ストレージにデータをログに記録したくない、私は自分自身を保存し、その後、分析をしたいと言う、あなたは私だけで罰金指定された場所を収集するのに役立ちます。
これは、ユーザーのニーズを満たすために、我々はログの宛先をカスタマイズする機能を開発している、確かに一般的なユーザーのニーズです。
名前が示すように、カスタムログの宛先は、それは、ユーザが行っている、ログの保存場所のサブスクリプション操作は、宛先名を指定すると、ユーザが指定するようにすることです。
FWDとカフカ：現在サポートされているログ記録先は2つのタイプがあります。
- FWD種類、ドメイン名とポート番号を宛先サービスと宛先サービスのサポートRELP契約を提供するために必要な、RELPは、TCPトランスポートプロトコルよりもはるかに信頼性があります。
- カフカのタイプは、あなたがカフカブローカーやトピックを指定する必要があります。
ビューのポイントを使用することから、ログ先の大多数の現在のカフカタイプ。
これまでのところ、導入上のいくつかの主要な機能ユン李ロギングサービスが終了しました。プロセス全体を見て、ログサービスは、橋の開発・運用・保守の間に良好な接続があり、ログは、オンライン、実際の動作条件を完全なアプリケーションを示す、ほぼすべての操作・保守・開発の懸念が含まれています。ユン李サイトのログ、履歴ログ、ログのダウンロード、これらの4つの機能のカスタムログの宛先は、異なるシナリオにおけるユーザーの要求を満たすために、お互いを補完します。
Jingdongはクラウドの監視は、[]をクリックし、無料のサービスを提供して読む Jingdongは、クラウドの監視についての詳細を学ぶために]。
ようこそ「をクリックしJingdongは雲をよりエキサイティングなコンテンツのために」
