OSSへのログの転送

最終更新日: Dec 12, 2017

LogShipperはバケットなどの用途を活性化するために、自動的にOSSにログストアでログをアーカイブすることができます:

  • OSSでは、必要に応じて、格納されているデータのライフサイクルを設定できます。その後、ログを保存するための長期的な設定ができます。
  • OSSデータは、ユーザー定義プログラムや他のシステム(E-MapReduceなど)で使用できます。

利点

OSSにログを転送するLogShipperを使用したバケットなどの利点を、提供しています。

  • 使いやすさ。ログサービスを使用して簡単な設定後、ログストアのデータをOSSに同期させることができます。

  • 反復コレクションの回避。ログ収集には、ログを集中管理するプロセスが含まれます。つまり、OSSにインポートする前にログを収集する必要はありません。

  • ロググループのフル再利用。LogShipper自動的に別のプロジェクトとログストアで転送ログ異なるOSSへのバケットディレクトリ、データ管理を容易にします。

シナリオ

Alibaba Cloudユーザーの2つの主要なアカウントがあるとします。AとBです。

  • プライマリアカウントAを使用すると、プロジェクトAは、深センで有効化されるリージョンログサービスの、そしてログストアはnginxのアクセスログを格納するために作成されます。
  • プライマリアカウントBで、 OSSのbucket-bを深センリージョンで作成します。

注意:

  • AとBは同じアカウントです。この場合、RAM許可が推奨されます。
  • ログサービスプロジェクトとOSS バケット同じである必要がありますリージョン 。クロスリージョンのデータ転送はサポートされていません。

ログサービスのproject-aのnginxアクセスログは、bucket-bのprefix-bディレクトリにアーカイブされます。

ログサービスを使用してOSSシッピング機能を実装するには、2つのステップ(RAM許可およびシッピングルール設定)を実行する必要があります。

手順

手順1:リソースアクセス管理(RAM)の承認

迅速な認証

プライマリアカウントBを使用して[Alibaba Cloudコンソール]にログオンし、[リソースアクセス管理(RAM)]を有効化します。

RAMクイック認証ページで、すべてのOSSバケットを書き込む許可を与えることを確認します。ログサービスは、Aの代わりにBのOSS バケット書き込みます。

ロールを表示および変更

プライマリアカウントBを使用して[Alibaba Cloudコンソール]にログオンします。[ロール管理]にアクセスしてロールを表示します(承認を迅速に行うために、作成されたロールはデフォルトでAliyunLogDefaultRoleです)。

AとBが異なるアカウントの場合は、[ロール変更]に移動します。AとBが同じアカウントである場合、作成されたクイック認証のロールを直接使用することができます。

OSS shippingルールの作成のためにプライマリアカウントAに提供する必要があるため、ロールArnを記録します(たとえば、acs:ram::1323431815622349:role/aliyunlogdefaultrole)。

デフォルトでは、クイック認証によりBはすべてのOSSバケットの書き込みを許可されます。拡張アクセス制御リストについては、下記の [ポリシーの変更] を参照してください。

サブアカウントを使用してshippingルールを登録する権限

Bのロール作成および承認プロセスが完了した後、プライマリアカウントAは、プライマリアカウントBによって作成されたロールを使用してOSS バケットデータを書き込む権利を持ちます。これは、プライマリアカウントAがshippingルールを作成することを条件としています。

プライマリアカウントAのサブアカウントa_1を使用してshipping ルールをロールとして作成するには、 PassRole Authorization にアクセスしてください。

手順2:OSS shippingルールを設定

  1. [ログサービスコンソール]にログインします。

  2. プロジェクトを選択し、プロジェクト名をクリックします。

  3. ログストアを選択します。[ログシッパー]列の下にある [OSS] をクリックします。

  4. [有効化]をクリックし、次のOSS shpping設定を設定して、[確認]をクリックします。

    • OSS シッピング名: 作成されたshippingの名前。OSS shipping名の長さは3〜63文字で、小文字、数字、ハイフン( - )、アンダースコア(_)を含めることができます。始まりと終わりは、小文字の文字または数字にする必要があります。
    • OSS Bucket: OSS バケット名。OSS バケットとログサービスプロジェクトが同じリージョンにあることを確認します 。
    • OSS Prefix: ログサービスからOSSに同期されたデータがこのバケットディレクトリに格納されます。
    • パーティション形式: シャード文字列を生成するための出荷タスクの作成時刻をフォーマットするには、%Y, %m, %d, %H, %Mを使用します(フォーマットについての詳細は、strptime APIを参照ください)。これにより、OSSオブジェクトファイルのディレクトリ階層を定義できます。ここで、バックスラッシュ(/)はOSSレベルを示します。次の表は、OSSプレフィックスとシャードフォーマットのOSSターゲットファイルパスを定義する方法の例を示しています。
    • RAMロール: ACLに使用され、OSS バケット所有者によって作成された役割の識別子です。たとえば、 acs:ram::1323431815622349:role/aliyunlogdefaultroleのようになります。
    • シッピングサイズ: 1つのOSSオブジェクト(圧縮されていない)の最大サイズが設定されたshippingタスクの作成間隔の自動制御。単位は MBです。
    • 圧縮: OSSデータストレージの圧縮。なしもしくはsnappyが可能です。Noneは元のデータが圧縮されていないことを示し、snappyはデータがsnappyアルゴリズムで圧縮されていることを示します。snappyは、OSS バケットストレージに使用されるスペースを減らすことができます。
    • ストレージ形式: 3つの形式(JSON、Parquet、CSV)をサポートします。設定手順の詳細:JSONParquet
    • シッピング時間: shippingタスクが生成されるまでの間隔。デフォルト値は300で、単位は秒です。

    1

注意: ログサービスは、バックエンドでのデータ配信を同時に実装します。大量のデータは、複数のshippingスレッドによって処理される可能性があります。各shippingスレッドは、サイズと時間に基づいてタスク生成の頻度を併せて決定します。いずれかの条件が満たされると、shipping用スレッドによってタスクが作成されます。

パーティションフォーマット

各shippingタスクはOSSのパス形式oss:// OSS-BUCKET/OSS-PREFIX/PARTITION-FROMAT_RANDOM-ID(.snappy)で、OSSファイルに書き込まれます。2017/01/20 19:50:43で作成されたshippingタスクは、シャード形式の使用を説明するための例として取り上げられています。

OSS バケット OSS プレフィックス シャードフォーマット OSS ファイルパス
test-bucket test-table %Y/%m/%d/%H/%M oss://test-bucket/test-table/2017/01/20/19/50/43_1484913043351525351_2850008
test-bucket log_ship_oss_example %Y/%m/%d/log_%H%M%s oss://test-bucket/log_ship_oss_example/2017/01/20/log_195043_1484913043351525351_2850008
test-bucket log_ship_oss_example %Y%m%d/%H oss://test-bucket/log_ship_oss_example/20170120/19_1484913043351525351_2850008
test-bucket log_ship_oss_example %Y%m%d/ oss://test-bucket/log_ship_oss_example/20170120/_1484913043351525351_2850008
test-bucket log_ship_oss_example %Y%m%d%H oss://test-bucket/log_ship_oss_example/2017012019_1484913043351525351_2850008

HiveまたはMaxComputeでOSSデータを分析する場合、パーティションデータを使用する場合は、すべてのリストをkey=value形式(Hive形式のパーティション)に設定できます。

例えば:oss://test-bucket/log_ship_oss_example/year=2017/mon=01/day=20/log_195043_1484913043351525351_2850008.parquet

トリプルパーティションの列に設定することができます:年、月、日。

ログshippingタスク管理

OSS shipping機能を有効にすると、ログサービスはバックグラウンドで定期的にshippingタスクを開始します。 コンソールでshippingタスクのステータスを表示できます。

Log Shippingタスク管理 を使用すると、以下を行うことができます。

  • 過去2日間のLogShipperタスクをステータスと共に表示します。shippingタスクのステータスは、[成功]、[実行中]、[失敗]のいずれかです。失敗は、出荷時に外部の理由でエラーが発生したため、再試行できないことを示します。この場合、手動で問題のトラブルシューティングを行う必要があります。

  • 失敗したshppingタスク(最近2日以内に作成されたもの)については、タスクリストの障害の外部原因を表示することができます。原因のトラブルシューティングが正常に完了したら、失敗したタスクを個別に、またはバッチで再試行できます。

手順

  1. [ログサービスコンソール]にログインします。

    プロジェクトを選択し、プロジェクト名をクリックします。

  2. ログストアを選択します。[ログシッパー]列の下にある [OSS] をクリックします。

    shippingタスクのステータスを表示することができます。

    2

shippingタスクの実装が失敗すると、対応するエラーがコンソールに表示されます。このポリシーに基づいて、システムのデフォルトでは再試行が実行されます。手動で操作を再試行することもできます。

タスクの再試行

通常、ログデータはログストアに書き込まれてから30分後にOSSで同期されます。

デフォルトでは、ログサービスはバックオフポリシーに基づいて最新の2日間のタスクを再試行します。再試行の最小間隔は15分です。1回失敗したタスクは15分後に再試行でき、2回失敗したタスクは30分(2 x 15分)で再試行でき、3回失敗したタスクは60分(2 x 30分)後に再試行できます。

失敗したタスクをすぐに再試行するには、コンソールで[再実行]をクリックするか、タスクを指定してAPI/SDKで再試行してください。

失敗したタスクエラー

失敗したタスクに関するエラー情報は次のとおりです。

エラー情報 トラブルシューティング方法
UnAuthorized 無許可。チェック:
- OSSユーザーがロールを作成したかどうか。
- ロール説明のアカウントIDが正しいかどうか。
- ロールにOSS バケット書込み許可が与えられているかどうか。
- role-arnが正しく構成されているかどうか。
ConfigNotExist 構成は存在しません。これは、通常、shippingルールの削除によって発生します。ルールが再作成された場合は、再試行して問題を解決してください。
InvalidOssBucket OSSバケットは存在しません。チェック:
-かどうかはOSS バケットと同じであるリージョンログサービスとしてプロジェクト。
- バケット名が正しく設定されているかどうか。
InternalServerError ログサービスの内部エラー。問題を解決するために再試行してください。

OSSデータストレージ

OSSデータは、コンソール、API / SDK、およびその他の方法でアクセスできます。

コンソールからOSSデータにアクセスするには、OSSサービスを開始し、バケット選択し、[オブジェクト管理]をクリックして、ログサービスから出荷されたデータを表示します。

OSSの詳細については、OSSドキュメントを参照してください。

オブジェクトのアドレス

  • アドレス形式

    oss://OSS-BUCKET/OSS-PREFIX/PARTITION-FROMAT_RANDOM-ID

  • フィールドの説明

    • OSS-BUCKETOSS-PREFIX OSS示すバケットはそれぞれ名前とディレクトリの接頭辞を、ユーザによって設定されます。INCREMENTIDは、システムによって追加された乱数です。
    • PARTITION-FORMAT は、%Y/%m/%d/%H/%Mとして定義されます。 年、月、日、時、分をそれぞれ示します。それらはstrptime APIを介してshippingタスクサーバによって計算されます。
    • RANDOM-IDはshippingタスクの一意のIDです。
  • ディレクトリ時間

    次のように仮定します。

    • データは5分ごとにOSSに転送されます。
    • shippingタスクは2016-06-23 00:00:00に作成されます。
    • 転送されるデータは、2016-06-22 23:55のログサービスに書き込まれたデータです。

    2016年6月22日の完全な日の完全なログを分析するには、2016/06/22ディレクトリ内のすべてのオブジェクトに加えて、 2016/06/23/00/の最初の10分間のオブジェクトディレクトリには、日付が2016-06-22のログが含まれています。

オブジェクトの格納形式