はじめに
日付：2026年7月23日（木）/ 74日目
本番環境でのpsql作業中にトークン切れというトラブルが発生。
落ち着いて対処できた。
また、監視リンクの全体像を整理し、
運用の流れが頭の中でつながってきた充実した一日。
本番環境でのpsql作業：認証トークン切れ対応
発生した問題
指定ディレクトリに移動してpsqlを実行しようとした際、
突然セッションが切断された。
確認したところ、認証トークンが予想より早く切れていたことが原因だった。
| 環境 | トークン有効期間 |
|---|---|
| 検証（テスト）環境 | 比較的長め |
| 本番環境 | セキュリティ上、より短く設定されている |
対応手順
# 1. セッション切断を確認
# 2. 再ログインしてトークンを再発行
PGPASSWORD=$(gcloud auth print-access-token) psql \
"host=[ホスト名] port=[ポート番号] user=[USERNAME] dbname=[DB名] sslmode=require"
# 3. 作業を再開
手順書への改善提案
今後同じ状況が繰り返される可能性があるため、
手順書に「トークン再発行」のステップを
明示的に追加する必要があると判断した。
本番環境は検証環境と設定が異なる。
「知っている」と「慣れている」は別物だと改めて実感した。
当惑したが、事前に対処方法を学んでいたため落ち着いて対応できた。
監視リンク整理：障害対応の流れを把握
監視業務で使用する各リンクと使い方を整理した。
障害対応の基本フロー
① All Application Dashboard
→ 全体スキャン（Alert数・Monitor状態・Pod状態）
↓
② Log monitoring（Error Outlier）
→ 問題のあるPod/Nodeを特定
↓
③ Argo CD
→ 最近のデプロイ時刻と障害時刻が重なるか確認
↓
④ AlloyDB / Valkey Dashboard
→ DB・キャッシュ側の原因を排除
↓
⑤ Batch hosts / Log monitoring
→ バッチ処理の問題であればここで確認
主要ダッシュボードの役割
| ダッシュボード | 主な用途 |
|---|---|
| All Application Dashboard | 全体の状態を一目で把握。Alert数・Pod状態・エラーログを確認 |
| AlloyDB Dashboard | DBのCPU・接続数・Deadlock・クエリ遅延を確認 |
| Log monitoring（Web） | エラー発生サービス・Pod・Nodeを特定する |
| Pod Metrics | CPU/メモリのリソース使用率・再起動回数を確認 |
| Argo CD | 最近のデプロイが障害に関係していないか確認 |
| Batch Log monitoring | バッチジョブ別にエラー・Warning件数を確認 |
| GCE | VMインスタンスの存在確認・内部IP確認 |
各レイヤーのログ監視ポイント
| レイヤー | 確認内容 |
|---|---|
| Istio Mesh | サービス間の通信・応答コード（4xx/5xx）分布 |
| Tomcat/App | アプリケーションのエラーログ・スタックトレース |
| Nginx | 外部からのアクセスログ・レスポンスタイム |
AlloyDB確認ポイント
| 指標 | 確認内容 |
|---|---|
| CPU使用率 | 高負荷になっていないか |
| 接続数 | 接続プールが上限に近づいていないか |
| Deadlock数 | デッドロックが頻発していないか |
| Buffer Cache Hit Ratio | 95%を下回ると要注意 |
感想
本番環境でトークンが予想より早く切れるというトラブルに直面した。
一瞬焦ったが、事前に対処方法を身につけていたおかげで
落ち着いてすぐに対応できた。
「備えがあれば本番でも動じない」
この経験がまた一つ自信になった。
監視リンクを整理していく中で、
「障害が起きたらここを見る」という流れが
頭の中でつながってきた。
まだ完全に体に染み込んでいるわけではないが、
「この知識と経験があればどこでも通用するんじゃないか」
という手応えを感じるほど成長を実感できた一日だった。
まだまだ学ぶことはたくさんあるが、
今の仕事が楽しい。それが一番大切なことだと思う。