1章 監視のアンチパターン
作成日: 2024/5/28
最終更新日: 2024/5/30
1.1 アンチパターン1: ツール依存
1.1.1 監視とは複雑な問題をひとくくりにしたもの
監視とは、非常に大きな問題の塊、複雑な問題をひとくくりにしたもの、単純で単一の問題ではない
1つのツールで解決できる問題ではない、汎用的、あるいは専門化されたツールが必要
観察者効果は気にしない
観察者効果とは: 監視する行為が監視対象を変化させてしまうこと
監視ツールがシステムに負荷を加えてしまうこと
2017年においては負荷は非常に小さいはずなのでシステムは処理できる
エージェントもインストールしよう
管理設定は構成管理ツールで
ツールは増えても良い
目的に応じてそれぞれ専門化された別のツールを使うのはよいこと
同じ情報を提供するツールは集約
別の情報を提供するなら別々でOK
それぞれのツールが連携して使えるとよし
「仕事ができる最低限の数ににしよう」
ツールを統合して必要性に見合ってない状態で使うよりも、問題を解決するツールを使おう
→ 統合したら、「Aは問題ないがBがいささか使いにくい、必要を十分に満たせない」はよくない。それなら統合しなくてよい。
1.1.2 カーゴ・カルトなツールを避ける
ツールは、評価し、試してみて採用/不採用する
機能をしっかり確認する
「ツールが実現することと、あなたやあなたのチームが苦痛なく実現できることが一致し、うまく動くようにしましょう。」
どっか成功したチームが使っているからといってそのツールを導入したら自分のチームも成功するわけではないぞよ
1.1.3 自分でツールを作らなければならない時もある
やりたいことをしてくれるツールが出回っていなかったら、目的に応じたツールを自作するのもよき
小さく、何かに特化したツール
1.1.4 「一目でわかる」は迷信
監視に対する一目でわかるアプローチとは、状態を見るための1つの場所がほしい の意
「1つのツールや1つのダッシュボード」ではない
「ツール:ダッシュボード = 1:1」の必要もない
監視は複雑な問題の塊、なので
1.2 アンチパターン2: 役割としての監視
監視とは役割ではなくスキル
「監視は、他の仕組みから孤立した仕組みではなく、サービスのパフォーマンスのために重要」
チーム内の全員が監視について責任を持つこと、ある程度のレベルに至っておくべき。専任のひとを1人設ける、はアンチパターン
「監視するまで本番環境とは言えない」！！
1.3 アンチパターン3: チェックボックス監視
「これを監視してます」という言うための監視、よくない
アンチパターンの兆候
システム負荷、CPU使用率、メモリ使用率などのメトリクスは記録しているが、システムがダウンしたことの理由はわからない。
→ 理由がわかるようなアラートになってると良き、ということ？
条件を組み合わせるんだろうか？
外形監視アラートにCPU・メモリ使用率、リクエスト数とかもいっしょに入れるとか？？
誤検知が多すぎるのでアラートを常に無視する。
→ Slack にアラート流れると、対応はしなかったとしても傾向を知れるのは良いと思うんだけど、そういう用途で使うの本来の姿じゃないかもな... これも「誤検知」にくくられるかも...
ふだんの傾向を知っておくのは大切だけど。ふだんを知らないと、異常が異常か否かわからない。
→ 3点の平均値、とか、n回連続で発生、とかの条件は入れてるけど、もっと絞り込んだらいいのかな...
各メトリクスを5分あるいはそれより長い間隔で監視している
→ なるほど、それはだめそうだな
メトリクスの履歴を保存していない
→ おおう、これは何か起こってもわからなくない？
1.3.1 「動いている」とはどういう意味か。「動いている」かどうか監視しよう
「動いている」とはどういう状態なのか、チームで定義する
(本では、「サービスやアプリケーションのオーナーに聞いてみることから始めましょう」)
e.g.
HTTP 200 OK が返ってきているか
ページに特定の文字列があるかどうか
リクエストのレイテンシが小さいかどうか
→ 外形監視
何が悪いのかを教えてくれるとは限らないけれども、「何かがおかしいことを示す優れた指標」
→ なるほど
「時間が経てば、サービスやアプリケーションにさらに詳しくなり、もっと多くのチェックやアラートを設定できるようになるでしょう。」
→ ふむ、何かできるかな...そういえば 5xx の数が異常、とかアラートしてないな... 例えばそういうの？
Sentry から Issue があがるけどそれは webアプリ起因のものだけだしな、閾値とかしてないし (n回以上で発報とか)
Sentry も「error tracking and performance monitoring platform」(エラー追跡と性能監視) だから監視だな
「目的に応じてそれぞれ専門化された別のツールを使う」になるのかな
でも Mackerel でも Datadog でもステータスコードの監視はできるよね
Datadog ログ監視もできるよね、トラッキングもできるよね
Datadog でもCPU・メモリ使用率とか監視できるよね
使い分けがわからなくなってきた
これは集約パターン？専門化で別々パターン？
ひとまず、エージェント入れるなら Mackerel か Datadog どっちか片方で良い気がしている
DatadogならAPMも入れてるし、ログも送ってるし、1箇所で見られてそれぞれの情報を (Datadogが) 連携させてくれるので、調査しやすい気がするんだけど
というか、Sentry も Datadog も Mackerelも、使いきれてない、十分に活用しきれてないし、使いこなせてない
1.3.2 アラートに関しては、OSのメトリクスはあまり意味がない
動かすサービスによっては、元々リソースをたくさん使うものもあるが、それで問題ない
MySQL が継続的に CPU 全部を使っていたとしても、レスポンスタイムが許容範囲に収まっていれば何も問題ない
→ そうですねえ
OSのメトリクスは診断やパフォーマンス分析にとって重要
パフォーマンスに影響を与える可能性のある負荷の急変化やトレンドを確認できる
「しかし、99%の場合、これらのメトリクスはだれかを叩き起こすには値しません。」OSのメトリクスをアラートに使う明確な理由がないなら止めてしまいましょう。
→ たしかに、アラート使って傾向を知るってなんか違うな。
(生死の次に) 一番気になるのは、レスポンスタイムなので、レスポンスタイム遅い〜アラートあがる → その時間帯にECSサービスCPU・メモリ使用率、DBのCPU・メモリ使用率...に何が起こってたかパッと確認できるダッシュボードがある、みたいな感じが良いのかな
1.3.3 メトリクスをもっと高頻度で取得しよう
最低でも60秒に1回メトリクスを取得する
トラフィックの多いシステムでは、もっと頻繁に、例えば30秒ごとや10秒ごとに取得する
複雑なシステムでは、数分、あるいは数秒の間にたくさんのことが起こる
負荷は大丈夫
モダンなサーバーやネットワーク機器は高性能なので、監視を増やしたことによるちょっとした負荷は大丈夫
保存はメトリクスに応じた適切なデータ間引きを
1.4 アンチパターン4: 監視を支えにする
監視とは、問題を通知することに長けているのであって、通知を受け取った次にするべきことである、問題の修正を忘るるなかれ。
注意を要するサービスを運用していて、そこに監視をどんどん追加している状態なのに気づいたら、サービス自体を安定して回復力のあるものにすることに時間を使いましょう。
監視を増やしても壊れたシステムがなおるわけではない
→ ほんとそのとおり
1.5 アンチパターン5: 手動設定
監視設定は100%自動化すべき
各サービスは、誰かが (手動で) 設定を追加するのではなく、勝手に登録されるようにしましょう
→ 勝手に登録というと...
Mackerel (のAWSインテグレーション) も、「新規メトリックの自動追加を設定」とか「自動退役を設定する」とか「(AWS側でリソースに付与した) タグで絞り込む」とかあるので、たぶんそういうことだな
Datadog も同様の機能があった覚え。
インテグレーション
ECS Fargate だけじゃなくて Mackerel 同様たくさんある
オートディスカバリー
ECS Fargate にエージェント入れてる → アプリのタスクにサイドカーコンテナとして入れてる、アプリコンテナと生死を共にしてる
死んだタスクは自動登録解除するし、生まれたタスクは自動登録されてる
→ ちなみに、自動化で連想したけど、サービス・リソースを監視対象に登録、というところじゃなく監視設定自体を Terraform (IaC) できる
Mackerelは画面ぽちぽちも直感的だったけど、IaC の良さみはそれでも言うに及ばず
冪等性、構成をコードという平面で見通せる・保持できる、履歴残せる、手順書不要、監視ルールやAlert設定のwiki不要 (顧客向けには必要かも)、適用前にコードでレビューできる...
Datadog はどうでしょう、Datadogのガイド、散乱してる印象あるので、IaC の方がかえってわかりやすかったりするんですかね
手順書依存
もし手順書が単なるやることのられるなら、さらなる自動化が必要
→ いろんなところで言われることですね、そうですね
手順書が参照しているアラートが単に手順を追っていけば解決できるものなら、その手順を自動化し、アラートを送る前に監視ツールがそれを実行してしまうことを検討しましょう。
→ おおよさそうー
何ができるかな...
そういえば、ECSなどの「Application Auto Scaling > ターゲット追跡スケーリングポリシー」とかまさにそれかも
1.6 まとめ
ツールに依存しても、監視の仕組みはよくなりません。
監視は全員がやるべき仕事であり、チームや部署内の役割ではありません。
素晴らしい監視とは、チェックボックスに「これは監視してます」とチェックを入れるだけで済むものではありません。
監視するだけでは壊れたものは直せません。
自動化が足りていないということは、何か重要なことを見落としている可能性を知るよい方法です。