はったりエンジニアの備忘録はったりエンジニアの備忘録アタマに浮かんだはてなを忘れないために。使っているところは前例にとらわれずゼロベースで見直そうとしています。ハイブリット構成になっています。いうところから考え直しています。自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。メトリクスを収集し、注意喚起レベルで通知する。メトリクスを収集し、警告レベルで通知する。エンジニアによる即座な対応を必要とし、夜間はオンコールするこの記事では、アプリケーションレイヤーについては触れません。いったマネージドサービスを前提としているため、コントロールプレーンの監視についても触れません。監視」がとても参考になりました。読んでいない人はぜひ。メトリクスは基本的に収集するだけです。メトリクスが重要ではないという意味ではなく、ユーザー視点により近いところで通知を設定するためです。クラスタではノードが増えることで自動的に解消します。ここで注目すべきは、メモリ使用率が上がっていることではなく、それによって例えばレスポンスタイムが悪化していないかどうかが重要です。メトリクスは、緊急の対応は不要ですが放置するとユーザーに影響が出かねないものです。自律システムでは復旧できないことが起きていて、エンジニアのフォローを必要とします。コンテナに関する通知の初動対応は、そのプロダクトのエンジニアが担当するイメージです(見てわかるとおり運用保守に近い)。メトリクスは、通知が届いたときには何かしらユーザーに影響が出始めている可能性があるものです。気付いた時点で即座に対応することが求められます。自律システムを安定稼働させられない状態や、どのコンポーネントかわからないけどユーザーに影響が出ている状態を通知します。集めたメトリクスが役に立つはずです。動いていない場合などもここで気付けるまとめこうやって洗い出してみると、これまでの監視と根本的に違うことがわかりました。自律システムが正しく動いているかどうかを監視するのが重要だと思います。乗り換えるつもりでいます。導入が完了したら、また書きたいと思います。