Alibaba CloudのLog Serviceを使ってアプリケーションログのバックアップをしてみる

14612 ワード
log AlibabaCloud LogService log テキストリンク

今回はAlibaba CloudのLogServiceを使ったアプリケーションログの収集、バックアップを試してみたいと思います。

Alibaba Cloud Log Serviceって？

以下は公式ページからの引用です。

Log Service (略して「Log」) では、Alibaba Cloud プロダクトおよびサービスの各種ログの収集から集計まで
一元的に管理することが可能です。大量のログの処理に高い能力を発揮するため、O&M や運用の効率化に最適です。

とのことです。それでは試していきましょう。

事前準備

今回はアプリケーションログの収集をメインとしたいので、以下のものを事前に準備しました。

  • アプリケーションを稼働させるECSのインスタンス
  • ログを出力するアプリケーション
  • ログを転送するObject Storage Service（OSS）のバケットと、転送するための権限を付与されたロール

ECSインスタンス

ECSのインスタンスについては以下の構成で作成しています。

  • リージョン:　 Asia Pacific NE 1 (Japan)
  • インスタンスの仕様: ecs.xn4.small
  • インスタンスタイプファミリー: コンパクトタイプ
  • CPU:　 1コア
  • メモリ:　 1 GB
  • OS:　 Ubuntu 16.04 64bit

また、SSHログイン後に以下のものもインストールしています。

  • go 1.10.2
  • git
  • nginx
  • Logtail(ECSからログファイルをLog Serviceに送るためのアプリケーション)

Logtailのインストールについては、ドキュメントを参考にしました

アプリケーション

次に、ログを出力するためのアプリケーションですが、私が以前HTTPリクエストをログ出力するために作成した以下のアプリケーションがありますのでインストールし、nginxのupstream経由で動作するよう構築しました。

github.com/deadcheat/pedigree

このアプリケーションはHTTPリクエスト内容をJSONに整形した上で標準出力に出力するので、起動時に標準出力を/var/log/applog/app_stdout.logにリダイレクトするように指定して起動しました。

OSSへの転送準備

今回出力するログは、Object Storage Service（OSS）に転送してみたいので、転送先として指定可能なOSSのバケットを、以下のように作成しました。

  • バケット名： deadcheat-logshipper-bucket
  • リージョン： Asia Pacific NE 1 (Tokyo)

また、ログをOSSに転送する設定を行う際に、ロールのArnが必要になります。まだロールを作成していない場合は、RAMのコンソールからロールを作成し権限を付与するか、ドキュメントから、AliyunLogDefaultRoleロールを作成するクイック認証ページへのリンクをクリックすることで作成可能です。

Log Serviceを使用する

Alibaba Cloud ConsoleからLogServiceを選択しましょう。Application Servicesの項にあります。

Log Serviceの有効化

まだLog Serviceを使ったことがない場合、例によって有効化を促す画面が表示されますので、有効化します。

有効化し、再度LogServiceを起動すると無事LogServiceの管理コンソールが表示されます。

プロジェクトの作成

管理コンソール上でプロジェクトの作成を選択すると、

  • プロジェクト名
  • 説明
  • リージョン

を選択するダイアログが表示されます。

今回は、

  • プロジェクト名： deadcheat-logservice-test
  • 説明：　なし
  • リージョン： Asia Pacific NE 1(Tokyo)

のように入力しました。
入力後確認をクリックするとダイアログが閉じ、リクエスト中とのメッセージが表示されたあと、すぐに以下のようにプロジェクトを作成しましたが、ログを保存するにはLogStoreを作成する必要があります。とのダイアログが表示されます。

作成しないと保存できないとのことで作成をクリックします。

LogStoreの作成というダイアログが表示されました。

  • LogStore 名
  • LogStore属性
    • WebTracking
    • データ保持期間
    • シャード数
    • 請求料金

以下の内容で入力して確認をクリックします。

  • LogStore 名: deadcheat-logstore-test
  • LogStore属性
    • WebTracking: OFF
    • データ保持期間: デフォルト(30)
    • シャード数: 1
    • 請求料金: そのまま

今度はLogStoreを作成し、データインポートウィザードを使用してログの収集や分析などの手順について学べますとのメッセージです。

せっかくなのでメッセージに従ってデータインポートウィザードを使用してみましょう。
先程のメッセージ・ダイアログのデータ・インポート・ウィザードというボタンをクリックすると以下のような画面が表示されます。

上から

  • クラウドサービス
  • サードパーティー製のソフトウェア
  • 他のソース

とカテゴライズされていますね。
今回のアプリケーションはログファイルに出力しているので、他のソースからテキストを選択し、次へをクリックします。データソースの設定という項目に移り、以下のような画面が表示されます。

この画面では、

  • 構成名
  • ログパス
  • モード
  • システム時刻使用
  • 高度なオプション

といった項目を入力する必要があります。

  • 構成名： deadcheat-logstore-ds-test
  • ログパス： /var/log/applog/app_stdout.logにログを出力しているので/var/log/**/app_stdout.logとなるように設定
  • モード： JSONモード
  • 高度なオプション： デフォルトのまま

という内容で入力し、次へをクリック。

マシングループに適用という項目に進みますが、まだ作成していないのでマシングループの作成を選択します。

マシングループの作成ダイアログが表示されます。

  • グループ名
  • マシングループの識別子
  • マシングループのトピック
  • IP

を入力するようなので、

  • グループ名： deadcheat-machinegroup-test
  • マシングループの識別子: IP
  • マシングループのトピック: なし
  • IP: 作成したECSインスタンスに付与されたプライベートIPアドレス

の様に入力し、確認をクリックします。

新しいマシングループが作成されたらチェックボックスにチェックを入れ、マシングループに適用をクリックします。
すると、検索、分析、可視化という項目に進みます。

このとき、まだ有効化されておりません。というダイアログが出てきて「えっ」となりますが、特に気にしなくて大丈夫そうでした。

この項目の設定は後回しにしたいので、一旦そのまま進みましょう。次へをクリックします。

最後に、ShipperとETLという項目になりますが、まずはログが収集されることを確認したいので、この項目も設定は省略します。データインポートウィザードを終了するため確認をクリックします。

これでプロジェクトが作成されました、プロジェクトのトップが表示されていると思います。

さて、ログが正常に抽出されているかの確認を行うために、セットアップしたアプリケーション上でログを出力させるために何度かHTTPリクエストを送っておきます。

では確認してみましょう。

プロジェクトのトップ画面に表示されているLogStoreの行から、ログ表示モードにあるLogHubの表示をクリックします。

ログが収集され、表示されているのがわかりました。

ログをOSSに転送しよう

ログが収集できているのを確認したところで、次はこのログをObject Storage Service（OSS）に転送してみましょう。

プロジェクトのトップ、ログ表示モードにLogShipperの項目があり、この下にOSSのリンクがあるのでこれをクリックします。トップでなくても、サブメニューの下の方にLogShipperというメニューがあり、OSSのリンクはこちらからもクリックすることができます。

OSS Shipperの画面が表示されます。プロジェクトのトップ画面から表示した場合はLogStore名がデフォルトで表示されていると思いますが、表示されていない場合はLogStoreを選択してくださいと表示されている箇所をクリックすることで選択することが可能です。

LogStoreが選択されている状態で、その横に有効化というボタンが表示されていると思いますのでこれをクリックします。

OSS LogShipperという画面が表示されました。

  • OSS shipping 名
  • OSS Bucket
  • OSS Prefix
  • ディレクトリ形式
  • RAMロール
  • 転送サイズ
  • 圧縮
  • 保存形式
  • 転送間隔

を入力する必要があります。ここでは、以下を設定しました。

  • OSS shipping 名: deadcheat-logshipper-test
  • OSS Bucket: deadcheat-logshipper-bucket （事前に準備していたバケットの名前）
  • RAMロール：事前準備で用意したロールのArn
  • 圧縮: 圧縮しない

これ以外の項目はデフォルトのままにして設定しています。圧縮をデフォルトのSnappyから圧縮しないに変更したのは、保存後に内容を確認するのが少し手間な気がしたためです。通常の保存用途であれば圧縮して構わないと思います。

確認をクリックするとダイアログが閉じますが、すぐには何も表示いないかもしれません。少しだけ待ってリロードすると以下のように転送の履歴が表示されると思います。

ステータスが成功となっているのでおそらく成功したものと考えられますね、OSSのコンソールに移動して確認してみます。
仮にステータスが失敗となる場合、エラーメッセージがステータスの横に表示されるようです。RAMロールなどに不適切なロール（ログのロールでないなど）が設定された場合に失敗となり、その旨がエラーとして表示されます。

無事ファイルがデフォルトの年/月/日/時で作成されたディレクトリにアップロードされていました。
ダウンロードしてみるには、ファイル名をクリックするとURLが発行されているのでそれを元に取得してください。

ログを解析してみよう

ログを取得して、OSSに転送することもできました。
最後に、少しだけログの解析もやってみましょう。

プロジェクトのトップ、ログ表示モードに解析検索という項目と、検索のリンクがあるのでこれをクリックします。

これまでアプリケーションがファイルに出力し、またLogServiceが収集してくれたログがそのまま表示されています。

LogServiceのセットアップの際に、データインポートウィザードの検索、分析、可視化項目で後回しにしたので、デフォルトで選択されていたフルテキストインデックスでログのインデックスが行われています。これはこれで、項目などを検索したり直接テキストボックスに検索クエリを記述する事ができるので、ログが単純な行データの場合はこのままで問題ないパターンが多いかもしれません。

今回はJSONがネストしているログを出力しているので、JSONの項目に対してインデックスしてみます。右上にインデックス属性というラベルがあるのでこれをクリックし、変更を選択します。

検索と分析という画面が表示されました。JSONフィールドに対し手動でインデックスをカスタマイズするには、まずフルテキストインデックスがOFFになっている必要があるので、これをOFFにします。

また、今回のログ中でHTTPリクエストの情報を詰めているのが、RequestDataという項目になるので、フィールド検索部分に行を追加し、
- キー： RequestData
- タイプ： JSON

のように入力し、ひとまずこのままOKをクリックします。

行データとして表示されていたログのRequestData部分が、JSONとして整形されて表示されるようになりました。これで少しだけ見やすくなりましたね。インデックスを自分で操作することで、よりログの分析などを深く行うことができるようになるはずです。

おわりに

いかがでしたでしょうか、今回はECSで動作させているアプリケーションのログをLogServiceで収集しOSSに転送する方法と、インデックス変更のやり方について学ぶことができました。

ログの収集・保全・解析は、クラウドサービス化であったり、マイクロサービスアーキテクチャやブルーグリーンデプロイメントなどの導入によってサーバーが複数台化しがちな昨今では非常に重要な事柄になってきています。今回学んだように、Log Serviceを使用すると非常にログの収集が楽になるのでみなさんも触ってみてください。

また、インデックスや解析画面でのクエリについては今回はほぼ触っていませんが、これを使いこなすことでログの解析などもLogServiceから実現することが出来る様になりますので興味のある方はご覧になってみてください。

今回もお読みいただきありがとうございました。