tjinjin's blog

インフラ要素多めの個人メモ

Monitoring Seminar in mercariに参加しました

勉強会

About

勉強会参加の記録です。走り書きと感想を貼っておきます。そのうちスライドが公開されるかと思うので、そちらも合わせてご参照下さい。（随時更新予定です）

メルカリのサービスの監視について @kazeburo mercari

speakerdeck.com

mercariのこれまでの監視

  • 元々はZabbix.さくらの専用サーバ
  • トリガーをうまく使って監視してた
  • JP/USでzabbix使ってた（JP:さくら、US:AWS）
  • zabbix設定が少しずつずれていく。（専用サーバとAWSで違いがあったり）
  • zabbix自体のツラミもあった
    • mysqlへの負荷、監視の遅延
    • zabbix芸が大変
    • 通知をもっと良くしたい
  • mackerelへの切り替え
  • 最初はService Metricsから導入
  • Zabbixのトリガーをpluginとして実装
  • mackerelのよさ
    • 運用が楽
    • JP/USでの監視項目を合わせやすくなった（差分はAnsibleで吸収）
  • UK追加時にほぼ流用できた
  • gcpはdatadogで監視している（コンテナ向け）
  • prometheusやstackdriverも使っている
  • kurado(RRDTool) NewRelicも利用

mackerelでのサーバ監視

  • pluginの使い方の話
  • MySQLの監視。結構いろいろ監視してそう（inodeとか）
  • LAはコア数で割って監視している
  • machine errorの監視やraidの監視もしてる
  • 監視は継続的なテスト

聞いた感想

  • 環境が複数に分かれたときに設定などにずれが出てくる問題はあるあるだなーと思った。ちゃんとコード化して差分を吸収する手段（Ansible）を用意していくのが必要だなーと感じました。新しく環境を作りたいってなったときに、すぐにそれなりのものを準備できるとかっこよさそう。今個人的にここで悩んでいたので、mercari社でも似たようなことあるんだなーと安心？しました
  • 監視ツールが結構別れていて横断的に見れてるのかなっていうのはちょっと思いました。どんな感じで使い分けているかをもうちょっと聞いてみたいと思った
  • 監視は継続的なテストって言葉がすごい頭に残りました。1回やって終わりではないし、利用率があがれば閾値も変化するし

マイクロサービスの監視 @spesnova mercari

  • 9月入社
  • micro serviceをどう監視するか
  • mercariはスケーラビリティの問題にぶつかりつつある
    • developerの協調がどんどん難しくなっている
    • 他チームとの調整は必要だけど遅くなる。micro serviceは小さいサイズに分割して早く動けるようにする
  • micro serviceは 疎結合・意味のあるまとまりを作るもの
  • 組織の再デザイン・セルフサービス・標準化・自動化が必要
    • オーナーシップを持てるようにってことだよね。権限の委譲というか
  • k8sがmicro serviceのキーとなる

micro serviceをどうmonitoringするか

  • 監視の役割
    • 集約・アラーティング・直す
  • datadog/stack driver/pagerduty/sentry/newrelic
  • モノシリックだと依頼ベースでのやり方（小さい組織規模なり、アプリが少ないなら問題ない）
  • 組織がアプリになっていくとOpsがボトルネックになっていく。。。
  • 開発者自身で監視設定などをできるようにする
    • 開発者ができるようにする.
    • pod のmanifest内に関し設定を書く -> Opsに依存しなくてよい
    • 監視agentはSREが管理。
    • k8sの世界わからないのでイメージしにくかった
    • datadogだと基本的な情報は取れるのでアプリ固有の問題だけ取れば良い
    • yaml(設定ファイル)の書き方難しいよね問題
  • 時間押してアラーティングとか聞けなかった
  • SREは開発者が自分でできるようにする。開発者が自分で頑張る

聞いた感想

  • 監視というかSREのあり方の話と思って聞いてました
  • 組織が多くなっていくと足回りを軽くするためにmicro serviceにしていかないと、開発者もオーナーシップ持ちにくいし、Opsエンジニアも依頼作業ばかりになって辛くなっていくんだろうなー
  • k8sの話で開発者が監視を入れるみたいな話は知識不足であまり理解できなかった。基本ベースはSREチームが作るからあとは開発側で自由にできるような仕組みという認識
  • SREという役割は開発者がオーナーシップを持って自由に開発・改善できる場を作る役割なのかなーと感じた
  • 時間なくてかなり飛ばしてたのでもっと詳しく聞きたいなーと思いました

Mackerel自身のモニタリング、監視について @kizkoh はてな

speakerdeck.com

信頼性確保に向けてやっていること

  • staging<=>productionで相互監視
  • agentがproduction/stagingで分かれている。設定自体は同じ
  • Nagios/pingdomも併用
  • Nagiosは外形監視（さくらVPSから監視）
  • 外形監視は3層、nagios/pingdom/route53
    • cronの終了ステータス監視ってどんな感じでやっているんだろう

mackerelの運用で得たメトリック、監視の知見

  • NLB
    • ICMPで監視できないので、check-tcp(plugin)で監視
    • TCPのConnectionを晴れるかチェック
  • Active-stanby
  • Kinesis Streamのモニタリング
    • makerel-plugin
  • ネットワーク

聞いた感想

  • staginとproductionの監視を相互にやっているのはなるほどと思った
  • tcpeekとか知らなかったので調べたい感
  • iptablesで各通信量を把握するのは便利そうと思った

開発者と監視 @songmu

資料はこちらです。

開発者と監視

  • 開発者と監視の話
  • mackerelでイベント通知ができるようになった
  • 「監視とは継続的なテストである」
  • 監視もテスト書こうぜ
  • 監視に対する抵抗感がある
  • 監視とはシステムに対する高速健康診断
  • 分かる範囲でやっていこう
  • 監視のコード化
  • フォーマットはそれなりに統一されてる
  • 開発者こそ何を監視すればいいか知っているはず
  • モニタリングエンドポイントを生やす
    • prometheusのexporter的な感じ？
    • gearman
    • システムに監視の口を空けておく

ケーススタディ

  • サーバレスアーキテクチャの監視
  • golang-stats-api-endpoint?は便利
  • 外見監視のデーモン監視
  • 毎分0秒に外形監視をワーカーが叩いている
  • 監視ツール作るの楽しいよ！

聞いた感想

  • 開発者の監視に対する心情の部分の解説があってなるほどなと思った。普段から触れていると大したことないように感じてしまうけれど、あまり知らない人からみたら恐ろしい何かなわけなのでその不安感みたいなものを取り除いてあげるのが必要そう
  • 監視の口を空けておく話があった。これはシステムの内部情報を取得できるエンドポイントを生やしておくと便利だよねという話だと思う。prometheusのexporterみたいな発想だなーと思った。

まとめ

これからのmackerelのロードマップはメモしている暇がなかったので公式からの案内をお楽しみに！