こんにちは。CnS技術統括部のumeです。
今回はSumo LogicのAWS Observability Solutionの紹介です。
少し前にSumo Logic社の方でもセミナーを頻繁に実施されておりましたが、私が見た限りではApp Catalogの適用方法の紹介まではなかったので、この適用方法の紹介をしたいと思います。
Sumo LogicのAWS Observability Solutionとは
AWSの各種サービスをアカウント単位・リージョン単位で可視化できる機能です。
基本的には稼働監視とトラブルシューティングの迅速化を目的としています。
AWSとついている通り、AWS専用のSolutionです。
中身はAWSの各種サービスを統合監視するDashboardです。
Sumo Logicはライセンスの種別が多数ありますが、どのライセンスでも使用することができます。
他のApp Catalogとの違い
今までのApp Catalogは、1サービスに対してDashboardが提供されるのが基本でした。
統合監視を行う場合、複数のApp Catalogを組み合わせて自分でDashboardを作る必要がありました。
AWS Observabilityであれば、複数サービスを1度に可視化（統合監視）するDashboardが最初から用意されています。
ただし、他のApp Catalogと適用の方法が異なります。
適用の流れ
適用する際は、Sumo Logic側の操作ではなくAWS側で操作することになります。
CloudFormationテンプレートを使用してデプロイします。
今回は単一のAWSリージョンとアカウントの組み合わせに対してAWS Observability Solutionを適用する形です。
複数のリージョンとアカウントに適用する場合は手順が異なりますのでご注意ください。
- 必要な情報を準備する
- AWSマネジメントコンソールにログイン
- Sumo Logic側で指定するURLからCloudFormationテンプレートを呼び出す
- CloudFormationテンプレートに必要な情報を入力
- スタックを作成
このような流れです。
必要な情報を準備する
まずSumo LogicのアクセスIDとキーが必要になります。
CloudFormationテンプレートを実行する際に指定が必要です。
AWS側からSumo Logicに対してAPIを使用して設定を行います。
AWS管理コンソール上でCloudFormationテンプレートを実行するため
これについても必要な権限を持ったアカウントが必要です。
https://sumologic-appdev-aws-sam-apps.s3.amazonaws.com/AWSObservabilityCFTemplatePermissions.json
またログとメトリクスの両方を使用して可視化を行うため、メトリクスも使えるようにしておく必要があります。
（ライセンスの種別によっては追加が必要な可能性もあります。）
- AWSマネジメントコンソールにログイン
- Sumo Logic側で指定するURLからCloudFormationテンプレートを呼び出す
ここはセットですね。
CloudFormationテンプレートは以下のURLからアクセスします。
現状ですとバージョン2.2が最新ですが、今後変更される可能性もあります。
変更履歴は以下のURLで確認できます。
https://help.sumologic.com/Observability_Solution/AWS_Observability_Solution/01_Deploy_and_Use_AWS_Observability/16AWS_Observability_-_Change_Log
CloudFormationテンプレートに必要な情報を入力
ここからCloudFormationテンプレートに値を入れていきます。
スタックの名前
これはCloudFormationのスタックの名前ですね。
Sumo Logic側には特に影響ないので任意の名前をつけます。
1. Sumo Logic Access Configuration (Required)
Sumo Logic Deployment Name
どのリージョンかを指定します。日本ならJPです。
Sumo Logic Access ID
Sumo Logic Access Key
Sumo LogicにアクセスするためのアクセスIDとキーです。
ここで指定するため事前に作成が必要です。
Sumo Logic Organization Id
Sumo LogicのOrganization IDです。
Sumo LogicのWebUIにログイン後、Administration→Accountの画面で確認できます。
Delete Sumo Logic Resources when stack is deleted
スタックが削除されたときにSumoLogicのコレクター、ソース、アプリを削除するには、このパラメーターを「True」に設定します。
2. AWS Account Alias
データを収集するAWS環境の名前を入力します。
この名前は、Collectorに追加される他、Sumo Logic Explorerのビュー、メトリック、およびログに表示されます。
3. Sumo Logic AWS Observability Apps and Alerts
「Yes」にするとSumo LogicのApp CatalogとAlertが設定されます。
4. Sumo Logic AWS CloudWatch Metrics Sources
Select the kind of CloudWatch Metrics Source to create
CloudWatch Metricsを使用するかどうか、とデータ取得の方法を設定します。
データ取得方法の推奨はKinesis Firehoseの使用です。
コストとパフォーマンスの利点がある、とSumo Logic社のサイトに記載がありますが恐らくAWS側にかかるコストだと思います。
Sumo Logic AWS Metrics Namespaces
AWSCloudWatchメトリクスとインベントリソースの両方に使用されるネームスペースのコンマ区切りリストを入力します。
ここはデフォルトで問題ないかと思います。
Exisiting Sumo Logic Metrics Source API URL
既存でCloudWatch Meticsを収集していて、それを使用する場合はURLを指定します。
5. Sumo Logic AWS ALB Log Source
Enable ALB Access logging
New-新しいALBが作成されると、AmazonS3を介したログの収集を自動的に有効にします。（既存は対象外）
Exsting-既存のALBに対してのみ、AmazonS3を介したログの収集を有効にします。
Both-新規および既存のALBのログの収集を有効にします。
Create Sumo Logic ALB Logs Source
「Yes」を選択すると既存のバケットまたは新しいバケットからALBログを収集するSumo Logic ALB Log Sourceを作成します。
Exisiting Sumo Logic ALB Logs Source API URL
既存でALBログを収集していて、それを使用する場合はURLを指定します。
Amazon S3 Bucket Name
上記のALBログソースの作成で「No」を選択した場合は、この手順をスキップしてください。
ALBログを保存する既存のS3バケット名を指定します。これが空の場合、新しいバケットがリージョンに作成されます。
Path Expression for existing ALB logs
既存のバケットでALBアクセスログを受信するように構成されている場合に必要です。
これが空白の場合、SumoLogicは以下のパスにログを保存します。
「*AWSLogs/*/elasticloadbalancing/*」
6. Sumo Logic AWS CloudTrail Source
Create Sumo Logic CloudTrail Logs Source
「Yes」を選択すると、既存または新しいバケットからCloudTrailログを収集するためにSumo Logic CloudTrailログソースを作成します。
Existing Sumo Logic CloudTrail Logs Source API URL
すでにCloudTrailログを収集している場合は必須です。
既存のSumoLogic CloudTrail Source APIのURLを指定します。
Amazon S3 Bucket Name
上記のCloudTrailログソースの作成で「No」を選択した場合は、この手順をスキップしてください。
CloudTrailログを保存する既存のS3バケット名を指定します。これが空の場合、新しいバケットがリージョンに作成されます。
Path Expression for existing CloudTrail logs
既存のバケットでCloudTrailログを受信するように構成されている場合に必要です。
これが空白の場合、SumoLogicは以下のパスにログを保存します。
「AWSLogs/*/CloudTrail/*」
7. Sumo Logic AWS Lambda CloudWatch Logs Source
Select the Sumo Logic CloudWatch Logs Sources
CloudWatch Logsを取得するためにLogForwarder-LambdaとKinesis Firehoseのどちらを使うか選択します。
Existing Sumo Logic Lambda CloudWatch Logs Source API URL
AWS Lambda CloudWatchログをすでに収集している場合は既存のSumoLogic AWS Lambda CloudWatchソースAPIのURLを指定します。
Subscribe log groups to Sumo Logic CloudWatch Logs Forwarder
New-新しいロググループを対象に収集、ログ送信します。
Exsting-既存のロググループを対象に収集、ログ送信します。
Both-新規および既存のログの収集を有効にします。
Regex for AWS Lambda Log Groups
ロググループ名を照合するための正規表現を入力します。
8. Sumo Logic Root Cause Explorer Sources
Select the Sumo Logic Root Cause Explorer Sources
Root Cause Explorerを使用する場合はデータソースを作成します。
※今回は割愛しますがRoot Cause Explorerを使用できるかどうかはライセンス種別によります。
スタックの作成
上記の入力が完了したらスタックを作成します。
環境によると思いますが、試したときは10分位で完了しました。
確認
まずCloudFormationテンプレートがCREATE_COMPLETEステータスで正常に実行されたことを確認します。
次にSumo Logic側でApp Catalogがインストールされていることを確認します。
アクセスIDを指定したユーザのPersonalフォルダにインストールされています。
以下のサービスのDashboardが用意されています。
- ECS
- ElastiCache
- RDS
- API Gateway
- ALB
- DynamoDB
- EC2 Metric
- Lambda
- NLB
- CloudTrail
- Account/Region Overview
以下のCloudFormationテンプレートで、AWSとSumo Logicの権限が足りているか確認することもできます。
https://console.aws.amazon.com/cloudformation/home#/stacks/quickcreate?templateURL=https://sumologic-appdev-aws-sam-apps.s3.amazonaws.com/permissioncheck.template.yaml
今回適用した環境では使っていないAWSサービスの方が多かったので、あまり面白いデータにはなりませんでしたが、上記のAWSサービスを使用している環境であれば簡単にDashboardが展開でき、Alertも設定されるので非常に便利なのではないかと思います。
Sumo Logicを使用しているユーザ様で上記のようなAWSサービスを利用されている方はもちろん、これを目的にSumo Logicを試してみるというのも良いかと思います。
