Console.app: ano ito, mga function at paano basahin ang mga log sa macOS

Ano ang Console.app

Console.app ay isang graphical na interface sa unified logging system ng Apple. Pinalitan nito ang lumang Console application (bilang bahagi ng macOS) at nagbibigay ng access sa lahat ng system at application log na naitala sa pamamagitan ng API na os_log, os_trace at syslog. Ang Console.app ay available sa /Applications/Utilities/ sa anumang Mac.

Hindi tulad ng Xcode, na nagpapakita lamang ng log para sa application na inilunsad mula sa IDE, ang Console.app ay nagpapakita ng mga log ng lahat ng proseso sa system nang sabay-sabay. Ito ay nagbibigay-daan sa pag-diagnose ng mga problema na nangyayari lamang kapag inilunsad ang application sa labas ng Xcode o sa background. Ipinapakita rin ng Console.app ang mga system log — kernel, launchd, WindowServer, na kapaki-pakinabang para sa debugging ng low-level na problema.

Console.app ay hindi nangangailangan ng pag-install ng karagdagang tool o koneksyon sa internet. Lahat ng data ay naka-imbak nang lokal sa .tracev3 database, at ang application ay gumagana nang ganap na offline. Para sa pagtingin ng log mula sa ibang Mac o iOS device, ginagamit ang command na log collect na sinusundan ng pagbubukas ng .logarchive sa Console.app.

Interface ng Console.app

Ang interface ng Console.app ay binubuo ng tatlong pangunahing lugar: side panel na may mga filter, table ng mensahe, at detail panel ng napiling mensahe. Ang side panel ay naglalaman ng mga seksyong Devices (available na log source), Reports (system report tungkol sa pag-crash), at Saved Searches (naka-save na query sa paghahanap).

Ang table ng mensahe ay nagpapakita ng listahan ng log na may mga column: Time (timestamp), Category (kategorya), Level (antas ng severity — color indication), Process (pangalan ng proseso), Message (teksto ng mensahe). Ang pag-click sa anumang mensahe ay nagbubukas ng detail panel, kung saan ipinapakita ang subsystem, activity identifier, thread ID at buong teksto na may formatting.

Console.app ay nagha-highlight ng mga mensahe na may kulay: pula para sa Fault, dilaw para sa Error, asul para sa Debug, kulay abo para sa Info. Ang mga Default na mensahe ay hindi naka-highlight. Ito ay nagbibigay-daan sa visual na pag-scan ng stream ng log at agarang pagtuklas ng mga kritikal na event.

// Mga log na lalabas sa Console.app
import OSLog

let logger = Logger(
    subsystem: "com.example.myapp",
    category: "network"
)

logger.error("Connection failed: timeout")
logger.debug("Retry attempt 3 of 5")

// Ang mga mensaheng ito ay makikita sa Console.app na may filter na “myapp”

Mga filter at paghahanap sa Console.app

Pag-filter — ang pangunahing function ng Console.app, na ginagawang isang nababasang listahan ang stream ng libu-libong mensahe bawat segundo. Ang field ng paghahanap sa itaas ay sumusuporta sa AND condition: maraming salita na pinaghihiwalay ng space ay nagpapakita lamang ng mga mensahe na naglalaman ng lahat ng salita. Halimbawa, myapp error ay magpapakita ng lahat ng log ng application na myapp na may antas na Error.

Filter ng Subsystem sa side panel ay nagpapahintulot na pumili ng isa o higit pang subsystem. Ito ang pinakamabilis na paraan upang ihiwalay ang log ng isang partikular na application mula sa mga system message. Filter ng Category ay available pagkatapos pumili ng subsystem — ipinapakita nito ang lahat ng kategorya na ginagamit ng napiling application. Filter ng Level ay naglilimita sa mga mensahe ayon sa antas ng severity: maaari lamang magpakita ng mga error o debug message.

Regular na expression sa paghahanap

Ang field ng paghahanap ng Console.app ay sumusuporta sa regex sa pamamagitan ng konstruksyon na REGEX:pattern. Halimbawa: REGEX:error.*tim(e|out) ay makakatagpo ng lahat ng mensahe na naglalaman ng “error” at salita na nagsisimula sa “tim” at nagtatapos sa “e” o “out”. Ang regex ay gumagana lamang sa field ng paghahanap, hindi sa filter ng subsystem o category.

Mga mode na Live at Historical

Live — ang real-time na mode, kung saan ang Console.app ay nagpapakita ng mga bagong mensahe habang lumilitaw ang mga ito sa circular buffer ng kernel. Ang mode na ito ay aktibo bilang default at angkop para sa debugging ng tumatakbong application: inilunsad mo ang application at makikita ang mga log nito na may pagkaantala na 1–5 segundo. Ang Live na button (o ⌘L) ay nag-o-on at nag-o-off ng stream.

Historical — ang mode ng pagtingin ng archive. Ang Console.app ay nag-iimbak ng lahat ng mensahe sa nakaraang 7–14 araw (na-configure sa system) sa .tracev3 database. Ang Historical mode ay nagbubukas ng archive na ito at nagpapahintulot ng paghahanap sa anumang filter, hindi lamang sa kasalukuyang stream. Ito ay kailangang-kailangan para sa pagsusuri ng mga problema na naganap sa gabi o kapag ang application ay gumagana nang walang koneksyon sa Mac.

Ang paglipat sa pagitan ng mga mode ay ginagawa sa pamamagitan ng Live na button sa toolbar. Kapag ang Live ay naka-off, ang Console.app ay nagpapakita ng historical na data. Sa mode na ito, maaaring mag-navigate sa timeline gamit ang kalendaryo o ← → na button. Ang Historical na data ay available lamang para sa mga log na na-save sa disk — ang mga mensahe na na-overwrite sa circular buffer ay hindi napupunta sa archive.

Pag-export at pagbabahagi ng log

Console.app ay sumusuporta sa pag-export ng na-filter na log sa maraming format. File → Export → Save ay pumipili ng format: .logarchive (native na format ng Apple, kasama ang lahat ng metadata), .txt (plain text na may column) at .json (structured data na may field). Para sa pag-attach sa bug report gamitin ang .logarchive — maaari itong buksan sa anumang Mac sa Console.app.

Pag-export mula sa iOS device: sa pamamagitan ng Xcode (Devices → Open Console) o sa pamamagitan ng command na log collect --device --output ./archive.logarchive sa terminal. Ang nakuha na .logarchive ay buksan sa Console.app sa Mac — ang mga log ay mula sa remote device, ngunit ang mga filter at paghahanap ay gumagana tulad ng sa lokal na log.

// Pag-export ng log ng iOS device sa pamamagitan ng terminal
// log collect --device --output ./ios_crash.logarchive
// log show --subsystem com.example.app --last 1h --output json

// Halimbawa: pag-export ng log mula sa nakaraang oras
// log show --predicate 'subsystem == "com.example.myapp"' \
//   --info --debug --last 1h --output json > logs.json

// Pag-parse ng na-export na log sa Swift
let jsonData = try Data(contentsOf: URL(fileURLWithPath: "logs.json"))
let decoded = try JSONDecoder()
    .decode([LogEntry].self, from: jsonData)

Pagbabahagi ng log

.logarchive — ang optimal na format para sa pagpapadala sa kasamahan o pag-attach sa JIRA ticket. Ang file ay naglalaman hindi lamang ng mga mensahe, kundi pati na rin ng subsystem, category, timestamps, thread IDs at lahat ng metadata. Ang laki ng archive ay makabuluhang mas maliit kaysa sa raw log dahil sa .tracev3 compression. Bago ipadala siguraduhin na ang mga log ay walang pribadong data: gamitin ang filter ng subsystem ng iyong application upang ibukod ang system log na maaaring maglaman ng kumpidensyal na impormasyon ng iba pang proseso.

Mga praktikal na halimbawa ng debugging sa pamamagitan ng Console.app

Diagnosis ng crash nang walang Xcode: kung ang application ay nag-crash kapag inilunsad sa labas ng Xcode, ang Console.app ay magpapakita ng Fault na mensahe mula sa proseso. Hanapin sa side panel ang Reports → Crash Reports — doon ay ipinapakita ang kumpletong crash report na may signature at stack. Gamitin ang filter ng subsystem para sa iyong application at itakda ang antas na Error+Fault upang makita ang lahat ng kritikal na event bago ang crash.

Pagsusuri ng performance sa pamamagitan ng Console.app

Ang Console.app ay nagpapahintulot ng pagsubaybay ng pagkaantala sa application batay sa timestamp. Kung sa pagitan ng dalawang kaugnay na mensahe (halimbawa, “Natapos na ang kahilingan” at “Natanggap ang tugon”) ay lumipas ang mas maraming oras kaysa sa inaasahan — ito ay senyales ng problema sa performance. Ang filter sa subsystem ng iyong application na may antas na Default ay magpapakita ng lahat ng pangunahing event na may precision ng millisecond.

Paghahanap ng memory leak: sa memory leak, ang system ay nagpapadala ng memory warning sa pamamagitan ng os_log na may kategoryang memory at antas na Error. Sa Console.app i-filter ayon sa salitang memory at piliin ang iyong subsystem. Kung ang warning ay umuulit tuwing 5–10 segundo — ang application ay aktibong kumokonsumo ng memory. Dagdag pa, maaaring i-on ang Debug log para sa pagsubaybay ng allocasyon.

Debugging ng network request: kung ang iyong application ay gumagamit ng os_log para sa network event, ang Console.app ay magpapakita ng lahat ng request at response na may timing. Ang filter na category=network ay nagbabawas ng ingay. Kung ang oras sa pagitan ng request at response ay lumampas sa inaasahan, hanapin ang mga mensahe na may level=Error — sila ay magsasaad ng timeout o DNS error.

// Structure para sa pag-parse ng JSON log ng Console.app
struct LogEntry: Codable {
    let timestamp: String
    let eventMessage: String
    let subsystem: String
    let category: String
    let messageType: UInt8

    var level: String {
        switch messageType {
        case 1: return "Fault"
        case 16: return "Error"
        case 17: return "Debug"
        default: return "Default"
        }
    }
}