この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
おはようございます､加藤です｡JAWS Days 2019にてランチセッションでSumo Logicについて登壇致しました｡
内容
Sumo Logicはログを収集・分析・可視化するSaaSです｡
ログ分析の問題点には例えば以下のような物があります｡
- サービス・アプライアンス毎に出力されるログフォーマットが異なる
- 正規化を行わないとログを格納できない・分析が行えない
- ログが肥大化してディスク容量が枯渇
- サービスの拡大を予測して必要なディスク容量を算出するのは非常に難しい
- 時間あたりのログ量が増えるに連れて分析に必要なスペック(CPU・MEM)が増える
- 同じ時間範囲でも徐々に分析にかかる時間が増えていく
- 分析環境に入ってくるログが正規化されていない
- 正規化が漏れてしまっている物がありログ格納時・分析時にエラーが発生して止まってしまう
- 不正と判断してログ受け取りを拒否してしまう
Sumo Logicはこれらに対して解決策となります｡
Sumo Logicは特に受け付けるログフォーマットに制限がありません｡複数のサービス・アプライアンス間で横断して分析する必要がなければ正規化は不要です｡ Sumo Logicに永続的にログを保存する事はできませんが､代わりに過去のログを簡単に取り込む事が可能です｡永続ストレージとしてはS3を使用し､Sumo Logicには常に分析したい範囲､たとえば3ヶ月分を保管する事になります｡ Sumo Logicは強力かつ簡単なクエリを持っているので､正規化されていないログであっても容易に分析が可能です｡
つまり､まずはSumo Logicへログを飛ばす事から始めればOKです｡
Sumo Logicの魅力は他にもあります｡ SaaSである為､スモールからラージケースまで､すぐに利用を開始する事ができます｡ あらかじめ多種のクエリとダッシュボードが用意されている為､ログを取り込んだ後にどの様に分析するか迷う事がありません｡まずはデフォルトを使用して環境に応じて少しずつカスタマイズして行けばOKです｡ 固定のしきい値だけではなく､急激な変化を検知する事が可能です｡例えばアクセスの8割が日中のサービスがあったとします｡日中も夜間も同じリクエスト数をしきい値にしてしまうと夜間の異常を見逃してしまう可能性が高いです｡スケジュールで指定する方法もありますが､Sumo Logicは変化の度合いで検知する事が可能です｡ これ以外にも収集した情報を元に将来の変化を予測することが可能です｡
Sumo Logicのデフォルトダッシュボード一覧です｡AWSに関するものを表示しています｡
ハイパーバイザーやアプライアンス､OS､Kubernetesのダッシュボードも用意されています｡ 更に気になる方はこちらをご覧ください｡全てではありませんが記載されています｡全てを確認したい場合はトライアルアカウントを取得してご確認ください｡ Sumo Logic Apps and Integrations | Sumo Logic
下記はCloudTrailのデフォルトダッシュボードの1つです｡ユーザーのログイン状況を可視化しています｡ログイン成功数もモニタリングしており､急激な成功数の増加､つまり認証情報の漏洩なども検知できる可能性があります｡ 他にはMFAが有効でないユーザーや1つのIAMユーザーから複数のIPアドレスでログインがあった場合に､IPアドレスの種類でランキングで表示しています｡
Sumo Logicの特に魅力的な機能としてログ圧縮(Log Reduce)があります｡ 異常ログは正常ログに埋もれがちです｡String Matchでアラートを上げることは可能ですが､必ずしも異常ログに含まれる文字列がわかっているとは限りません｡ Log Reduce機能は類似するものをグループ化し数を数えてくれます｡これによってどういったログがどれぐらい発生しているかを可視化できます｡砂漠から一粒の砂を見つけてくれる機能です｡
Log Reduceの画面です｡圧縮前は59ページあるログが圧縮後は2ページにまで減少しています｡
Outlier機能は移動平均と標準偏差を使って外れ値､急激な変化を検知する機能です｡いくつかの変更可能なパラメータが提供されており､ユーザーがカスタマイズすることが可能です｡ 例えば､急激な増加は検知したいが減少は検知したくない､3回連続した時だけ異常として扱いたいなどです｡
Outlierの画面です｡ピンク色の三角が検知した箇所､水色の範囲が許容する範囲です｡
Predict機能は線形回帰と自己回帰を使用して将来の変化を予測してくれます｡将来的にディスク容量が枯渇する事を検知できたり､1ヶ月後に予測されるリクエスト数を知ることができます｡
Predict機能で予測したエラーカウントの回数です｡ エラーカウントの傾向を把握することで､増加傾向であればBad､減少傾向であればGoodなどサービス状態の傾向把握の1つとして使うことができます｡
皆さんに明日からSumo Logicを使って貰うために､やや抽象的ですがログの飛ばし方をご説明します｡
よく使われるSumo Logicのログ収集方法を3つご紹介します｡ 1つ目はInstalled CollectorというSumo Logic製のエージェントをサーバーにインストールしてログを飛ばす方法です｡
2つ目はHttp Sourceという方式で､Sumo Logicに対してPOSTでログを飛ばす方法です｡LambdaやSNS､そしてFluentdなどからPOSTします｡FluentdはSumo Logicから公式のOutputプラグインが提供されています｡ SumoLogic/fluentd-output-sumologic: FluentD Output Plugin to deliver logs to Sumo Logic.
3つ目はHosted Collectorsという方式です｡S3の場合で説明します｡Sumo LogicがアクセスできるようにIAMロールを発行し､Sumo Logicがその権限でS3からログをPullします｡ CloudFrontやALBなどS3にログを出力するマネージドサービスに向いています｡
構成図でログの流れを説明していきます｡ EC2インスタンス内のアプリケーションのログを取りたい場合､インスタンス内でログエージェントを動かまします｡ログエージェントはInstalled CollectorやFluentd､CloudWatch Agentなどです｡ 赤太線が個人的にオススメの方法です｡ Fluentdを動かし､HTTP EndpointとS3両方にPUSHします｡CloudWatch Logsでも見たいという要件がなければこの方法で良いと考えています｡
S3やCloudWatch Logsにログを出力するマネージドサービスの場合です｡ S3へ出力する場合は､Hosted Collectorで収集します｡ CloudWatch Logsの場合は直接Sumo Logicへ送れないので､Lambdaを使ってHTTP EndpointとS3にPushします｡CloudWatch LogsからS3へPushする部分は Kinesis Data Firehose を使うのもありですね｡
SNSに通知するサービスもSumo Logicで収集することができます｡ そのままSNS経由でHTTP EndpointにPushするのが基本ですが､Lambdaを挟んでより詳細の情報を追加で取得してからHTTP EndpointにPushすることもできます｡ SNSが受け取るのはIDのみで詳細な内容が含まれない場合に､IDを元にLambdaが詳細な情報を取得してPushといった感じです｡
Sumo LogicでAmazon Inspectorをウォッチしてみた ｜ DevelopersIO
オンプレミスの場合は､特にアプライアンスなどのログエージェントをインストールできない機器をどう対応するか検討する必要があります｡ 基本的にSyslogに対応していると思いますので､Syslogサーバーをどこかに立ててログを一時的に収集､Fluentdを同居させてEC2の場合と同様にHTTP EndpointとS3両方にPushすれば良いでしょう｡ また､図は用意していませんが方向を逆転させればSaaSのログも収集できる場合があります｡ログサーバーからSaaSに対してリクエストを投げてログ収集しHTTP EndpointとS3両方にPushする形です｡
ログ出力のパターンはこちらのブログに詳しくまとめています｡ぜひ御覧ください｡
0
