07:00: 一日の始まり
ノートパソコンを開き、一杯目のコーヒーをすすりながら、自分のケースに目を通す。私のバックログのほとんどは、顧客のアップデートやバグフィックスを待っている。2つのケースはクローズすることになった。月曜日にしては上々の滑り出しだ。
PodのCrashLoopBackoff 問題は、メモリ要求を上げることで解決し、メトリクス欠損の問題は、お客様のnginx PodにPrometheusアノテーションをいくつか適用することで解決した。両方のケースを記録してクローズする。
バッジスキャナーの「ピッ」という音が聞こえてくるやいなや。オフィスには続々と人が集まってくる。顧客をサポートする同僚たちのおしゃべり、新しい見込み客と話すセールスエンジニア、そして新しい取引が決まったときのゴングの音で、すぐににぎやかになるだろう。
09:35：システム内のアラート
あるケースがキューに入った。そのお客様は、遅いSQLクエリに対してアラートを受け取っていると報告している。アラートはすべてのクエリに対して発動しているわけではなく、ごく一部のクエリに対して発動している。
お客様からは、これらのクエリーはマイクロ秒単位で完了しているように見えている。しかし、Sysdigでは完了までに3秒以上かかっていると報告されている。
彼らのアラートの設定を確認してみる。
「オッケー、これはかなりわかりやすい」と思う。
msp ネームスペースで net.sql.request.time.worst という指標が3.8秒以上になると、アラートを発し、アラートをクエリとサービス名でセグメント化している。私は顧客に実行しているクエリを提供してもらえるように依頼した。彼らはクエリ名と、いくつかの追加情報を提供してくれた。
“この2つ目のクエリは0.04秒で完了しています。なぜ連続したアラートが発生するのでしょうか？どのような支援でもありがたいです”
私はキャプチャを確認し、問題のクエリが一貫して3.8秒のしきい値を超えて報告されていることを発見した。クエリ時間の測定方法は、ユーザースペースからクエリが実行されたときにタイマーをスタートさせ、カーネルがユーザースペースに結果を返したときにタイマーをストップさせるものだと、顧客に説明した。
お客様が説明を続ける。
“ログによると、アプリケーションは2022-03-05T11:41:00.000にデータベースにリクエストを送信し、2022-03-05T11:41:00.298000+0100にレスポンスを受け取っていて、ここで遅延がないことを意味しています。クエリーはネットワークの問題もなく高速で、クエリーの実行時間は0.003000秒です”
10:15：謎は深まる
これらのクエリーが本当にどれくらい時間がかかっているのかを理解するには、もっとデータが必要だ。
私はお客様にSysdigのキャプチャを集めるようお願いした。このキャプチャには、マシンで何が起きているのか、知りたいことがすべて含まれている。システムコール、プロセス、CPU時間…すべて。Sysdigの信条は、「システムコールは嘘をつかない」だ。
顧客からキャプチャファイルが送られてきたので、それをSysdig Inspect にロードした。SQLサーバーは最初のレスポンスの完了時間を測定しているが、クエリの完全なペイロードは4秒後に返されていることが判明した。
次のキャプチャーのスクリーンショットは、ポート3306で問題のホスト間でフィルタリングされたトラフィックを示している。
このクエリーは1分ごとに実行され、16時41分00秒に開始され、16時41分04秒に終了している。このことをお客様に説明したところ、よく理解していただけた。
ケースクローズ！ナレッジベースの記事を書き、同僚がこのワークフローに従って将来の顧客に対応できるようにした。
13:00: あなたは「go」と言い、Sysdigは「stop」と言う!
昼食から戻ると、また面白いケースがあり、引き受けることにした。ある顧客が、ある環境でgolangが使われるのを止めようとしている。それは、Falco Rulesで簡単に達成できるはずだ。テストするために、私はVMを起動し、Sysdigエージェントをインストールし、それをバックエンドに接続した。
Sysdig Secureで、新しいプロセスルールを作成する。
ルールは簡単だ。プロセス名が “go “に一致する場合、そのプロセスを終了させる。
そのルールを新しいポリシーにインポートする。
これで、私の環境のどこであってもgoプロセスが終了するだけでなく、そのイベントのキャプチャを取得できるようになった。これにより、どのユーザーがどこでそのプロセスを実行したかといった有用な情報を得ることができる。
エージェントが動作している私のVMから、dockerコンテナ内にgolangをインストールした。ポリシーをテストするために、goコンテナでシェルを起動し、”go version “を実行した。予想通り、私のターミナルはすぐに停止した。この結果に満足し、私はこの情報を顧客に転送した。
Sysdigは素晴らしいアプリケーションだ。私は、お客様が目標を達成するためにSysdigを使用するのを支援したり、お客様がSysdigについてまだ知らないことを説明するのが大好きだ。Sysdigはまさに、セキュリティと可観測性の両方を実現する「スイスアーミーナイフ」だ。
これらは、お客様から寄せられる質問のほんの一部です。私たちカスタマー・リライアビリティー・エンジニアリングチームは、このような質問を受けると、とても嬉しくなります。
Sysdigは、私たちに「より深く掘り下げる(dig deeper)」力を与えてくれます!