Pag-log at pag-monitor sa mobile development: esensya, anong mga tool, at kung paano i-set up

Pag-log at pag-monitor sa iOS: os_log at CocoaLumberjack

Ang pag-log ng mobile application sa iOS ay binuo sa os_log — ang built-in na sistema ng Apple, na available mula noong iOS 10. Ang os_log ay nagsusulat ng mga log sa iisang system log (on-device o sa pamamagitan ng Console.app), sumusuporta sa mga kategorya, antas, at privacy tag. Ang kumbinasyon ng pag-log at pag-monitor sa iOS sa pamamagitan ng Console.app at xcrun ay nagbibigay-daan sa pagsubaybay ng mga error at performance sa real-time.

Log Level sa iOS

Ang os_log ay may mga antas: Default, Info, Debug, Error, Fault. Sa produksyon, pinapanatili ang Error at Fault — ang Debug at Info ay hindi pinagana. Ang pagpili ng tamang antas ay bahagi ng estratehiya ng pag-monitor ng mobile application sa iOS. Privacy: %{public}@ para sa hindi protektadong data, %{private}@ para sa personal na data.

CocoaLumberjack

CocoaLumberjack ay isang popular na library para sa iOS logging. Hindi tulad ng os_log, sinusuportahan nito ang custom na format, asynchronous na pagsulat, at log rotation. DDLog, DDTTYLogger (console), DDFileLogger (file na may rotation). Para sa remote monitoring, ang CocoaLumberjack ay maaaring isama sa os_log — sumulat sa isang file para sa remote logging at sa os_log para sa Console.app.

Pag-log at pag-monitor sa Android: Timber at Log Level

Para sa pag-log ng mobile application sa Android, ginagamit ang Timber — isang library ni Jake Wharton na naging pamantayan ng platform. Ang Timber ay isang wrapper sa Android Log (Logcat) na awtomatikong nagdaragdag ng class tag at nagko-configure ng Tree. Ang Timber ay bahagi ng sistema ng pag-monitor ng mobile application ng Android: DebugTree para sa debugging, CrashlyticsTree para sa pagpapadala ng data.

Timber nang detalyado

Ang Timber ay gumagamit ng Tree — isang bahagi na nagpapasya kung ano ang gagawin sa log. Sa debug builds, DebugTree (output sa Logcat), sa release — CrashlyticsTree (pagpapadala ng crashes). Timber.wtf() ay nagla-log ng mga fatal error. Timber.tag("CustomTag") ay nag-o-override ng tag. Para sa epektibong pag-monitor, ang Timber ay isinasama sa mga tool ng APM.

Log Level sa Android

Android Log ay may mga antas: VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT. Tinatanggal ng ProGuard/R8 ang Log.d at Log.v sa release — pinapayagan ng Timber ang pag-log sa pamamagitan ng Plant. Ang pagpili ng antas ay nakakaapekto sa kalidad ng pag-monitor ng mobile application — sa produksyon, pinapanatili ang WARN at ERROR.

Kapag pumipili ng tool sa pag-log, isaalang-alang: kailangan mo ba ng remote logging, gaano kadalas nagbabago ang mga log, at sino ang susuri sa kanila. Para sa mga startup, sapat na ang os_log o Timber. Para sa enterprise — CocoaLumberjack na may pagpapadala sa server. Sa IT Sectr, ginagamit namin ang kombinasyong Timber + Crashlytics para sa Android at os_log + CocoaLumberjack para sa iOS.

Structured Logging

Structured logging — pagsulat ng mga log sa JSON format sa halip na plain text. Halimbawa: sa halip na "User login failed" sumusulat kami ng {"event": "login_failed", "user_id": 123, "reason": "invalid_password"}. Ito ang pundasyon para sa awtomatikong pag-monitor — ang ELK stack at Grafana ay nag-filter, nag-aggrega, at nagsusuri ng naturang data.

Mga benepisyo ng structured logging

Pag-filter ayon sa field: hanapin ang lahat ng log na may event=crash sa nakaraang oras. Pag-aggrega: bumuo ng graph ng bilang ng mga error ayon sa bersyon ng application. Pagsasama sa ELK (Elasticsearch, Logstash, Kibana) o Grafana. Hindi sapilitan ang structured logging para sa mga unang release, ngunit nagiging kritikal kapag lumampas ang DAU sa 10,000.

Remote Logging at Log Rotation

Remote logging — pagpapadala ng mga log mula sa device patungo sa server para sa sentralisadong pag-monitor. Ipinapatupad sa pamamagitan ng custom Tree (Android) o HTTP requests. Ipadala lamang ang Error at Warning — huwag sayangin ang trapiko ng gumagamit. Log rotation: DDFileLogger (iOS) bawat 1 MB o 1 araw. Sa Android, limitado ang Logcat buffer.

APM at pag-monitor ng mobile application: Sentry, New Relic, Datadog

Application Performance Monitoring (APM) — isang klase ng mga tool para sa pag-monitor ng mobile application. Sinusukat ng APM: oras ng pagsisimula, mga kahilingan sa network, FPS, paggamit ng memorya, dalas ng crash. Mga pangunahing manlalaro: Sentry (Performance), New Relic Mobile, Datadog Mobile.

Sentry Performance

Sentry — hindi lamang pag-uulat ng crash, kundi pati na rin pag-monitor ng performance. Ang Sentry Performance ay lumilikha ng distributed traces na nagpapakita kung gaano katagal ang bawat yugto: mula sa pagpindot ng button hanggang sa tugon ng server. Sinusuportahan ang iOS, Android, Flutter, React Native. Libre hanggang 5k event bawat buwan.

New Relic at Datadog

New Relic Mobile ay nagbibigay ng metrics: bilang ng session, oras sa app, dalas ng crash, mga kahilingan sa network. Datadog Mobile ay isang mas modernong tool na may real-time dashboard at alerto. Parehong bayad, ngunit may libreng tiers. Inirerekomenda ng IT Sectr na magsimula sa Firebase Performance at lumipat sa bayad na APM kapag lumampas ang DAU sa 100,000.

Firebase Performance

Firebase Performance — isang libreng tool para sa pag-monitor ng mobile application mula sa Google. Awtomatikong nangongolekta ng metrics: oras ng pagsisimula ng app, mga HTTP request (URL, paraan, code ng tugon), FPS. Para sa custom na pagsubaybay, gamitin ang Trace API. Pagsasama: idagdag ang SDK sa build.gradle (Android) o Podfile (iOS).

Trace at metrics

Trace — isang segment ng oras na may simula at wakas na iyong sinusukat. Halimbawa: trace = FirebasePerformance.getInstance().newTrace("checkout_process"). Metrics — mga numerikong tagapagpahiwatig (laki ng tugon, bilang ng item). Ang Firebase Performance ay hindi nangangailangan ng server infrastructure — lahat ng data ay dumadaan sa Firebase SDK. Kapag nagmo-monitor ng mobile application, ang Trace API ay nagbibigay ng konteksto para sa pagsusuri ng performance.