LogStitch

これがアプリの核だ。どのプラットフォーム行にも request ID が付くので、LogStitch は INIT_START、START、END、REPORT を 1 つの呼び出し境界にまとめ、自分のログ行をその時点で開いていた実行に割り当てられる。結果として、15 行の乱れたログが、筋道を立てて考えられる 1 つの呼び出しになる。ローカルで動き、ミリ秒で終わる。

1 つのリクエストが 1 つの関数に留まることはまれだ。LogStitch は 1 つのリクエストを触れたすべての Lambda にわたって追い、ホップを泳レーンとして並べ、その間の伝播遅延を示す。request ID か、すでに出力している相関ヘッダーで検索できるので、恩恵を受けるためにログの出し方を変える必要はない。

アプリは別のツールへ追いやるのではなく、自前のダッシュボードを備える。p99 所要時間の推移、コールドスタートの散布、メモリの適正化、コスト予測が 1 か所で見られる。サードパーティの設定は要らない。メモリの画面は余裕だけでなくメモリと所要時間の曲線を使うので、より役立つ適正化の数字が出やすい。

エラーのパターンは自動でクラスタ化され、所要時間、エラー、コールドスタート、コストの統計的な異常がひとりでに浮かぶ。これが最も効くのは障害の最中、まだ何を探しているか分からないときだ。手作業の grep が減り、信号が増える。どのチームにも理想的とは言えないが、噛み合えば本当に時間を節約する。

組み込みの MCP サーバー（Model Context Protocol）が、同じ Mac で動く AI アシスタントに保存済みの呼び出しを公開する。127.0.0.1 にのみバインドし、すでにディスク上にあるログデータから答えるので、アシスタントが AWS の認証情報を受け取ることも AWS と通信することもない。ループバックのみだ。呼び出し、エラー、パターン、性能、コスト、全文検索をカバーする 21 個のツールを公開する。

ログはあなたの AWS アカウントから Mac へ直接取り込み、認証情報は macOS のキーチェーンに留まり、LogStitch 自身だけが使う。ベンダーを経由するものは何もなく、アプリは完全なローカル履歴に対してオフラインで動く。厳しいデータ規則を持つチームには重要だ。ログデータがネットワークを出ることが障害になるなら、この設計こそ検討する理由になる。