முதல் முதலில் ஒரு பயன்பாட்டிற்கான கண்காணிப்பை நீங்கள் எவ்வாறு வடிவமைப்பீர்கள்?

Question

Accepted Answer

**கீழிலிருந்து மேல்நோக்கி உள்கட்டமைப்பிலிருந்து** அல்ல, **மேலிலிருந்து கீழ்நோக்கி பயனர்கள் உணர்வதிலிருந்து** தொடங்கவும். மிகவும் நம்பகமான호 ஸ்ட் ஃபிளீட் கோரிக்கைகள் தோல்வியடையும் போது மதிப்பற்றது, எனவே பயனர்-எதிர்முறையான **SLI** உடன் தொடங்கவும் — **தாமதம்**, **பிழை விகிதம்**, **கிடைக்கும் தன்மை** — பின்னர் நான்கு தங்க சமிக்ஞைகளைச் சேர்க்கவும், பின்னர் உள்கட்டமைப்பு மெட்ரிக்குகளைக் கடைசியாக சேர்க்கவும்.

## அடுக்குகள், பயனரிலிருந்து உள்நோக்கி

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

আপনি CPU மற்றும் disk ஐ மட்டும் கண்காணித்தால் (கீழிலிருந்து மேல்நோக்கி), நீங்கள் முழுவதும் பச்சையாக இருக்கலாம் அதே நேரம் பயனர்கள் 500s பெறுகிறார்கள். முதலில் SLI ஐக் கண்காணிப்பது (மேலிலிருந்து கீழ்நோக்கி) என்பது நீங்கள் **பயனர்கள் உண்மையில் உணர்ந்த அறிகுறிகளால்** எச்சரிக்கை செய்கிறீர்கள், பின்னர் நீங்கள் தங்க சமிக்ஞைகள் மற்றும் உள்கட்டமைப்பில் நுழைந்து காரணத்தைக் கண்டுபிடிக்கிறீர்கள் என்பதாகும்.

## பைப்லைன்: கருவி → சேகரணம் → டாஷ்போர்டு → எச்சரிக்கை

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## ஒரு கான்கிரீட் தொடக்க புள்ளி

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

ஒவ்வொரு SLI இல் **SLO** வரையறுக்கவும் (எ.கா. 99.9% கிடைக்கும் தன்மை, p99 < 300ms), அவற்றை டாஷ்போர்டு செய்யவும், மற்றும் SLO இடமிருந்து ஆபத்தில் இருக்கும் போது எச்சரிக்கை செய்யவும் — ஒவ்வொரு சிறிய ওঠানிறக்கத்திலும் அல்ல।

## இது ஏன் முக்கியமானது

கீழிலிருந்து மேல்நோக்கி கட்டப்பட்ட கண்காணிப்பு ஒரு ডிஸ்க் 80% நிரம்பியுள்ளது என்பதைக் கூறுகிறது ஆனால் வாடிக்கையாளர்கள் செக்அவுட் செய்யாமல் இருப்பதைக் கூறவில்லை. பயனர்-எதிர்முறையான SLI களுடன் தொடங்குவது ஒவ்வொரு டாஷ்போர்டு மற்றும் எச்சரிக்கையைத் திருப்பி உண்மையான பயனர் தாக்கத்துடன் இணைக்கிறது, இரைச்சல் குறைவாக வைத்திருக்கிறது, மற்றும் ஏதாவது உடைந்தபோது (அறிகுறி → தங்க சமிக்ஞை → உள்கட்டமைப்பு காரணம்) ஒரு স్పष्ட ড্রিল-ডাউன பாதை தருகிறது।