ลดบิล Observability 2026: Datadog & Spl…

Q: ทำไม Datadog ถึงแพงมาก?

Datadog คิดเงินหลายแกนพร้อมกัน (ค่า host, log ingest $0.10/GB, custom metrics $0.05/metric/เดือน และ APM span จำนวน) โดยที่ custom metrics คือตัวที่ทำให้บิลระเบิดที่สุด เพราะ 1 metric ที่มี tag high-cardinality เช่น user_id 10,000 คน จะกลายเป็น 10,000 custom metrics คิดเป็น $500/เดือน จาก metric เดียว วิธีลดคือใช้ Metrics Without Limits ตัด tag ที่ไม่ query จริง

Q: มีทางเลือกอะไรที่ถูกกว่า Datadog บ้าง?

Grafana Cloud (LGTM stack) เป็นทางเลือกที่ถูกที่สุดสำหรับ workload ขนาดเล็ก-กลาง มี free tier 10k series/50GB log และ usage-based ที่ยืดหยุ่น สำหรับ enterprise ควรพิจารณา self-hosted Prometheus + Loki + Tempo + Mimir บน Kubernetes ซึ่งจ่ายเฉพาะค่า infra (2–5x ถูกกว่า SaaS) แต่ต้องมีทีม SRE ที่ดูแลไหว หรือใช้ Chronosphere, Coralogix, Honeycomb ที่ pricing model ยืดหยุ่นกว่า

Q: High cardinality metric คืออะไรและทำไมถึงต้องกลัว?

High cardinality metric คือ metric ที่มี label ที่มีค่าไม่ซ้ำจำนวนมาก (มากกว่า 100–1,000 ค่า) เช่น user_id, request_id, trace_id เมื่อใส่เป็น label ของ metric แต่ละค่าจะสร้าง time series ใหม่ ทำให้ storage และค่า billing ระเบิด เช่น 3 label ที่มี 100/100/1000 ค่า = 10 ล้าน series วิธีป้องกันคือย้าย ID ที่มี cardinality สูงไปเก็บใน trace/log แทน metric

Q: การย้ายไป OpenTelemetry ใช้เวลานานแค่ไหน?

สำหรับ 20–30 microservice ใช้เวลา 3–6 เดือนสำหรับทีมที่ทำ full-time โดย 60% เป็นการ instrument โค้ด และ 40% เป็นการตั้ง Collector, dashboard, alert ใน backend ใหม่ แนะนำให้ทำแบบ dual-write (ส่งไป 2 ปลายทางพร้อมกัน) 30–60 วันเพื่อ verify ก่อนตัด vendor เก่าออก ลด risk migration ได้เกือบหมด

Q: Log sampling ปลอดภัยไหมสำหรับระบบ production?

ปลอดภัยถ้าใช้ tail-based sampling ที่เก็บ error 100% และ high-latency trace 100% ไม่ปลอดภัยถ้าใช้ head-based sampling แบบ probabilistic กับ error log เพราะจะสูญเสีย log สำคัญที่มาก่อน error ทำให้ debug ไม่ได้ กฎที่ปลอดภัยที่สุดคือ include-list (define ว่าเก็บอะไรบ้าง) มากกว่า exclude-list ที่พลาดง่าย และตั้ง alert ที่ error rate ไม่ใช่ที่ log volume

อัปเดตล่าสุด: 14 กรกฎาคม 2026

การลดค่าใช้จ่ายเครื่องมือ Observability ทำได้ด้วย 4 กลยุทธ์หลัก คือ ตัด log ที่ไม่จำเป็นด้วย drop/sampling rules, จัดการ cardinality ของ metrics label, ย้าย custom metrics ที่คิดเงินสูงไปเป็น histogram หรือ derived metrics และตั้ง retention tier แบบ hot/warm/cold ให้เหมาะกับความถี่การ query จริง องค์กรที่ทำครบทั้ง 4 ข้อ สามารถลดบิล Datadog, Splunk, New Relic หรือ Grafana Cloud ได้ 40–70% ภายในไตรมาสเดียวโดยไม่ต้องยอมสูญเสีย visibility ที่สำคัญต่อการดูแลระบบ production ผมเคยเจอเคสที่บิล Datadog ทะลุ 6 หลักต่อเดือน แล้วลดลงเหลือครึ่งภายใน 8 สัปดาห์ด้วยชุดเทคนิคที่จะเล่าให้ฟังในบทความนี้

ค่า Observability กลายเป็นบิลอันดับ 2 รองจาก compute ในหลายองค์กร โดย Datadog มักคิดเงินสูงจาก custom metrics ($0.05/metric/เดือน) และ log ingest ($0.10/GB)
High-cardinality metric (label ที่มีค่าไม่ซ้ำหลายพันหลายหมื่น เช่น user_id, request_id) คือสาเหตุอันดับ 1 ของบิลบานปลาย ควรตัดออกและใช้ trace แทน
Log sampling แบบ tail-based ผ่าน Vector, Fluent Bit หรือ OpenTelemetry Collector ลด volume ได้ 60–80% โดยยังเก็บ error และ trace ที่ต้องการครบ
Splunk SmartStore, Datadog Flex Logs และ Grafana Loki tiered storage ช่วยให้เก็บ log ระยะยาวได้ในราคา 1/10 ของ tier ปกติ
การย้ายไป OpenTelemetry standard ช่วยหลุด vendor lock-in ทำให้ต่อรองราคาหรือย้ายค่ายได้ทุก 12–18 เดือน
ควรตั้ง unit cost KPI เช่น "ค่า observability ต่อ 1 ล้าน request" เพื่อป้องกันบิลกลับมาโตซ้ำหลังลดครั้งแรก

ทำไมค่า Observability ปี 2026 ถึงแพงขึ้นเรื่อยๆ

เอาตรงๆ ประสบการณ์ที่ผมเห็นซ้ำในหลายทีม คือบิล observability โตเร็วกว่าบิล compute ถึง 3 เท่าในช่วง 18 เดือนหลัง สาเหตุหลักไม่ใช่ราคาต่อหน่วยที่ขึ้น แต่มาจาก 3 พฤติกรรมของทีมพัฒนาที่เปลี่ยนไปหลัง Kubernetes และ microservices กลายเป็นมาตรฐาน คือ (1) จำนวน pod ที่ปล่อย log เพิ่มจากหลักสิบเป็นหลักพันภายในไม่กี่ปี (2) นักพัฒนายิง custom metric ตามใจโดยไม่มี governance และ (3) label เช่น user_id, request_id, trace_id ถูกใส่เป็น metric dimension ทำให้ time series ระเบิดเป็นล้าน

ตามรายงาน Gartner Market Guide for Observability Platforms องค์กรระดับ enterprise มีค่า observability เฉลี่ย 8–15% ของบิลคลาวด์ทั้งหมด และตัวเลขนี้จะแตะ 20% ในปี 2027 หากไม่มีการควบคุม ที่น่ากังวลกว่าคือ Datadog กับ Splunk คิดเงินแบบ "ยิ่งใช้ยิ่งลดจ่ายไม่ได้" (commitment discount กินตายเราตอนต่อสัญญา แล้ว overage คิดในราคาเต็ม) ทำให้บิลกระโดดได้ 2–3 เท่าเมื่อมี incident ใหญ่หรือ deploy ผิดพลาดจนยิง log ล้น การเข้าใจโครงสร้างราคาก่อนตัดสินใจซื้อคือด่านแรกที่ประหยัดได้จริง เชื่อมกับหลัก FinOps Unit Economics วัดต้นทุนต่อ transaction ที่ควรผูก observability เข้าไปในสมการด้วย ไม่ใช่มองแยกส่วน

เปรียบเทียบโมเดลราคา Datadog, Splunk, New Relic, Grafana Cloud

ก่อนจะลดค่าใช้จ่าย เราต้องเข้าใจว่าแต่ละเจ้าคิดเงินยังไง เพราะกลยุทธ์การลดขึ้นกับสูตรราคาโดยตรง Datadog คิดเงินหลายแกน (host + log ingest + custom metric + APM span) ทำให้ประหยัดต้องทำหลายด้านพร้อมกัน ส่วน Splunk คิดตาม data ingested ต่อวัน (GB/day license) จึงต้องเน้นลด volume, New Relic เปลี่ยนไปคิดตาม data ingest (GB) + user seat ตั้งแต่ปี 2020 ส่วน Grafana Cloud มีทั้ง free tier กับ usage-based ที่ยืดหยุ่นสุด

คุณสมบัติ	Datadog	Splunk Cloud	New Relic	Grafana Cloud
โมเดลราคาหลัก	Host + Ingest + Metric	GB/day workload pricing	Ingest + User	Usage-based (metrics/logs/traces)
ค่า log ingest (ราคาลิสต์)	~$0.10/GB indexed	~$1,800/GB/day/ปี	~$0.30/GB (Data Plus)	~$0.50/GB (Loki)
ค่า custom metric	$0.05/metric/เดือน	รวมใน ingest	รวมใน ingest	~$8/1000 series/เดือน
Log retention default	15 วัน	90 วัน	30 วัน	30 วัน
Tiered storage	Flex Logs (cheap tier)	SmartStore (S3)	Data Plus tier	Loki cheap boltdb-shipper
Overage charge	ราคาเต็ม on-demand	Hard-limit cutoff ได้	Overage 1.5x	Usage-based ไม่มี overage
OpenTelemetry support	OTLP endpoint (dual write)	OTel Collector native	OTLP native	Native (LGTM stack)

ข้อสังเกตสำคัญคือ Datadog แม้ราคาต่อหน่วยดูต่ำที่สุด แต่พอนับรวม custom metrics และ APM traces กลับเป็นเจ้าที่บิลบานที่สุดในหลาย benchmark ปี 2025–2026 ขณะที่ Grafana Cloud มีต้นทุนคงที่ต่ำสุดสำหรับ workload ขนาดเล็ก-กลาง แต่ต้องการทีมที่ถนัด LGTM stack (Loki, Grafana, Tempo, Mimir)

วิธีลดค่าใช้จ่าย Datadog อย่างเป็นระบบ

ผมแนะนำให้เริ่มจาก Datadog Cost Analytics dashboard (Usage & Cost tab) เสมอ เพราะมันแจกแจงว่าเงินหายไปที่ไหนตั้งแต่วันแรก จากประสบการณ์ทำ 20+ engagement ในไทย บิล Datadog แบ่งได้ 4 ส่วนหลัก คือ Infrastructure hosts (30–40%), Logs (25–35%), Custom Metrics (15–25%), และ APM (10–20%) วิธีลดที่ได้ผลจริงต้องโจมตีทั้ง 4 ด้านคู่ขนาน

1) ลด Custom Metrics ที่คิดเงินสูง

Datadog คิด $0.05 ต่อ custom metric ต่อเดือน โดย 1 metric = 1 unique combination ของ metric name + tags ถ้าคุณส่ง http.requests พร้อม tag user_id ที่มีค่า 10,000 ค่า จะกลายเป็น 10,000 custom metrics = $500/เดือน เพียงจาก 1 metric ผมเจอบั๊กนี้เข้าเต็มๆ ตอน ship ฟีเจอร์แรกที่ tag user_id เข้า metric แล้วบิลกระโดด 4 เท่าใน 1 สัปดาห์ วิธีแก้คือใช้ Metrics Without Limits™ ที่ช่วยลบ tag ที่ไม่จำเป็นจาก metric ที่ query จริง ตัวอย่าง Datadog Agent configuration:

# /etc/datadog-agent/conf.d/metric_filter.yaml
init_config:
instances:
  - metric_filter:
      # ลบ high-cardinality tag ก่อน submit
      exclude_tags:
        - user_id
        - request_id
        - session_id
        - trace_id
      # เก็บเฉพาะ tag ที่ทีมใช้ query จริง
      include_tags:
        - env
        - service
        - version
        - region
        - endpoint

2) เปลี่ยน APM sampling จาก head-based เป็น tail-based

Datadog default เก็บ trace 100% แล้วค่อย sample ที่ intake ทำให้ทีมจ่ายค่า network egress และ ingest เต็มก่อนจะทิ้ง การใช้ OpenTelemetry Collector ทำ tail-based sampling ก่อนส่งเข้า Datadog ลด APM cost ได้ 60–75%:

# otel-collector-config.yaml
processors:
  tail_sampling:
    decision_wait: 30s
    policies:
      # เก็บ trace ที่มี error 100%
      - name: errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      # เก็บ trace ที่ช้ากว่า 1 วินาที
      - name: slow-traces
        type: latency
        latency: {threshold_ms: 1000}
      # เก็บ trace ที่มาจาก endpoint สำคัญ
      - name: critical-endpoints
        type: string_attribute
        string_attribute:
          key: http.route
          values: [/checkout, /payment]
      # trace ปกติ sample 5%
      - name: baseline
        type: probabilistic
        probabilistic: {sampling_percentage: 5}

exporters:
  datadog:
    api:
      site: datadoghq.com
      key: ${DD_API_KEY}

3) ปิด Log indexing สำหรับ log ที่ไม่ต้อง search

Datadog มี Log Archives (ส่งเข้า S3 ราคาถูก) และ Flex Logs (tier ราคา 1/5) สำหรับ log ที่ต้องเก็บตาม compliance แต่ไม่ค่อย search ควรตั้ง exclusion filter ที่ Log Pipeline เพื่อไม่ index log ระดับ INFO/DEBUG จาก health check และ liveness probe เป็นอันดับแรก

ลด log volume ด้วย Vector และ OpenTelemetry Collector

เครื่องมือกลางที่ผมใช้ประจำคือ Vector by Datadog (open source) เพราะประมวลผลได้ 10x เทียบ Fluentd และรองรับทั้ง VRL (Vector Remap Language) สำหรับ transform ที่ซับซ้อน ตัวอย่าง config ที่ตัด health-check log และ sample DEBUG log ก่อนส่งเข้าปลายทาง:

# vector.yaml, ลด log volume 60-80%
sources:
  kubernetes_logs:
    type: kubernetes_logs

transforms:
  drop_healthchecks:
    type: filter
    inputs: [kubernetes_logs]
    condition: |
      !contains(string!(.message), "/healthz") &&
      !contains(string!(.message), "/readiness") &&
      !contains(string!(.message), "kube-probe")

  sample_debug:
    type: sample
    inputs: [drop_healthchecks]
    rate: 100  # keep 1 in 100 DEBUG logs
    key_field: level
    exclude:
      type: vrl
      source: '.level != "DEBUG"'

  redact_pii:
    type: remap
    inputs: [sample_debug]
    source: |
      # แทน email/credit card ด้วย mask ก่อนส่ง
      .message = replace(string!(.message), r'[\w.]+@[\w.]+', "[EMAIL]")
      .message = replace(string!(.message), r'\d{16}', "[CC]")

sinks:
  datadog_logs:
    type: datadog_logs
    inputs: [redact_pii]
    default_api_key: ${DD_API_KEY}
    compression: gzip

เทคนิคที่มองข้ามบ่อยคือ compression: gzip ช่วยลด egress cost ระหว่าง cluster ไปยัง Datadog ได้ 5–8 เท่า ซึ่งเป็นค่าที่ไม่เห็นในบิล Datadog แต่ไปโผล่ในบิล AWS หรือ GCP แทน สอดคล้องกับที่เขียนไว้ใน คู่มือลดค่าเครือข่ายคลาวด์ เรื่อง egress cost ที่มักถูกลืม

จัดการ metric cardinality ไม่ให้บานปลาย

Cardinality คือจำนวนชุด unique ของ label combinations ต่อ metric name เช่น http_requests_total{method,status,path} ที่มี 4 method × 8 status × 500 path = 16,000 time series และถ้าเพิ่ม user_id (10,000 คน) เข้าไป กลายเป็น 160 ล้าน series ทันที นี่คือสาเหตุอันดับ 1 ที่บิล Prometheus, Mimir, Datadog custom metrics และ New Relic ระเบิด ผมเคยเห็นทีมนึงเจอปัญหานี้ตอน 3 ทุ่มวันศุกร์ เพราะ deploy ใหม่เพิ่ม label โดยไม่ได้ตั้งใจ

วิธีตรวจสอบ cardinality ก่อนบานปลายด้วย PromQL ที่ผมใช้เป็น standard:

# 10 metrics ที่มี series มากที่สุด (top cost driver)
topk(10, count by (__name__)({__name__=~".+"}))

# label ที่ทำให้ cardinality สูง
topk(10, count by (__name__, label_name)({__name__=~".+"}))

# หา metric ที่เพิ่ม cardinality เร็วในสัปดาห์ที่ผ่านมา
topk(10,
  count by (__name__)({__name__=~".+"})
  - count by (__name__)({__name__=~".+"} offset 7d)
)

กฎ 3 ข้อที่ผมสอนทีมพัฒนาเสมอ คือ (1) ไม่ใส่ ID ที่มี cardinality > 100 เป็น label ให้ไปอยู่ใน trace หรือ log แทน (2) ใช้ histogram bucket จำกัด (5–10 bucket) แทนที่จะใส่ raw latency เป็น label (3) ถ้าจำเป็นต้อง group by user ให้ใช้ exemplar หรือ Grafana Tempo trace search ไม่ใช่ metric

ตั้ง retention tier แบบ hot/warm/cold ให้ประหยัด

Log และ metric ส่วนใหญ่ถูก query ในช่วง 7 วันแรก หลังจากนั้นแทบไม่มีใครเปิดดูจนกว่าจะเกิด audit หรือ post-mortem ระยะยาว การเก็บทุกอย่างที่ hot tier 90 วันคือการเผาเงิน แนวทางที่ผมใช้ใน production:

Hot tier (0–7 วัน): Datadog Standard / Splunk hot bucket / Loki index (ราคาแพงสุด แต่ query < 1 วินาที)
Warm tier (7–30 วัน): Datadog Flex Logs / Splunk warm SmartStore / Loki chunks บน S3 IA (ราคา 1/5 ของ hot, query 5–30 วินาที)
Cold tier (30 วัน–7 ปี): S3 Glacier / Azure Archive / GCS Coldline พร้อม Parquet format สำหรับ query ผ่าน Athena/BigQuery (ราคา 1/50 ของ hot, query เป็นนาที)

ตัวอย่าง Terraform ที่ตั้ง Datadog Log Archive ไปยัง S3 พร้อม lifecycle policy ที่ย้ายเข้า Glacier หลัง 30 วัน:

resource "aws_s3_bucket_lifecycle_configuration" "logs" {
  bucket = aws_s3_bucket.dd_archive.id

  rule {
    id     = "tiering"
    status = "Enabled"

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }
    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }
    expiration {
      days = 2555  # 7 years compliance
    }
  }
}

resource "datadog_logs_archive" "s3" {
  name  = "prod-logs-cold"
  query = "env:production"
  s3_archive {
    bucket     = aws_s3_bucket.dd_archive.id
    path       = "logs"
    account_id = data.aws_caller_identity.current.account_id
    role_name  = aws_iam_role.datadog_archive.name
  }
}

ลดค่า Splunk ด้วย SmartStore และ Ingest Actions

Splunk เป็นเจ้าเดียวที่ยังคิดเงินแบบ GB/day ingested เป็นหลัก แม้จะเริ่มมี Workload Pricing แล้ว จุดโจมตีหลักคือ (1) ปริมาณ data ingested ต่อวัน และ (2) storage สำหรับ historical data

Splunk SmartStore แยก compute (indexer) กับ storage (S3) ทำให้เก็บ log 1–7 ปีในราคาต่ำมาก โดยไม่ต้อง provision disk บน indexer เพิ่ม ผลลัพธ์ที่ทีมเห็นจริงคือประหยัด storage cost 60–80% ตัวอย่าง indexes.conf:

[volume:smartstore]
storageType = remote
path = s3://mycompany-splunk-smartstore/
remote.s3.endpoint = https://s3.ap-southeast-1.amazonaws.com
remote.s3.access_key = $AWS_ACCESS_KEY_ID
remote.s3.secret_key = $AWS_SECRET_ACCESS_KEY

[application_logs]
homePath = volume:smartstore/$_index_name/db
coldPath = volume:smartstore/$_index_name/colddb
thawedPath = $SPLUNK_DB/$_index_name/thaweddb
remotePath = volume:smartstore/$_index_name
maxDataSize = auto
frozenTimePeriodInSecs = 220752000  # 7 years
maxGlobalDataSizeMB = 500000

อีกฟีเจอร์ที่ต้องเปิดคือ Ingest Actions (มาตั้งแต่ Splunk 8.2) ทำหน้าที่เหมือน Vector คือ filter/mask/route ก่อน index เช่นส่ง DEBUG log ไป S3 (ราคา $0) แทน index (ราคาเต็ม) ทีมที่ใช้เทคนิคนี้ลด daily ingest ได้ 40–65% ภายใน 2 สัปดาห์

ย้ายไป OpenTelemetry เพื่อหลุด vendor lock-in

เหตุผลที่ Datadog กับ Splunk คิดเงินแพงได้ตลอด คือ agent proprietary ของเขาถูกฝังในโค้ดของทีมพัฒนาแล้ว ย้ายค่ายทีเจ็บทั้ง engineering effort และเวลา OpenTelemetry (OTel) คือมาตรฐาน CNCF ที่กลายเป็น de facto ตั้งแต่ปี 2024 มี SDK ครบทุกภาษาและ Collector ที่ export ได้ทุกปลายทาง

ประโยชน์การย้าย คือ (1) instrument ครั้งเดียว ใช้ได้กับทุก vendor (2) ใช้ Collector เป็น "abstraction layer" (เปลี่ยน exporter ที่ config file แทนแก้โค้ด) (3) sampling และ transformation อยู่ที่ Collector ไม่ต้อง depend ตัว vendor (4) ใช้ต่อรองราคาต่อสัญญาได้ 15–30% เพราะ vendor รู้ว่าย้ายได้จริง

# OpenTelemetry Collector, dual-write เพื่อทดสอบก่อนย้าย
receivers:
  otlp:
    protocols:
      grpc: {endpoint: 0.0.0.0:4317}
      http: {endpoint: 0.0.0.0:4318}

processors:
  batch: {timeout: 10s}
  memory_limiter: {check_interval: 1s, limit_mib: 512}

exporters:
  # ปลายทางปัจจุบัน
  datadog:
    api: {site: datadoghq.com, key: ${DD_API_KEY}}
  # ปลายทางใหม่ที่ทดสอบ
  otlphttp/grafana:
    endpoint: https://otlp-gateway-prod-ap-southeast-1.grafana.net/otlp
    headers: {authorization: "Basic ${GRAFANA_TOKEN}"}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [datadog, otlphttp/grafana]  # ส่ง 2 ที่พร้อมกัน

ในการทดสอบ 30–60 วัน ให้ทีม SRE/DevOps เทียบ dashboard, alert และ trace ระหว่างสองที่ ก่อนตัดสินใจย้ายจริง จะช่วยลด risk migration ได้เกือบหมด

FinOps สำหรับ Observability: ตั้ง unit cost KPI

ปัญหาที่พบบ่อยหลังลดบิลครั้งแรกคือ 6 เดือนหลังบิลกลับมาโตซ้ำ เพราะไม่มี "guardrail" ป้องกันพฤติกรรมเดิม แนวปฏิบัติ FinOps ที่ผมใช้กับลูกค้าคือตั้ง KPI 3 ตัวและวัดรายเดือน:

Observability cost per 1M requests: รวมค่า APM + log + metric ทั้งหมด หารด้วยจำนวน request ที่ระบบรับ ถ้าตัวเลขนี้เพิ่ม 20% MoM ให้เข้าตรวจสอบทันที
Custom metrics per service: จำกัดที่ 200 unique metrics ต่อ service (เกินต้อง approve โดย FinOps champion ของทีม)
Log GB ingested per service per day: ตั้ง budget ต่อทีม และ alert เมื่อเกิน 80% ของ budget ด้วย Datadog Usage Attribution หรือ Splunk Usage Metric

นอกจากนี้ควรทำ Cost Anomaly Detection กับบิล observability โดยเฉพาะ เพราะ deploy ผิดพลาดที่ยิง log ล้นครั้งเดียวสามารถทำให้บิลเดือนนั้นเพิ่ม 3–5 เท่าได้ ระบบ alert ที่แจ้งใน 24 ชั่วโมงหลัง spike ช่วยประหยัดหลักแสนบาทได้ในหลาย engagement ที่ผมทำ

คำถามที่พบบ่อย

ทำไม Datadog ถึงแพงมาก?