Elasticsearch 8 — Use case ngân hàng & Kibana

Bảy bài trước dựng nền: Elasticsearch là gì, document & index, Query DSL, aggregations, indexing & ingest, cluster & scaling, hiệu năng & vận hành. Bài này là điểm hội tụ: gom hết công cụ đó lại và trả lời câu hỏi thực chiến nhất — một ngân hàng dùng Elastic Stack để làm gì, và làm như thế nào cho đúng?

Ta sẽ đi qua Kibana, bốn mảng use case ngân hàng, một kiến trúc tham chiếu chung, kim chỉ nam chọn giữa Elasticsearch / ClickHouse / RDBMS, và các cạm bẫy đắt tiền cần né. Đây là bài "lắp ráp", không phải lý thuyết mới.

Lưu ý về sandbox: SQL sandbox của Knowledge Base chạy trên PostgreSQL. Elasticsearch dùng Query DSL (JSON qua REST), không dùng SQL. Trong bài sẽ có vài block SQL đánh dấu "▶ Chạy được" để minh hoạ loại câu hỏi mà trên ES sẽ được diễn đạt bằng query/aggregation — chúng chạy trên Postgres, còn cú pháp ES thì được ghi rõ bên cạnh.

Kibana: cửa sổ nhìn vào dữ liệu

Không có Kibana, Elasticsearch chỉ nói chuyện qua REST API — hữu ích cho máy, khó chịu cho người. Kibana là ứng dụng web biến index thành biểu đồ, bảng và cảnh báo. Bốn khối chức năng cần nắm:

1. Discover — khám phá thô. Nơi bạn chọn một data view (tập index, ví dụ logs-app-*), gõ điều kiện lọc bằng KQL (Kibana Query Language, ví dụ service: "payment" and level: "ERROR"), chọn khoảng thời gian, và xem từng document raw kèm biểu đồ mật độ theo thời gian. Đây là màn hình dùng nhiều nhất khi điều tra sự cố: gõ trace_id, thu hẹp thời gian, đọc log gốc.

2. Visualize — dựng một biểu đồ. Mỗi visualization là một aggregation được vẽ ra: đường số lỗi theo phút (date_histogram), cột top service theo latency (terms + avg), pie tỷ lệ giao dịch theo kênh. Công cụ dựng chính hiện nay là Lens (kéo-thả trường, Kibana tự chọn aggregation phù hợp).

3. Dashboard — ghép nhiều biểu đồ. Một dashboard là tập visualization xếp cạnh nhau, chia sẻ bộ lọc thời gian và điều kiện chung. Đây là "bảng điều khiển SLA" mà đội vận hành mở suốt ngày: tổng request, tỷ lệ lỗi, p95 latency, top endpoint chậm — tất cả tự cập nhật.

4. Alerting — cảnh báo tự động. Kibana (qua Alerting framework) cho định nghĩa rule: cứ mỗi khoảng (ví dụ 1 phút) chạy một truy vấn tổng hợp, nếu kết quả vượt ngưỡng thì kích action — gửi email, Slack, webhook, tạo ticket. Ví dụ: "tỷ lệ level: ERROR của service payment > 1% trong 5 phút → báo trực". Đây là thứ biến dashboard thụ động thành hệ thống chủ động.

Ngoài bốn khối này, Kibana còn là bảng điều khiển cho các giải pháp đóng gói sẵn: Observability (APM, log, metric, uptime) và Security (SIEM, detection rules) — ta nói ngay dưới đây.

Use case 1 — Log & observability tập trung

Đây là lý do phổ biến nhất khiến một ngân hàng dựng Elastic Stack. Hệ thống lõi (core banking), hệ thống thẻ, cổng API (API gateway), microservice thanh toán... mỗi thứ sinh log rải rác trên hàng chục, hàng trăm máy. Trước Elastic Stack, điều tra một sự cố nghĩa là SSH vào từng máy grep file log — chậm và dễ sót.

Log centralization gom mọi dòng log về một index tập trung, chuẩn hoá thành các trường JSON (@timestamp, service, level, latency_ms, trace_id, status_code). Từ đó:

• Điều tra sự cố (troubleshooting): truy một trace_id để xem một giao dịch chuyển khoản đi qua những service nào và tắc ở đâu — thay vì ghép log thủ công giữa các máy.
• Dashboard SLA: đếm lỗi theo thời gian, tỷ lệ thành công của giao dịch, p95/p99 latency theo endpoint. Đây chính là ứng dụng của aggregations — date_histogram cho trục thời gian, percentiles cho độ trễ.
• APM (Application Performance Monitoring): Elastic APM agent cắm vào ứng dụng đo thời gian phản hồi, throughput, tỷ lệ lỗi và distributed tracing — theo dấu request qua các service, chỉ ra điểm nghẽn.

Câu hỏi kiểu "đếm lỗi theo loại trong khoảng thời gian" trên ES là một terms aggregation. Để cảm nhận hình dạng câu hỏi, đây là bản tương đương chạy được trên Postgres (cột kind đóng vai "loại sự kiện/giao dịch"):

-- ▶ Chạy được
SELECT kind, COUNT(*) AS so_luong, SUM(amount) AS tong_tien
FROM transactions
WHERE created_at >= '2026-06-01' AND created_at < '2026-07-01'
GROUP BY kind
ORDER BY so_luong DESC;

Trên Elasticsearch, cùng ý đồ đó viết bằng Query DSL: một range filter trên @timestamp bọc trong bool, cộng một terms aggregation trên trường kind với sub-aggregation sum trên amount. Kết quả về dưới dạng JSON các bucket, và Kibana Lens vẽ thẳng thành biểu đồ cột.

Use case 2 — SIEM / security analytics

Log bảo mật là một dòng đặc biệt của observability, quan trọng đến mức Elastic đóng gói riêng thành SIEM (Security Information and Event Management). Log đăng nhập, firewall, endpoint, VPN, Active Directory được gom vào Elasticsearch rồi chạy detection rules để phát hiện bất thường:

• Đăng nhập bất thường: nhiều lần đăng nhập thất bại liên tiếp (dò mật khẩu / brute force), đăng nhập thành công ngay sau chuỗi thất bại, đăng nhập từ hai vị trí địa lý cách xa trong thời gian ngắn ("impossible travel"), truy cập ngoài giờ hành chính.
• Giám sát an ninh: cảnh báo khi có truy cập vào tài nguyên nhạy cảm, thay đổi quyền, hoặc traffic ra ngoài bất thường.
• Audit log: lưu lại ai làm gì, khi nào, trên bản ghi nào — ai truy vấn hồ sơ khách hàng, ai export dữ liệu. Trong ngân hàng đây không chỉ là bảo mật mà là tuân thủ: quy định yêu cầu lưu và tra soát được audit trail. Elastic Stack giữ audit log tập trung, tìm kiếm nhanh, và giữ đủ thời hạn lưu theo quy định. Việc kiểm soát ai được xem chính các log này lại liên quan tới phân quyền truy cập.

Điểm cần nhớ: SIEM trên Elastic mạnh ở phát hiện và điều tra tương tác (search-as-you-type trên hàng tỷ sự kiện), nhưng bản thân ES không là hệ thống quản trị tuân thủ — nó là công cụ; quy trình, chính sách lưu trữ và kiểm soát quyền vẫn là phần con người.

Use case 3 — Full-text search nghiệp vụ

Gốc rễ của Elasticsearch. Trong ngân hàng, các ô tìm kiếm nghiệp vụ là ứng dụng trực tiếp nhất:

• Tra cứu khách hàng: tìm hồ sơ theo tên, số điện thoại, CMND/CCCD, mã khách trong CRM. Điểm ăn tiền là tìm gần đúng tên có dấu / không dấu: nhân viên gõ "nguyen van an" phải khớp "Nguyễn Văn An". Đây là việc LIKE của SQL không làm nổi, còn analyzer của ES (bỏ dấu, tách token, fuzzy) làm mượt.
• Tra cứu giao dịch: ô tìm giao dịch trên app chăm sóc khách hàng — "nap the viettel thang 3" trả về đúng nhóm giao dịch, xếp hạng theo relevance, phản hồi vài chục mili-giây thay vì quét toàn bảng trên hệ thống lõi.

Loại truy vấn "lấy giao dịch của một tài khoản trong khoảng thời gian" — nền của mọi ô tra cứu — trên Postgres trông như thế này:

-- ▶ Chạy được
SELECT t.id, t.created_at, t.kind, t.amount
FROM transactions t
JOIN accounts a ON a.id = t.account_id
WHERE a.account_no = '000123456'
  AND t.created_at >= '2026-06-01'
  AND t.created_at <  '2026-07-01'
ORDER BY t.created_at DESC;

Trên Elasticsearch, nếu mỗi giao dịch là một document (đã denormalize account_no vào document theo hướng dẫn ở document & index), cùng ý đồ là một bool query: một term trên account_no cộng một range trên created_at, sắp xếp sort giảm dần theo thời gian. Với tìm mô tả gần đúng, ta thêm một match (full-text) trên trường mô tả và để BM25 xếp hạng relevance — thứ mà ORDER BY của SQL không có khái niệm.

Với nhu cầu tìm kiếm nhỏ và vừa, đừng vội dựng ES: full-text search của PostgreSQL qua tsvector/tsquery là quá đủ và dữ liệu ở ngay database gốc, đồng bộ tức thì.

Use case 4 — Hỗ trợ giám sát giao dịch & điều tra

Elastic Stack không thay thế hệ thống giám sát giao dịch AML chuyên dụng, nhưng là lớp hỗ trợ điều tra rất mạnh. Khi một cảnh báo AML nổ (ví dụ chuỗi giao dịch nghi ngờ chia nhỏ để né ngưỡng — smurfing), điều tra viên cần truy ngược nhanh mọi giao dịch liên quan tới một tài khoản, một khách, một khoảng thời gian, một đối tác. ES cho phép:

• Tìm kiếm tương tác trên hàng trăm triệu giao dịch với phản hồi dưới giây.
• Ghép nhiều điều kiện văn bản + số + thời gian trong một bool query mà không đánh sập database giao dịch gốc.
• Dựng dashboard "chân dung giao dịch" của một khách trong Kibana để điều tra viên nhìn tổng thể.

Ranh giới quan trọng: ES là bản sao để tra cứu và điều tra, còn quyết định giám sát, chấm điểm rủi ro và lưu bằng chứng thuộc hệ thống AML và database giao dịch gốc. Chất lượng của lớp tra cứu này phụ thuộc trực tiếp vào chất lượng dữ liệu đẩy sang.

Kiến trúc tham chiếu

Ghép cả bốn use case lại, một kiến trúc Elastic Stack điển hình cho ngân hàng — phục vụ đồng thời observability và SIEM — trông như sau:

Đọc theo dòng: Beats thu log nhẹ tại nguồn; CDC/ETL đẩy giao dịch từ database gốc; Logstash / Ingest Pipeline parse và chuẩn hoá; Elasticsearch lưu, index và tổng hợp; Kibana trình bày và cho điều tra; Alerting biến ngưỡng thành hành động. Log nóng thường giữ trên ES 30–90 ngày qua ILM và data tiers; dữ liệu cũ hơn dời sang lưu trữ rẻ.

Khi nào chọn ES vs ClickHouse vs RDBMS

Đây là quyết định kiến trúc hay sai nhất — và tốn kém nhất khi sai. Ba công cụ, ba thế mạnh khác nhau:

Kim chỉ nam ngón tay cái:

• Cần tìm kiếm văn bản, xếp hạng relevance, khám phá log tương tác, alerting → Elasticsearch.
• Cần tổng hợp metric quét hàng tỷ dòng, lưu dài hạn, chi phí lưu tối ưu, dashboard OLAP → ClickHouse.
• Cần giao dịch chính xác, nhất quán, làm nguồn sự thật → RDBMS.

Thực tế nhiều ngân hàng dùng cả ba: RDBMS/Oracle giữ sổ cái, ES phục vụ log nóng + tìm kiếm + SIEM, ClickHouse gánh phân tích metric dài hạn. Mỗi công cụ đúng việc của nó — đừng ép một công cụ làm việc của công cụ khác.

Cạm bẫy & chi phí

Elastic Stack mạnh nhưng đặt sai chỗ trả giá đắt. Các bẫy hay gặp:

• Coi ES là nguồn sự thật giao dịch. Sai lầm nguy hiểm nhất. ES là near-real-time, không có transaction đa-document, có thể mất dữ liệu chưa flush khi sự cố. Số dư, sổ cái, đối soát phải ở database ACID. ES chỉ là bản sao để tìm/phân tích. Xem lại định vị ở bài 1.
• Heap JVM. ES chạy trên JVM; quy tắc kinh điển: heap ≤ 50% RAM và dưới ~32 GB (để giữ compressed oops). Đặt heap quá lớn không nhanh hơn mà còn gây GC pause dài. Chi tiết ở hiệu năng & vận hành.
• Chi phí lưu trữ phình. Log và full-text index chiếm nhiều dung lượng (inverted index + _source + doc values). Giữ mọi thứ "nóng" mãi mãi là hoá đơn khổng lồ. Bắt buộc dùng ILM để tự động chuyển hot→warm→cold→delete và đặt thời hạn lưu hợp lý.
• Over-sharding. Chia quá nhiều shard nhỏ làm phình bộ nhớ cluster và chậm query. Dùng data stream + ILM rollover thay vì đẻ index/shard tuỳ tiện.
• Dựng cả cluster chỉ để tránh một câu tsquery. Nếu nhu cầu tìm kiếm nhỏ, full-text của PostgreSQL rẻ và đủ. ES đáng dựng khi thực sự cần quy mô, relevance tinh vi, hoặc gom log tập trung.
• Bỏ qua bảo mật. Cluster mở không xác thực từng là nguồn rò rỉ dữ liệu đình đám. Bật xác thực, TLS, và kiểm soát ai xem được index nhạy cảm (đặc biệt SIEM/audit) — liên hệ phân quyền truy cập.

Use case thực tế

Bối cảnh. Ngân hàng NCB dùng một cluster Elastic Stack duy nhất phục vụ ba mảng: observability, SIEM và tìm kiếm nghiệp vụ. Quy mô minh hoạ: log ứng dụng ~40 GB/ngày từ 60 microservice, ~120 triệu giao dịch/năm đồng bộ sang index tìm kiếm, log bảo mật từ firewall + AD + VPN.

Triển khai.

1. Observability. Filebeat trên 60 service đẩy log qua Logstash (parse grok thành service, level, latency_ms, trace_id). Kibana dashboard SLA hiển thị tỷ lệ lỗi theo phút và p95 latency theo endpoint. Alert: tỷ lệ ERROR của service payment > 1% trong 5 phút → báo đội trực. Kết quả: thời gian khoanh vùng sự cố giảm từ hàng giờ (SSH + grep) xuống vài phút.

2. SIEM. Winlogbeat + firewall log vào index security. Detection rule "impossible travel" và "≥ 10 lần đăng nhập thất bại trong 1 phút rồi thành công" gửi cảnh báo tới SOC. Audit log truy vấn hồ sơ khách hàng được giữ tập trung, đáp ứng yêu cầu tra soát tuân thủ.

3. Tìm kiếm nghiệp vụ. CDC đẩy giao dịch từ Oracle sang index ES; analyzer bỏ dấu tiếng Việt cho khớp gần đúng. Nhân viên gõ "nap the viettel thang 3" nhận đúng nhóm giao dịch, phản hồi dưới 50 ms, trong khi Oracle vẫn giữ số dư và đối soát.

4. Quản chi phí. ILM giữ log nóng 30 ngày, chuyển warm 30 ngày tiếp rồi xoá; metric tổng hợp dài hạn (throughput theo ngày cả năm) đẩy sang ClickHouse để tối ưu lưu trữ. Cluster giữ heap 31 GB/node, không vượt 32 GB.

Bài học. Một cluster phục vụ nhiều mảng được, nhưng phải tách index rõ ràng, phân quyền theo mảng, dùng ILM triệt để, và luôn nhớ ES là lớp tra cứu, không phải sổ cái.

Ghi nhớ

• Kibana là lớp mặt người: Discover (khám phá/điều tra), Visualize/Lens (một biểu đồ), Dashboard (bảng SLA), Alerting (ngưỡng → email/Slack/webhook). Không có Kibana, ES chỉ nói qua API.
• Bốn use case ngân hàng: (1) log & observability tập trung — gom log core/thẻ/API, điều tra qua trace_id, dashboard SLA + APM; (2) SIEM/security — phát hiện đăng nhập bất thường, giám sát an ninh, audit log phục vụ tuân thủ; (3) full-text search — tra cứu khách/giao dịch, khớp tên có dấu/không dấu; (4) hỗ trợ điều tra cho giám sát giao dịch AML.
• Kiến trúc tham chiếu: Beats/CDC → Logstash/Ingest Pipeline → Elasticsearch → Kibana + Alerting; log nóng 30–90 ngày qua ILM.
• Chọn công cụ: ES cho tìm kiếm + log tương tác + SIEM; ClickHouse cho aggregation OLAP quy mô lớn, lưu rẻ; RDBMS cho giao dịch ACID, nguồn sự thật. Nhiều ngân hàng dùng cả ba.
• Cạm bẫy: ES không là nguồn sự thật giao dịch; heap ≤ 50% RAM và < 32 GB; chi phí lưu phình nếu không dùng ILM; over-sharding; đừng dựng cả cluster chỉ để tránh một tsquery; bắt buộc bật xác thực/TLS và kiểm soát quyền trên index nhạy cảm.
• Trên ES, câu hỏi "đếm theo loại" là terms aggregation, "giao dịch của account trong khoảng thời gian" là bool + term + range + sort, "tìm mô tả gần đúng" là match + BM25 — không dùng SQL.