「入門 監視」読書会レポート vol.8

株式会社リゾーム システム企画・開発部 第4グループの尾古（@patorash）です。

入門監視 読書会の第8回目のレポートです。 第7回目のレポートは、こちらになります。

tech.rhizome-e.com

入門 監視 ―モダンなモニタリングのためのデザインパターン

8回目レポート

今回は、「8章 サーバ監視」で、参加者は5名でした。

感想・意見交換

OSの標準的なメトリクス

• メトリクスは取るが、アラートは設定しない。確かに狼少年になってしまう。数値ではなく、意味の方が大事。
• 適切なインスタンスサイズを選ぶには、CPUやメモリの使用量を意識する必要がある。
• topコマンドはよく使うが、freeコマンドは使ったことがなかった。topでもメモリの使用率はわかる。
  • オプションを使いこなさないと！
• OOMkillerの呼び出しを監視するのは、なるほどと思った。
• IOPSは下がったらディスクパフォーマンスに問題あり。
  • AWSだったらburst balanceを見ればいいはず。

SSL証明書

• HerokuだとHerokuが面倒見てくれるので意識せずともよい。現在は特に監視していないが、以前はMackerelの外形監視でSSL証明書の有効期限を監視していた。
• ドメイン更新・サーバー管理用のアカウントなども含め、お客様が契約した環境で動かす管理体制だと特にあるある。
  • 契約の段階でどちらがどこに責任を持つのかハッキリさせるのは勿論、通知が機能するようにチェックしておくことも必要。
• 有効期限切れはゾッとする。特にワイルドカード証明書は範囲が広いので怖い。
• SSL証明書の期限は監視しているが、更新方法がわからないのでやり方を共有してほしい。
  • => 読書会の後、共有されました。

SNMP

• 使うのはやめましょう、と書いてあるので使うことはなさそう。

Webサーバ

• ステータスコードが大事。エラーが起きまくっているとしたら、何かがおかしい。
• 秒間リクエスト数やリクエスト時間を見る。
• 大体エラーになってから問い合わせが入るので、事前に検知できて修正できていれば、問い合わせを減らせるかもしれない。

データベースサーバ

• スロークエリは時々チェックしている。これはAPMツールを使っていたら教えてくれるからわかりやすいんだけれど、だからといってどう高速化できるか？キャッシュする等はよくやっている。
• 実践ハイパフォーマンスMySQLはDB勉強会でもよく紹介されていたと思うけれど、普段PostgreSQLを使っているからあまりチェックしていない。
• スロークエリはアプリケーション側の修正の話になる。
  • BulletでN+1は拾えているが、countよりsize、不要なオブジェクトを生成しない等、意識して行わなければならない。
• RDSでクレジットが枯渇してIOPSが下がっていることがあった。
• RDSを使っているならクレジットの監視もしたほうがいい気がする。
• RDSだとPerformance Insights、New RelicだとAPMで遅いクエリを検出することができる。
• DBのパフォーマンスチューニング難しい

メッセージキュー

• ActiveJobのキューの数とかを見ればいいのかな？Sidekiqとか。
• SC BASE *1 では帳票作成などの普通のJobに失敗すると、 Amazon SQS の デッドレターキュー (DLQ) から AWS Lambda に通知が行き、ログ保存した後に Amazon SNS を経て開発者向けの通知が飛ぶ仕組み。基本的にAWSに任せる感じ。

キャッシュ

• Heroku Postgresのページを見ると、そういうのが載っている。
  • https://devcenter.heroku.com/ja/articles/heroku-postgres-production-tier-technical-characterization
• 難しいから一度本格的に勉強しないとなと思い続けて今に至る。
• どうしてもアプリ視点、キャッシュが原因で更新されない方を問題視してしまいがち。

DNS

• 大昔に自宅サーバ立ててた頃にBind触ったなぁ
• 自社では運用していない
• Route53でほとんど運用している

スケジュールジョブの監視

• バックアップが動いてなかったなどがあってはならないので監視すべきと。なるほど。
• デッドマン装置は知らなかったが、タイムリミットを過ぎてもちゃんと動作していなさそうだったらアラートをあげる感じか？
• BOND GATE *2 では、主にRundeckを使用
  • エラー通知はRundeckがやってくれるので便利
• cronを使用している環境もある
  • エラーの監視が厄介
    • エラー発生→ログに出力→Mackerelでログ監視→エラー通知
  • ログを出力しないタスクもあるので、本に記載のような、コマンドがエラーになるとログを出力する方式はいいなと思った。

ロギング

• syslogデーモンのドキュメントを読みましょう→はい。
• ログをsyslogサーバに送ると二度と見なくなるからログ管理システムへ送りましょう。そうですね。
• ログ分析にElasticStackが紹介されていた。取り組むかー。

まとめ

サーバ監視で何を監視したらいいか、メトリクスは取るがアラートは設定しない等、様々な学びがありました。結局はそのメトリクスの値に意味を与えるのは我々なので、メトリクスを取り、数値と向き合えということなのでしょう…。

SSL証明書の期限については、更新の仕方がわからないという話の後にすぐに更新の仕方が書かれているWikiのURLが共有されたので、非常によかったなと思います。

今回も監視するべき項目が明確になってきたなと感じました。

次回は「9章 ネットワーク監視」です。

*1: 売上管理業務をはじめとした、これからのSC運営に必要な機能を搭載した次世代SCクラウドサービス(ホームページ商品説明引用)

*2: BOND GATEは直観的で使いやすい、店長支援のためのSC・専門店向けコミュニケーションウェアです。(ホームページ商品説明引用)