Platform အမျိုးအစားမတူညီစွာ Observability

နားလည်ထားရမယ့် အချက်

Cloud & Deployment ရဲ့ monitoring, logging, observability lesson သည် metrics, logs, traces နှင့် ဘာကြောင့် သုံးမျိုးလုံးလိုအပ်သလဲဆိုတဲ့ fundamental များကို ဖော်ပြပြီးဖြစ်သည်။ ထို lesson မဖော်ပြခဲ့သည်မှာ သင့်ရဲ့ default observability depth သည် ဘယ် platform အမျိုးအစားအပေါ် run နေသလဲအပေါ် လေးနက်စွာ မူတည်နေခြင်းနှင့် platform တစ်ခု ရွေးချယ်ခြင်းသည် box ထဲက ဘာမြင်ရမလဲ vs ကိုယ်တိုင် ဘာထပ်ထည့်ရမလဲကို တိတ်တိတ်ဆိတ်ဆိတ် ရွေးချယ်ခြင်းနှင့်တူသည်။

OBSERVABILITY DEFAULTS BY PLATFORM TYPE
---------------------------------------
MAJOR CLOUD
  depth:  deep, highly configurable (metrics/tracing/logs)
  effort: high -- almost nothing works until you set it up

PaaS-STYLE (Vercel / Railway / Render kind)
  depth:  simple built-in logs + basic metrics
  effort: low -- works immediately, but has a low ceiling

BaaS
  depth:  strong for its own pieces (auth, DB, storage)
  effort: partial -- your own custom logic stays mostly dark
          unless you wire up logging inside it yourself

No platform type is "more observable" in general --
each trades setup effort against depth differently.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

PaaS-style platform ပေါ်တွင် SaaS product သေးငယ်တစ်ခု run နေတယ်ဆိုပါစို့။ Box ထဲကတည်းက request log, basic error rate, simple metric ရရှိသည် — 'traffic ကျဆင်းသွားတယ်' (သို့) 'error spike ဖြစ်တယ်' ဆိုတာ သတိပြုမိလောက်သော်လည်း internal function call ငါးခုကို ဖြတ်သန်းနေသော request နှေးကွက်တစ်ခုကို trace လုပ်ပြီး bottleneck အတိအကျရှာရန်မလုံလောက်ပါ။

ဒီအဆင့်အထိ detail လိုအပ်ပါက dedicated tracing tool တစ်ခုကို ထပ်ထည့်ရဦးမည်ဖြစ်သည်၊ ဘာကြောင့်ဆိုတော့ platform ၏ built-in view သည် ထိုအထိ မရောက်ပါ။ ယခု team နောက်တစ်ခုကမူ backend ကို major cloud ပေါ်တွင် run သည်ဆိုပါစို့ — bottleneck-hunting လုပ်နိုင်သော tracing/metrics system ရရှိသော်လည်း တစ်စုံတစ်ယောက်က instrumentation, dashboard, alert rule များကို configure လုပ်ပြီးမှသာဖြစ်ပြီး PaaS ၏ basic log ကဲ့သို့ default အားဖြင့် ဘာမှ မရှိပါ။

BaaS ပေါ်တွင် တည်ဆောက်နေသော team တတိယတစ်ခုသည် login attempt မအောင်မြင်ခြင်းနှင့် database query နှေးကွင်းခြင်းကို platform ၏ ကိုယ်ပိုင်အပိုင်းများဖြစ်သောကြောင့် အလိုအလျောက် ကောင်းစွာ မြင်ရသော်လည်း ၎င်း၏ business logic run နေသော custom serverless function များကို code ထဲမှာ logging ကို တိုက်ရိုက် ချိတ်ဆက်ထားခြင်းမရှိပါက နီးပါးဘာမှ log မရနိုင်ပါ။

Case တိုင်းတွင် သင်ခန်းစာက တူညီသည်: platform တစ်ခုကို ကတိပြုခံမည့်မီ default အားဖြင့် ဘာပြသလဲ စစ်ဆေးပြီး ထို default နှင့် team က production issue debug လုပ်ရန် တကယ်လိုအပ်မည့်အရာကြားက ကျန်ရှိနေမည့် gap အတွက် တကယ့်အချိန်ကို budget ချထားပါ။

• Default observability depth သည် platform အမျိုးအစားပေါ် လေးနက်စွာ ကွာခြားသည်
• Major cloud သည် power အများဆုံးပေးသော်လည်း setup homework အများဆုံးလည်းလိုသည်
• Platform ရွေးချယ်ခြင်းသည် ဘယ် observability gap ကို ကိုယ်တိုင် ဖြည့်ချင်သလဲကို တိတ်တိတ်ဆိတ်ဆိတ် ရွေးချယ်ခြင်းဖြစ်သည်

အတူတူ စမ်းရေးကြည့်မယ်

function assessObservabilityFit(platformType, needs) {
  const {
    needsCustomMetrics = false,
    needsDeepTracing = false,
    justNeedsUptimeAlerts = false,
  } = needs;

  const defaults = {
    "major-cloud": { customMetrics: true, deepTracing: true, uptimeAlerts: true, note: "capable but requires manual setup" },
    "paas": { customMetrics: false, deepTracing: false, uptimeAlerts: true, note: "works out of the box for basics only" },
    "baas": { customMetrics: false, deepTracing: false, uptimeAlerts: true, note: "strong for managed pieces, weak for your own code" },
  };

  const d = defaults[platformType];
  if (!d) return { sufficient: false, reason: "unknown platform type" };

  const needsList = [];
  if (needsCustomMetrics && !d.customMetrics) needsList.push("custom metrics tooling");
  if (needsDeepTracing && !d.deepTracing) needsList.push("dedicated tracing tool");
  if (justNeedsUptimeAlerts && !d.uptimeAlerts) needsList.push("uptime alerting");

  return {
    sufficientByDefault: needsList.length === 0,
    additionalToolingNeeded: needsList,
    note: d.note,
  };
}

console.log("Major cloud + deep tracing need:", assessObservabilityFit("major-cloud", { needsDeepTracing: true }));
console.log("PaaS + just uptime alerts:", assessObservabilityFit("paas", { justNeedsUptimeAlerts: true }));
console.log("BaaS + custom metrics need:", assessObservabilityFit("baas", { needsCustomMetrics: true }));

Major cloud + deep tracing: sufficientByDefault true (cloud native tracing ပါဝင်သော်လည်း manual setup လိုသေးသည်)
PaaS + uptime alerts only: sufficientByDefault true
BaaS + custom metrics: sufficientByDefault false, additionalToolingNeeded ['custom metrics tooling']

Wikipedia: Observability (software) — Cloud Providers & Platforms