今回やった事は以下の3つ。

ログ・メトリック・イベントの保管・監視をする目的と必要な機能を整理
監視にまつわるSaaSを集めて眺めた
機能を比較して面白そうな事や注意した方が良さそうな事を考えてみた

やってみた感想

感想は下に並べておく。詳細は読む必要はあまりない。

監視・通知の目的自体について

監視・通知の目的や技術については綺麗に整理できなかった
いくつか体系的な知識がある事が分かったので勉強しておきたい

監視について

面白そうな事や需要がありそうな領域で未実装な事がたくさん残っていそう
- 仮想化が進むと監視対象の追加や除去などメンバーシップ管理が複雑になるので勉強しておきたい(いい記事があった)
- システムに依存する関係で、新しい設計方針やワークフローや依存インフラが出るたびに必要な領域が増える感じがする
用件を真面目に考えたり、OSSの採用や内製を検討せずにSaaSを選ぶなら下が無難だし大きく外れないと思った
- New Relic
- DataDog
- Elastic
- PagerDuty
- Neptune.io

システム分析・集計

システムのクライアントサイドのログ・メトリックも重要
システムの稼働状態の監視はシステムテストを利用する方法もある
稼働コンポーネントの発見・依存検出ができると面白い(役に立つかはわからない)
分散トレーシングは需要があり便利(zipkin ってOSSがある)
ダッシュボードの設定を簡単にするためにDSLを準備するというアイディアは勉強になった
ダッシュボードの内容のスナップショット・レポーティング用PDFの生成は需要がある
ダッシュボード内で全文検索ができて関連メトリックを表示するの便利
SQL使ってリアルタイムにダッシュボードの表示項目を決めるの需要がありそう
- 実装は少ない
- 時系列情報の横断的なクエリ実行には需要がある
- Presto などクエリエンジンの改修とか接続性向上は大事
Elasticsearch Beats がパケット解析して自動でスロークエリとか統計取ってるの凄い
- オーバーヘッドが気になる
JVM ,PHP とかはコードレベルの解析をできてしまう監視ツールがあって便利
- 他言語も欲しい
カナリアリリースやABテストに対応するためにマルチバージョン・マルチコンフィグに対応した分析基盤があると便利そう

アラート・自動復旧

アラート多発は一般的な課題として認識されていて偽陽性への対策は重要
アラートと共にリソースメトリック・関連コンポーネントのアラートで相関が高いものを表示するだけでヘルプに使える
通知はSMS, e-mail, 電話, Slack, ChatWorksなどを見た
- 他に何があると便利だったり使いやすいか
Slack, ChatWorksにサマリーを貼り付けられるのは需要ありそう
通知は時間帯・エスカレーション順序、認知されない場合の対応など選択肢がたくさんある
- 実践的で現場に優しいテンプレが準備できると重宝されそう
アラートのエスカレーション・オートリカバリ・コラボレーション・レポーティングって流れは綺麗に設計しておくと運用負荷が大きく下がる
オートリカバリとかサービスへの操作を自動実行する場合にはフェイルセーフな設計にしないといけない
タスクランナーで自動復旧をやる前には障害診断が必要、ユーザーにルールを設定させるとフェイルセーフになるか心配
ユーザーに影響していて責任範囲のドメイン内で人が対応するべき項目のみで通知が来てほしい
依存先コンポーネントから依存元コンポーネントに通知が行き障害診断・通知に利用してほしい(通知というかリアルタイム処理)
解析結果はサマリとして通知に載っていて欲しい
簡単な障害は自動復旧したい、実行履歴の報告は残ってほしい
他のドメインや顧客が障害発生・発生予測・パフォーマンス劣化の通知を受け取れると便利かも知れない

目的について整理した

サービス稼働によりアプリケーションの永続化データ以外に以下を得られる。

ログ: syslog, errorログ, アクセスログ, クライアント, ...
メトリック: JVM, OS, ミドルウェア, クライアント, 利用量, ...
ステータス: プロセスの存在, portと接続, システムテスト・合成トランザクションの実行, 利用サービス・CSからの報告

システムやサービスにまつわるメトリック・ログ・ステータスの管理目的を考えた。以下の4つが思いついた。

レポーティングはサービスの提供情況を確認・改善するためにある
モニタリングはサービスの障害を予防・分析するためにある
アラーティングはサービスの障害に対応するためにある
オペレーティングはサービスの継続のために実施する

レポーティング

サービスの提供情況を確認・改善する。例えば以下のような事が求められる。

利用サービス・ユーザー毎の利用統計
特定オペレーション(リリース・オートリカバリ)の内容とサービスメトリックの変化の報告
カナリアリリース・ABテストの影響調査
アドホックな解析・可視化

そのためログ・メトリックの収集・保管・比較・分析・可視化できる事が求められる。またリリースやリカバリといったオペレーションログを落とす必要がある。リクエストの属性やサービスのバージョンに対応した異なるタグをログ・メトリックに追加するルールを追加できる必要がある。

モニタリング

サービスの障害を予防・分析する目的がある。例えば以下のような事が求められる。

メトリック及び統計情報の可視化
ログの検索
メトリックのアドホックな統計処理・異常検知
システムリソースの消費状態の傾向予測と可視化

なのでログ・メトリックの収集・保管・可視化・検索・分析できるようにする事が求められる。また複数の関連サービスのデータを横断的に問い合わせて分析する必要がある。

アラーティング

サービスの障害に対応するためにある。例えば以下のような事が求められる。

障害を検知して通知する
障害を検知して自動化された回復処理を実施する
依存しているインフラ・外部サービスの異常も検知して総合的に障害を判断する
異常検知の精度を改善される

なのでログ・メトリック・稼働状態のリアルタイム処理により異常検知ができる事が求められる。またイベント種類に応じて適切にルーティングされる。

オペレーティング

サービスの継続のために実施する。ここではアラーティングと連携して自動化を進める視点に限定して考える。例えば以下のような事が考えられる。

イベントやメトリックとその分析情報によって障害診断ができる
障害診断が失敗した場合は人へ通知される
障害対応や実行条件を登録できる
実施記録が残されレポーティングに繋げられる
障害の影響や規模を報告する
障害診断の精度を改善される

なので実施条件・運用作業の登録と実施ログの収集・保管・分析・報告する事が求められる。フェイルセーフな設計が求められる。

目的を支える機能を考えてみた

先に並べた4つを支えるサブ機能達を制するとだいたい下になる。

可視化

メトリック・ステータス・イベントの表示

検索

ログの全文検索

異常検知

ログ・メトリック・ステータスなどからイベントを生成

障害診断

イベントをきっかけにログ・メトリック・ステータス・イベントから障害を判別

通知

イベントをきっかけに関係者に連絡

エスカレーション

通知内容・障害診断の結果・関係者のリアクションによってエスカレーションする

自動オペレーション

イベントをきっかけに自動回復・自動デプロイ・自動スケール

メトリック生成

システムの状態、ビジネス実績をメトリックとして出力するアプリケーション・ミドルウェア開発時に埋め込む

ログ生成

主にINFOログ, CRITログの2つの記録を残す

INFOログ

サービス提供の証拠
CIRTログ

即座に対応が必要な異常とその詳細を記録

データ保管

ログ・メトリック・ステータス・イベントといった時系列情報を記録保持する

アドホック分析

保管された時系列データに対して統計処理やフィルタ処理を実施して出力する

マルチバージョン・マルチコンディション管理

「『リクエストの属性・サービスのバージョンに対応した異なるタグ』をログやメトリックに追加するルール」を作成・有効にする

利用状況報告

保管された時系列データの統計処理を意思決定に利用できるよう可視化する

監視系のSaaSを集めて調べてみた

ログ・メトリック・ステータスを扱うSaaSがあるので、ここではサービスブランドを並べてみる。正直、多すぎて調べるのが辛くなった。

New Relic

2008年創業のWebアプリケーション, モバイルアプリケーションのリアルタイム監視サービスを提供する。クラウド・オンプレミスやハイブリッド環境で稼働し70以上のクラウドベンダと提携している。ちなみにロゴの使い方やブランド表記を公開してくれている。

調べているとままある事だけど自分よりも詳しく書いている記事を見つけたのでこちらも参考にするのが良さそう。無料枠で簡単に設定できるっぽいし便利と勉強を兼ねて設定してみようと思う。Qiitaに日本語2次情報が溢れているのも良い。主だったサービスのメモを残しておく。

New Relic APM

アプリケーションモニタリング(APM)を行える。メトリックの収集と可視化と通知機能が提供される。またアプリケーションのプロファイルも取得できたりするっぽい。ネットでは、PHPのコード行が表示されてるスクリーンショットが多数公開されている。 GolangだとGCのpause time, pause frequencyなどが落ちるっぽい。さすがにアプリケーションコードにリンクして使うんだろうと想像している。(まだアカウントとってないので見てない)

メトリック転送に使えるプラグイン一覧を眺めるとわかるがベンダーが紹介している物だけでも結構豊富。

Apache Traffic Serverはなかった。 HAProxy関係が3つもあったりと重複が見られるのが気になるところ。

New Relic Movile

モバイルアプリケーションのクライアントサイドでのプロファイル結果などを転送してくれる。

New Relic Synthetics

対象URLに対して稼働確認のリクエストを送信する事で稼働確認を行う。発行元地域・頻度などを調整できる。Ping モニターが提供され、そこでレスポンスタイムなどサービスメトリックも確認できる。

New Relic Insights

Magic Happens Hear.なサービス。クエリ(NRQL)を書いてリアルタイム分析を可視化するダッシュボード。

時系列DBに格納されたデータにクエリ発行で表示するのかストリーム処理基盤上で変換して格納して、過去データはマイグレーションするのか。まぁ容量を食わないし前者なんだろうと想像しているけど、やっぱり魔法が起きているのかも知れない。

New Relic Browser

Real User Monitor(RUM)という監視機能を提供する。 Google Analytics的な感じでJSによるエージェントがクライアントサイドでのプロファイル結果を転送する。アクセス元・セッショントレース・ブラウザエラーの収集なども金を払うと出来る。 New Relic APMの利用者はAPMのコンパネからも閲覧できる。

Dynatrace

APM を提供している。パフォーマンス問題に注力している印象がある。モバイル端末でのスタックトレースの提供と分散トレースを提供している。

Dynatrace Saas And Managed: All-in-oneのパフォーマンスモニタリングツール。 Ruxitと呼ばれる機械学習エンジンを抱えてる
Application Monitoring: パフォーマンスモニタリングやプロファイルを実施する
UEM: モバイルアプリケーションで、クライアントサイドのログ・プロファイルをエンドユーザーから転送しソースコードに対応させた可視化を提供している
Synthetic: Dynatraceからテストリクエストを飛ばすことでエンドユーザーに公開する前に検証をする
Data Center RUM: DC内のネットワークやトランザクションを集計・可視化する、エンドユーザーのトランザクションに紐付けて解析できる

DataDog

API, Dashboard, Alertsが提供されている。アラートは課金ポイント。

ログ・イベントの横断した全文検索やメトリック可視化・メトリックやイベントを条件とした通知・ダッシュボードのカスタマイズ・コラボレート機能が提供されている。ダッシュボード上で障害対応のコミュニケーションが取れるなど実務に寄った機能を提供している印象を受けた。障害が監視情報と共に表示されて記録されるの良いと思った。

内田さんの勉強になる記事も見つけた。

この記事の前半でモニタリングとかについて考えてみたけど、一般的な理論とDataDogの経験を踏まえた体系の説明記事へのリンクも提供されていたので読んで再考したい。リンク先の記事では「仮想化が進んで監視対象のメンバーシップ管理をどうしよう」って課題についてもk8sをベースに書いてて勉強になる。

Mackerel

エージェントはGoで書かれていたはず。日本製の監視サービス。グラフスナップショットの他ツールへの共有は簡単らしいと謳われていた。またサービス・ロールによってノードの所属を解決する設計らしい。

Splunk

Splunkはビッグデータ活用ソフトウェアの提供を行っている。結局のところ提供してる機能は監視・検索・可視化・分析・相互関連付け。

格納データに対し、リアルタイム処理としてクエリを発行したりアドホッククエリを実施したりできる。 Splunk Stormと呼ばれる AWS上にホスティングされるSaaSを提供している。

S3に格納したログの全文検索なども出来る噂が書かれてた。その場合はSpark SQLを利用したりするのだろう。検索でなく総舐めになる。

バックエンドを切り替えてクエリを投げられるって事なので、Presto動かしていたりするのかも知れない。レポーティング機能ではレポートをPDFにして他に埋め込めるよとか言っていた。

Splunk IT Service Inteligence なるサービスが提供されていて偽陽性アラートへの対応・障害予測など機械学習っぽい事も提供していた。

Neptune.io

AWS出身によるスタートアップで通知を受け取ってタスクを実行するサービスを提供している。 Neptune.ioは実行タスク毎に異なるエントリポイントを提供する設計になっているみたいで、叩く側が複数の通知を実行できる必要がある。

ソフトウェアになるが、競合ツールにStackStorm,Openbookがある。

Elastic

Elasticはソフトウェアプロバイダだけど、気になっているしAWSへのマネージドクラウドサービスを提供しているので載せてみた。 Elasticsearchを中心としてコンポーネントを提供しており、構造化・非構造化データのリアルタイム検索・ログング・解析に関連したエコシステムを育てている。

コンポーネントの詳細はロギング周辺のソフトウェア比較の時にでも書くけど、特にBeatsというshipperの提供で便利でかっこいい感じ。 Beatsの凄いところはパケットを解析してプロトコルごとに集計したりロギングしてしまうところ。マルチテナントとかどうなってんだって思う。あとだいぶ強引な事をしていそうで安定しているのか通信のオーバーヘッドはどうなんだとか色々と気になる。

X-Packって呼ばれる拡張が提供されている。内容はShield,Watcher,Marvelのセット。またGraph ってコンポーネントが提供されていた。

Influxdata

TICKと呼ばれるモニタリングスタックの開発を行っているソフトウェアベンダ。 Elasticと同じで個人的に気になっている事とAWSへのマネージドクラウドサービスを提供しているので載せた。 AWSなどのIaaSベンダがあることでソフトベンダもコンサルやチューニングの他にクラウド事業を提供できるの面白いと思った。

InfluxEnterpriseというエンタープライズ版のソフトウェアも提供している。これはTICKスタックの高可用性クラスタ機能の追加とマネージメントUIのセットみたいな感じだった。 Elasticsearchと違ってJava実装でなくLuceneなどメモリを食う仕事をしない分リソースの利用効率は良さそう。全文検索については不安が残る。と思ったらInfluxの人がホワイトペーパー出してた。 Elasticと同様にコンポーネント詳細は別の機会に書く。

PagerDuty

通知に特化したサービス。Datadob, Mackerelなどから通知を受け取り通知ルールに基づいて適切にエスカレーション&アクションする。

ユーザー毎に通知方法のルールを設定でき、緊急度やe-mailで反応がなかったらSMSなどが可能。またサービス毎にエスカレーションルールを設定できる。多くのソフトウェア・サービスと連携できる。

Pingdom

ヘルスチェックサービス。主にWebサービスなどに使える。

少なくともHTTP(S), MAIL, PINGによるヘルスチェックが提供されている
シナリオテスト機能も有している
サイトにJavaScriptコードを埋め込んでパフォーマンスチェックを行うRUM機能を有している
メトリックダッシュボードのLibratoと相性がいいというか、同じSolarWinds ファミリーを持ってる
通知は偽陽性が減るようにダブルチェックする

Librato

ログ・メトリック集約・リアルタイム処理・可視化・通知までのフルスタックモニタリングサービス(SaaS)を謳っている。ロゴにSolarWindsグループの気配を漂わせている。

簡単に集約できるメトリックが少なかったりダッシュボードのテンプレートの少なさで苦労している記事があった。 Webツールの設定をDSLで簡単にするという方法は見習いたい。Goでもyaccあるし作れそう。

上記の苦労する記事を読んで、収集メトリックの出力フォーマットや語彙の標準化やガイドライン作らないと業界全体で類似品を作る羽目になって辛そう。もしくは買収とかが進んで便利な方向に統合してほしい。

Sumo Logic

ログ・メトリックの集計とアドホック分析・リアルタイム分析と結果をダッシュボードで提供することによる可視化を行うSaaS。リアルタイムクエリの結果により通知することも可能。保持するログデータは一定期間経過すると破棄する。競合にはSplunk Storm があったりする。BigQuery + ダッシュボードとかでも似た事が実現できる。

OpsGenie

通知を集約してエスカレーションするSaaS。SMS, 電話, e-mailなどいろいろ使える。 PagerDutyよりもだいたい1/2から2/3 くらいの料金プランになりそう。機能の違いや組織の大きさにスケールする具合がどうかはわからない。

Anturis

メトリック・ログの監視を行うSaaS。サーバーリソース監視・ネットワーク監視・アプリケーション監視・Web監視(pingdom的なこと)・レポートィング・マネジメント・アラーティングなどが機能として含まれる。

レポーティング・アラーティングでは各種コンポーネントの論理的な依存関係を登録することで大量のアラートを出さないようにするなどの工夫ができる。この管理がどれくらい簡単で無駄アラートの削減に役に立つかはわからない。

AppDynamics

アプリケーションパフォーマンス監視(APM)のツールを提供している。 SaaSも提供している。アプリケーショントポロジーや相互依存関係の自動発見を提供している。どうやっているのか気になる。日本だと丸紅が絡んでる。

BigPanda

エスカレーション機能に特化したSaaSを提供している。大量のアラートを受けとり重要なものが実際に通知されるようにフィルターする。またアラートやメトリック間の相関を自動で取る事で関連するログなどを探して報告するようにするなどの機能を持っている。

Monitis

Pingdom的なSaaS。

Sematext

オンプレ・SaaS形式で提供されるAPM。基本的な事はだいたいやっている。アプリケーションコンポーネントの接続関係やJavaアプリケーションのオンデマンドデバッグ・プロファイルが可能になっている。

Microsoft

Bluestripe を買収して自身の監視ツールに統合していった。買収理由はネットワーク上で動いているアプリケーションの自動検出と依存関係の分析に惹かれたみたい。

他にあった諸々のサービス

APMだったりRUMだったり簡易監視だったりのサービスは大量にある。勢いで読んだから詳細はわからないけど、それほど面白いものはなかった気がする。

Gear5, Instrumental, LogicMonitor, Monitis, Scoutapp, Stackify, WhatsUpGold, Manageengine Opmanager, Count.ly, CA Technologies, Aternity, Compuware Gomez, Level Platforms Managed Workplace, Boundary, IDERA

サービス比較に使った資料

最後に監視系サービスを探すのに使った資料を並べておく。

感想

最初の方にだいたい書いた。とりあえず似たようなサービスは大量にあって既存サービスあるのになんで挑むんだろう? 勝算は? ってのが1つ。あと疲れた。