介紹
有一天，我在開發過程中查看雲端環境（在 Cloud Logging 上）的日誌時，
我覺得日誌很混亂，很難閱讀。
我以為我要做的就是將日誌輸出為文本，但我的經驗已經有了很大的提高，我希望我早點知道它，所以我想寫一篇關於它的文章。
前提
使用言語: Typescript
雲端環境：Google Cloud（Cloud Run + Cloud Logging）
（假設它已經部署到雲端環境（例如，Cloud Run）並且與 Cloud Logging 的連線已經完成。）
使除錯更容易的有用專案
1. 結構化日誌
使日誌在雲端環境中更易於查看和除錯
採用「結構化日誌記錄」 。
結構化日誌簡單解釋為
將日誌資訊輸出為JSON格式等結構化資料，而不是簡單的字串
這使得搜尋和過濾日誌變得更加容易。
輸出日誌時，不再輸出ユーザーがログインしました，而是以如下所示的JSON格式輸出。
{
"message": "ユーザーがログインしました",
"severity": "INFO",
"userId": "user-123",
"timestamp": "2025-08-20T12:00:00Z",
"requestId": "_QBNoVwge8AxqlwBI-yWm"
}2. 請求ID的採用
第二個有用的專案是將名為「requestId」的參數作為元資料新增至結構化日誌。
透過新增“requestId”，
透過為每個 HTTP 請求指派一個唯一的 ID（請求 ID） ，您可以在一個地方追蹤與該請求相關的所有日誌。
引入的好處
1. 記錄的一致性
如果每個開發人員在編寫console.log時都沒有任何特定的規則，
console.log('ユーザーがログインしました');
console.log(`User ID: ${userId} logged in.`);
console.log(`Login event occurred at ${timestamp}, user ID: ${userId}`);喜歡，
日誌格式往往會改變並且變得不一致...
在這種情況下，稍後分析日誌或搜尋特定資訊將變得極為耗時。
但是，如果建立用於日誌記錄的包裝函數，則可以統一通過該函數輸出所有日誌，這將防止每個開發人員以自己的格式編寫 console.log，並在整個應用程式中建立日誌的一致性。
此外，透過檢查此包裝函數內的環境變數，可以自動在開發環境和雲端環境之間切換日誌輸出格式，從而允許您控制每個環境的適當日誌輸出！
// コード例
type LogLevel = 'info' | 'warn' | 'error';
interface StructuredLog {
message: string;
level: LogLevel;
timestamp: string;
requestId: string;
[key: string]: any;
}
const isProduction = process.env.NODE_ENV === 'production';
export const logger = (message: string, level: LogLevel = 'info', data: object = {}): void => {
const timestamp = new Date().toISOString();
if (isProduction) {
// クラウド環境（本番環境）では構造化ログを出力
const logPayload: StructuredLog = {
message,
level,
timestamp,
...data,
};
console.log(JSON.stringify(logPayload));
} else {
// 開発環境では読みやすいフォーマットで出力
const formattedData = Object.keys(data).length > 0 ? ` - ${JSON.stringify(data)}` : '';
console.log(`[${level.toUpperCase()}] ${message}${formattedData}`);
}
};在 Cloud Logging 中顯示
僅 Console.log（上），結構化日誌記錄（下）
2. 您可以透過 requestId 追蹤日誌
透過將 requestId 新增至結構化日誌的元資料中，
現在您可以在一個地方追蹤與單一請求相關的所有日誌。
在涉及多個微服務和非同步進程的複雜系統中，可能很難了解特定使用者操作（例如下訂單）經過了哪些服務、按照什麼順序以及在哪裡發生錯誤。
透過在日誌中包含 requestId，您可以使用該 ID 按時間順序找到所有相關日誌，以幫助您快速辨識問題的根本原因並找到解決方案。
日誌像這樣以列表形式輸出，因此很難找到哪些日誌與其他日誌是在同一個進程中產生的。
在這種情況下，如果您點擊日誌中的“requestId”並按“顯示符合條目”，則只會顯示相同請求的日誌，從而更容易查看。
*如果中間件提供了“x-request-id”，則使用該id產生“requestId”；如果沒有，則使用nanoid()產生“requestId”，以使其唯一。
3. 更輕鬆地在 Cloud Logging 中進行過濾
與之前使用「requestId」一樣，Cloud Logging 可讓您最大限度地發揮結構化日誌記錄的優勢。
這篇文章有詳細的解釋，而且通俗易懂，大家可以看一下。
在日誌中包含某些元資料可以使偵錯變得更加容易！
例如，，，
如果包含元資料“severity”並將其值設為“WARNING”，
如圖所示，左側的“重要性”將是一個警告圖標，
一眼就能看出發生了視覺錯誤。
另外，顯示“ERROR”時標記會變成紅色，並且可以根據錯誤等級進行更改！ ！
▼ 参考資料
此外，使用結構化日誌記錄可讓您對每個 JSON 元資料使用篩選器，這有助於加快偵錯速度並分析最常發生的錯誤類型...！
結論
我認為本文的內容只是讓除錯更容易的方法之一，
僅此一點就使除錯變得容易多了！ ！
當執行應用程式時，必然會出現錯誤。
我認為，為了盡快找出原因，易於除錯非常重要，所以我想從這個角度繼續開發！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式