せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

Mackerel / NewRelic / Elasticsearch Seminarに行ってきた

奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。

ご挨拶

モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮=ビジネスの特性等を把握.

Linux OSから見るMackerelのパフォーマンスモニタリング

何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング

  • Mackerelの特徴

    • もともとははてブはてなブログを監視するツール。10年前から使っている
    • 3年前からSaaSとして公開。はてな自身がエンドユーザーでもあるのでUIには凝ってる
  • 利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSHTTPSで送信。

    • 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言語に対応
  • 遅いトランザクションや直近のアラートが観れる

    • アラートは集中管理。通知チャネルや設定条件が豊富
  • ダイナミックベースラインアラート

    • 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
  • トランザクションタイムからどのトランザクションが遅いかわかるので深掘りすることが可能

    • アプリのどの部分で時間がかかっているか
    • SQLの場合、発行されたSQLと時間
    • 外部サービスにかかった時間も観れる
  • 内部サービスの呼び出し階層が観れる

    • 一覧で赤いとアラートが発生している
  • インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨

  • デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる

    • デプロイ前後のパフォーマンスが比較
    • デプロイした時刻が残るので調査に役立つ

応用編

ソースコードを修正することで、さらなる情報取得が可能

  • カスタム属性

    • 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
    • ショップごとにパフォーマンス追跡が可能
    • 入れない場合、アプリ全体でしか見れない
  • カスタム計測

まとめ

  • NewRelicはAdobe、Sansan、楽天

    • パフォーマンスに売り上げに繋がるサービスで多く採用
  • ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる

  • 最新動向としては、AIに注力

    • 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
  • NewRelicを導入して開発とインフラのコミュニケーションが改善

    • インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
    • 開発もパフォーマンスに対する意識が高くなった

Elastic Stackによるログの監視入門

ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一

昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立

Beat

  • Go言語エージェント。
    • データがあるところに仕込むと取り出してくれる
    • 送り先はSearchかLogstsh
    • File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々

Logstash

  • Rubyで書かれている
    • JRubyで実装されているため、Javaが必要だった
    • フィルタリングのようなパイプライン処理が可能

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にお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.