Mackerel / NewRelic / Elasticsearch Seminarに行ってきた
奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。
ご挨拶
モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮=ビジネスの特性等を把握.
Linux OSから見るMackerelのパフォーマンスモニタリング
何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング
Mackerelの特徴
利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSにHTTPSで送信。
- Mackerelからエージェントを導入したサーバーにアクセスすることはないからセキュア
Linuxモニタリング
ロードアベレージ
- 実行待ちのプロセス数とディスクIO待ちのプロセス数の合計
- 高い場合はCPUやディスクIOが詰まってる状態
- uptimeやtop等で確認できる
- uptimeの数値は1分間、5分間、10分間の平均
- Mackerelは標準で5分平均をサポート
CPUの使用率
100%の場合、どこが使っているかを知るのが重要
- topコマンドのCPU使用率は全コアの合計。1を押すとコア別に見れる
メモリーディスクioFSは省略.
Mackerel本を読んでね.
モニタリングしたものをどう活躍するか
根本原因をどうやって見つけるか
- ロードアベレージのアラートは処理がさばききれてない可能性。ただ、即障害とは限らない
- スパイクなら問題ない
- 負荷がかかっているコアが1個なのか全部なのか
- 継続的に見ないとダメ
- 「実際にさばいている処理<捌くべき処理数」の状態が継続していないか?
- 高まり続けているのは処理待ちがたまり続けてる
- 高い場合でもコア数を確認するのが重要
- CPUかディスクがボトルネック
- CPUのメトリックから原因を読み取る
ディスクIOの場合はSSDに換装する
userが高い場合はアプリケーションのループや処理が原因
- 金の弾丸(コアを追加、コアのスペック向上)で解決できる場合も
- 1個のCPUで止まっているなら、コアのスペック向上
CPUが常に低い場合はサーバーがオーバースペック。コストダウンのチャンス。
まとめ
- パフォーマンスモニタリングは難しい
- 見るべき値や条件はサービスやサーバーの役割でちがう(Webサーバー、DBサーバー)
- 勉強しておけばアプリエンジニアとしての付加価値に
- スパイクなのか少しずつ上昇しているかを知るためには時系列データが必要
- 過去のデータは取れないからモニタリングツールは重要
- 問題が起こる前兆もわかる
QA
Q:コマンドで監視できるけどMackerelを導入する理由は?
- A:コマンドを打たなくてもよくなる。毎分実行、加工、失敗した時云々・・・。DB、グラフ、分析を自分でやらなくていい。
Q:HinemosとかZabbixとのちがい?
- A:セルフマネージドは監視対象が増えた場合のチューニング等のメンテナンスを自分でしないと行けない。 また、Zabbixを監視するZabbixとかも必要になる。 MackerelはSaaSなので何もしなくていいし、他のツールやサービスと連携できる
New Relic によるアプリケーションパフォーマンス監視入門
New RelicはSaaS型のパフォーマンス分析ツール。
パフォーマンス、アラート、障害分析機能(切り分け)等様々
APM
APM=ApplicationPerfomanceMonitoring
- エージェントをインストール
- Java、Go等の7言語に対応
遅いトランザクションや直近のアラートが観れる
- アラートは集中管理。通知チャネルや設定条件が豊富
ダイナミックベースラインアラート
- 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
内部サービスの呼び出し階層が観れる
- 一覧で赤いとアラートが発生している
インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨
デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる
- デプロイ前後のパフォーマンスが比較
- デプロイした時刻が残るので調査に役立つ
応用編
ソースコードを修正することで、さらなる情報取得が可能
カスタム属性
- 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
- ショップごとにパフォーマンス追跡が可能
- 入れない場合、アプリ全体でしか見れない
カスタム計測
- メソッドに指定することでトランザクションのトレースをより詳細に見るために必要
まとめ
-
- パフォーマンスに売り上げに繋がるサービスで多く採用
ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる
最新動向としては、AIに注力
- 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
NewRelicを導入して開発とインフラのコミュニケーションが改善
- インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
- 開発もパフォーマンスに対する意識が高くなった
Elastic Stackによるログの監視入門
ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一
昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立
Beat
- Go言語エージェント。
- データがあるところに仕込むと取り出してくれる
- 送り先はSearchかLogstsh
- File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々
Logstash
ElasticSearch
Kibana
- nodejs
- ElasticStackの窓口
導入とか
大規模な場合はBeats→kafka→Logstashの構成でElasticsearchの負荷を下げる
nginxやApache2のログは、ファイルの場所とElasticsearchを指定するだけ
PacketBeatsはプロトコルを監視
パケットを指定するだけなので再起動は不要で後から差し込める。
- オーバーヘッドがそこそこある。本番ではパケットをミラーリングして監視するといい
FilebeatやLogstashは1行1データではなく複数の行も観れる
- パターンマッチを利用する(先頭がスペースだと複数行のデータとして扱う)
X-PackはClosedソース
- 検索のクエリでアラートが可能(Kibanaにはアラートがない)
- 例:10秒以内にエラーが5件
機械学習でパフォーマンスを予測した曲線
- NewRelicと被ってる
Elasticsearchは検索エンジンなので、パターンでログを検索して、それ以外のログが出たらアラートといった使い方のできる
- これにも機械学習も組み込める
感想
あまり情報を追いかけていない分野だったけど、サービスのクオリティが非常に高いと思った。
どのツールも得意な分野があるので組み合わせて使うのがいい感じ
先日のioドメイン障害といったリスクもあるけど、SaaSにお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.