Monitoring နှင့် Troubleshooting

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

Lesson 3 က `_cluster/health` ကို "readiness check" (dashboard warning light) အနေနဲ့ intro လုပ်ခဲ့ပေမယ့် production monitoring မှာတော့ status color ကိုကြည့်ရုံနဲ့ မလုံလောက်ဘဲ root cause ကို diagnose လုပ်တတ်ဖို့ vocabulary ကို deeper တက်ရပါတယ်။ Unassigned shards ဆိုတာ (`status: red` ရဲ့ အဖြစ်များဆုံးအကြောင်းရင်းတစ်ခု) node failure, disk space ကုန်ခြင်း, allocation setting misconfiguration တို့ကြောင့် primary/replica shard ကို node တစ်ခုမှာမှ assign မလုပ်နိုင်တော့တဲ့ situation ဖြစ်ပြီး `GET /_cluster/allocation/explain` API က ဘယ်ကြောင့် assign မဖြစ်နိုင်ဘူးဆိုတဲ့ specific reason ကို ရှင်းပြပေးနိုင်ပါတယ်။ Slow queries ကို diagnose လုပ်ဖို့ Elasticsearch ရဲ့ "slow log" feature (threshold ကျော်တဲ့ query တွေကို log ချထားခြင်း) ကို enable ထားနိုင်ပြီး `_search` request ထဲမှာ `profile: true` parameter ကို ထည့်ရင် query execution ကို phase အလိုက် (query, fetch, aggregation) time breakdown ပြပေးနိုင်ပါတယ်—Lesson 17 က non-cacheable `must` clause tradeoff၊ Lesson 18 က leading wildcard cost၊ Lesson 12 က deep pagination cost—ဒီ concept တွေအားလုံးက ဒီနေရာမှာ actual production symptom (slow query) အဖြစ် ပေါ်လာနိုင်ပါတယ်။ Out-of-memory issues ကတော့ JVM heap size ကို data volume/aggregation complexity အတွက် လုံလောက်အောင် configure မလုပ်ထားခြင်း (သို့) field data cache (aggregation/sort အတွက် memory ထဲ ဆွဲထားရသော data structure) ကို field count များလွန်းတဲ့ index ပေါ်မှာ uncontrolled ဖြစ်စေခြင်းက အဓိက cause များဖြစ်ပါတယ်—Lesson 18 ရဲ့ mapping explosion ပြဿနာက memory pressure ကိုလည်း တိုက်ရိုက် ဆက်စပ်ပါတယ်။ Monitoring ကို car ရဲ့ dashboard (readiness) ကနေ mechanic ရဲ့ diagnostic tool (root cause investigation) ဆီ level up သွားတာနဲ့ တွေးလို့ရပါတယ်—warning light ကို ကြည့်ရုံမက engine ကို ဖွင့်ကြည့်ဖို့ tool set ကိုပါ လိုအပ်ပါတယ်။

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

Tutorial Platform ရဲ့ production cluster မှာ `_cluster/health` status `red` ဖြစ်နေတာ alert တက်လာရင် ပထမဆုံး `GET /_cluster/allocation/explain` run ပြီး ဘယ် shard ကို ဘာကြောင့် assign မလုပ်နိုင်ဘူးဆိုတာ ရှာမယ်—disk space ကုန်နေတယ်ဆိုရင် node ရဲ့ storage ကို ချက်ချင်း expand လုပ်ရမယ်။ Search API response time ချက်ချင်းမြန်လိုက်နှေးလိုက် ဖြစ်နေရင် production slow log ကို enable ထားပြီး ဘယ် query pattern (deep pagination, leading wildcard) ကလား ဆိုတာ ဖမ်းယူမယ်—slow query တွေ့ရင် `profile: true` ဖြင့် ထပ် drill down ကြည့်မယ်။ JVM heap usage metric ကို dashboard ပေါ်မှာ monitor ထားပြီး threshold (ဥပမာ 85%) ကျော်ရင် alert ထုတ်မယ်—mapping explosion ဖြစ်နေတဲ့ index ရှိမရှိကိုလည်း field count metric ကနေ ဆက်စပ်ပြီး investigate လုပ်နိုင်ပါတယ်။

Unassigned shards = red status ရဲ့ common cause, allocation/explain API ဖြင့် root cause ရှာ
Slow log + profile: true ဖြင့် slow query ကို phase-level diagnose
JVM heap/field data cache monitoring ဖြင့် OOM ကို ကြိုတင်ကာကွယ်

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

http

GET /_cluster/allocation/explain
{
  "index": "tutorials",
  "shard": 0,
  "primary": false
}

GET /tutorials/_search
{
  "profile": true,
  "query": { "match": { "body": "redis" } }
}

GET /_cat/thread_pool/search?v

You should see

Unassigned replica shard ရဲ့ specific reason ကို ရှင်းပြသော response နှင့် query phase တစ်ခုစီရဲ့ execution time breakdown ရမည်။

၅ မိနစ် စမ်းကြည့်

`_cluster/health` status `red` ဖြစ်နေတဲ့ alert တစ်ခုကို ခံစားရတယ်ဆိုပါစို့—`allocation/explain` result မှာ "disk watermark exceeded" ဆိုတဲ့ reason ကိုတွေ့ရရင် ဘယ်လို troubleshooting step များ ဆက်လုပ်မလဲ list ရေးပါ။

သတိလေးတစ်ချက်

`_cluster/health` status `yellow`/`red` ကို glance လုပ်ရုံနဲ့ resolved လုပ်ခဲ့တယ်လို့ ယူဆပြီး `allocation/explain` ကို run ကြည့်ဘဲ root cause ကို skip ခြင်း—underlying issue (disk space, node failure) က ပြန်ဖြစ်နိုင်ဆဲပါ။

Slow query ကို production traffic အတွက် guess လုပ်ပြီး code ပြင်ခြင်း—slow log/profile data ကို အရင်စစ်မကြည့်ဘဲ root cause အမှန်ကို မသိဘဲ optimize လုပ်ရင် ပြဿနာအမှန်ကို မဖြေရှင်းနိုင်ပါ။

Elasticsearch Guide — Troubleshooting — Elastic