Reading 50MB JSONL logs with a viewer in 2026

Reading 50MB JSONL logs with a viewer in 2026

使用基於瀏覽器的 JSONL 查看器，將每一行解析為獨立的 JSON 物件，並以可篩選、可排序的表格呈現結果。這是閱讀以換行符號分隔的日誌最快的方法，無需撰寫一次性腳本。貼上檔案即可取得欄位、篩選所需列，並匯出剩餘資料。無需在終端機中操作，也不會因 2GB 檔案而使編輯器當機。所有運算都在客戶端執行，因此可離線使用。

下方連結的 jsonl 查看器是我自行開發的。我厭倦了這件事：去年春天我試過六種不同的線上 JSON 工具，但只要我貼上以換行符號分隔的資料，它們就全部當機，因為它們都假設單一 JSON 文件，而 JSONL 是 JSON 文件的串流。我的工具完全在瀏覽器中執行。無需註冊、無需上傳，任何資料都不會離開您的機器，而且免費。如果您有更好的工具，歡迎告訴我。

讓我的文字編輯器當機的日誌檔

上週二凌晨 2 點左右，我正在追蹤一個生產環境的逾時問題。我手上唯一的證據是服務串流到磁碟的 NDJSON 日誌：340 MB 大約 120 萬行，每一行都是一個 JSON 物件。我先做了最明顯的事——用編輯器開啟它。它思考了一段時間，風扇開始轉動，然後視窗變白停止回應。太好了。

於是我改用 jq。jq 'select(.level == "error")' app.log 的確有效，而且老實說 jq 是一個很棒的工具，但我記不住確切的欄位名稱，不斷把篩選條件弄錯，而每次猜錯都會重新從頭串流整個檔案。20 分鐘後我還沒看到任何一行。錯誤實際上發生在第 811,406 行，但我當時還不知道。我只想先看到資料的樣貌，再決定要篩選什麼。這就是問題所在。

JSONL（也稱為 NDJSON 或 JSON Lines，不同名稱但概念相同）是一連串的 JSON 值，每行一個。日誌管線喜歡這種格式，因為您可以附加一行而無需重寫檔案，而寫入中斷只會損失最後一行，而非整個文件。問題是大多數 JSON 工具都假設單一文件，因此讀取您的 120 萬行後，會在第二個 { 立即拋出錯誤。

JSONL 查看器如何解析物件串流

JSONL 查看器的核心其實小得驚人。您只需依換行符號分割，然後分別解析每一行非空白的內容。真正重要的技巧是不要讓單一錯誤的行毀掉整個渲染，因此您需要捕捉每行的錯誤並繼續執行。

// Split, drop blanks, parse each line independently.
function parseJSONL(text) {
  return text
    .split('\n')
    .filter((line) => line.trim() !== '')
    .map((line, i) => {
      try {
        return { ok: true, row: JSON.parse(line) };
      } catch (err) {
        return { ok: false, line: i + 1, raw: line, error: err.message };
      }
    });
}

const sample = `{"ts":"2026-04-11T02:14:03Z","level":"error","msg":"timeout","ms":9812}
{"ts":"2026-04-11T02:14:04Z","level":"info","msg":"retry","attempt":2}
not valid json
{"ts":"2026-04-11T02:14:06Z","level":"info","msg":"ok"}`;

console.log(parseJSONL(sample));

Enter fullscreen mode Exit fullscreen mode

執行後您會得到四個結果。三個成功解析為列物件，而 not valid json 那一行會回傳 { ok: false, line: 3, ... }，而不是讓其他三個也跟著失敗。查看器會取得這個陣列，聯集所有看到的鍵來建立欄位（ts、level、msg、ms、attempt），然後繪製表格。現在 level 成為您可以篩選的欄位，而非必須用 grep 搜尋的字串。

您不需要自己執行這些步驟。只要將檔案貼到 JSONL viewer，它就會在您的瀏覽器中執行這些操作，然後給您一個可排序、可篩選的表格，並以紅色標記損壞的行，讓您能發現損壞而非默默捨棄。這種紅色標記功能是我最常用的，說來奇怪。我一半的「錯誤」報告結果證明只是被截斷的日誌行。

表格實際能為您做什麼

解析只是無聊的一半。表格優於一堵文字牆的原因在於您能對其執行哪些操作。我幾乎總是先進行篩選。在 level 欄位輸入 error，120 萬列就會收縮為 3,000 個相關的列。然後我依時間戳排序來找出第一個，因為第一個錯誤通常是真正的原因，其餘則是後續影響。

對數值欄位排序（例如以毫秒為單位的持續時間）是表格展現價值的時刻。在編輯器中我必須手動查看數字。在這裡，我點擊 ms 標題，最慢的請求就會浮到最上方。上週這找出了一個我從未注意到、單一的 14,203 毫秒異常值，而這正是整個問題的根源。

匯出功能完成了整個流程。一旦我篩選出關心的列，我就可以將它們匯出為 JSON 或 CSV，並將這部分資料放入工單，讓接手的人看到 40 行相關的內容，而不是 340 MB 的檔案和聳肩。

jq 與試算表及文字編輯器的比較

每種工具都有其用武之地。以下是我實際選擇它們的方式：

當我在探索且尚未知道要找什麼時，查看器是贏家。當我知道確切查詢且想要將它放入腳本或管線時，jq 是贏家。我在 CI 中使用 jq，而在凌晨 2 點大腦半離線時使用查看器。不同的工作，我不再對同時使用兩者感到內疚。

何時不應使用它

我建立了這個工具，但我仍不會用它做所有事。有幾個誠實的限制。

如果您的檔案真的很大（數 GB），請繼續使用 jq 或串流解析器。瀏覽器分頁有記憶體上限，而將 3 GB 載入表格會讓頁面當機，就像它讓我的編輯器當機一樣。查看器適用於編輯器吃力但資料仍能放入 RAM 的範圍，所以大約是數百 MB 以下。

如果任務是自動化的，使用查看器完全是錯誤的選擇。任何依排程或在建置中執行的東西都應該使用 jq 或小型腳本。人類點擊網頁不屬於 cron 工作，如果您試圖這麼做，您會討厭維護它。

如果您處理的是深度巢狀物件，扁平表格很快就會變得笨拙。查看器會盡可能展平，並將巢狀區塊顯示為收合的 JSON，這是可讀的但並非魔法。對於大量巢狀結構，我仍然會回到 jq 的路徑表達式。沒有任何工具能贏得每一回合，而假裝相反只會讓您在凌晨 2 點開啟錯誤的工具。

常見問題

Q: JSONL 和 NDJSON 是同一件事嗎？
A: 實際上是的。JSONL、NDJSON 和 JSON Lines 都指同一種格式：每行一個 JSON 值，以 \n 分隔。關於尾端換行符號和空行有一些學究式的邊緣情況，但任何像樣的查看器都會以相同方式處理這三個名稱。

Q: 我的資料會上傳到任何地方嗎？
A: 不會。解析在您的瀏覽器中於客戶端執行，因此檔案永遠不會離開您的機器。這正是我以這種方式建立它的原因。我不想將生產日誌貼到別人的伺服器上，然後期待最好的結果。

Q: 它實際上能處理多大的檔案？
A: 這取決於您的可用 RAM 比其他任何事情都重要。我在一般筆記型電腦上測試過 90 MB 的檔案而沒有問題。超過數百 MB 您會感覺分頁變得沉重，這就是您應該切換到 jq 的信號。

Q: 我可以匯出已篩選的列嗎？
A: 可以。一旦您縮小到想要的列，您就可以將可見的集合匯出為 JSON 或 CSV，這對於將乾淨的切片交給同事，而不是原始的傾印檔案很有幫助。

Q: 為什麼不直接對所有事情都使用 jq？
A: 您可以，而且很多人都是這麼做的。我喜歡用 jq 處理已知的查詢和管線。查看器是用於更混亂的時刻，在此之前我還不知道欄位名稱或我在找什麼，只是想用眼睛戳戳資料。

Written with AI assistance and human review. Try the tool at aidevhub.io/jsonl-viewer.