Xử lý các lỗi kết nối phổ biến giữa Vector, Kafka và ClickHouse
Trong môi trường production, lỗi kết nối thường xuất phát từ cấu hình không khớp giữa các thành phần, đặc biệt là vấn đề về xác thực (SASL/SSL) hoặc định dạng dữ liệu (Serialization).
1. Khắc phục lỗi Vector không gửi được dữ liệu vào Kafka
Vấn đề thường gặp là Vector báo lỗi "Connection refused" hoặc "Authentication failed". Nguyên nhân chính là Vector không thể handshake với Kafka broker do thiếu cấu hình SASL hoặc SSL, hoặc phiên bản protocol không tương thích.
Bước 1: Kiểm tra log lỗi của Vector để xác định loại lỗi cụ thể.
journalctl -u vector -f | grep -i "kafka\|error\|refused"
Kết quả mong đợi: Bạn thấy dòng log chỉ rõ lỗi, ví dụ: "failed to produce message: SASL authentication failed" hoặc "Connection refused: 9092".
Bước 2: Chỉnh sửa file cấu hình `/etc/vector/vector.toml` để bổ sung phần `sasl` và `ssl` nếu Kafka yêu cầu.
[sinks.kafka]
type = "kafka"
inputs = ["source_input"]
topic = "time-series-data"
bootstrap_servers = ["kafka:9092"]
[sinks.kafka.sasl]
enabled = true
mechanism = "SCRAM-256"
username = "vector_user"
password = "secure_password_123"
[sinks.kafka.sasl.ssl]
enabled = true
ca_file = "/etc/certs/ca.pem"
# client_cert_file = "/etc/certs/client.pem"
# client_key_file = "/etc/certs/client-key.pem"
Kết quả mong đợi: Sau khi restart Vector (`systemctl restart vector`), log không còn báo lỗi authentication, và bạn thấy thông báo "Producing message to topic...".
2. Khắc phục lỗi ClickHouse không nhận dữ liệu từ Kafka
ClickHouse sử dụng `KafkaConsumer` để đọc dữ liệu. Lỗi phổ biến là "Kafka: Request timed out" hoặc "Invalid format". Điều này xảy ra khi ClickHouse không thể kết nối vào topic hoặc không parse được dữ liệu (ví dụ: dữ liệu là JSON nhưng cấu hình là Protobuf).
Bước 1: Kiểm tra trạng thái của table nguồn Kafka trong ClickHouse.
clickhouse-client -q "SHOW CREATE TABLE kafka_source_table"
Kết quả mong đợi: Xem lại định dạng `FORMAT` trong câu lệnh tạo bảng. Nếu dữ liệu đầu vào là JSON, phần này phải là `FORMAT JSONEachRow`.
Bước 2: Nếu gặp lỗi timeout, tăng giá trị `fetch_max_bytes` và kiểm tra firewall.
clickhouse-client -q "ALTER TABLE kafka_source_table MODIFY SETTINGS fetch_max_bytes = '100MB', fetch_max_bytes_ratio_to_max_poll_interval = 1.0"
Kết quả mong đợi: ClickHouse bắt đầu fetch dữ liệu từ Kafka mà không bị treo (stuck) ở trạng thái pending.
Bước 3: Debug lỗi định dạng bằng cách xem raw data trong Kafka và so sánh với cấu hình.
kafka-console-consumer --bootstrap-server kafka:9092 --topic time-series-data --from-beginning --max-messages 5
Kết quả mong đợi: Bạn thấy dữ liệu thô. Nếu là JSON, hãy đảm bảo trong ClickHouse bạn dùng `FORMAT JSONEachRow`.
Đọc log và debug vấn đề mất dữ liệu hoặc độ trễ cao
Để xác định điểm nghẽn (bottleneck) hoặc mất mát dữ liệu, bạn cần so sánh số lượng message giữa ba điểm: Vector (source), Kafka (buffer) và ClickHouse (destination).
1. Xác định điểm mất dữ liệu (Data Loss)
Chiến lược là đếm số lượng message ở từng tầng và so sánh. Nếu Vector gửi 1000 nhưng ClickHouse chỉ nhận 800, lỗi nằm ở Kafka hoặc cấu hình tiêu thụ.
Bước 1: Kiểm tra số message đã gửi của Vector (nếu cấu hình log level INFO/DEBUG).
grep -c "Produced" /var/log/vector/vector.log | tail -1
Kết quả mong đợi: Một con số tổng cộng message Vector đã cố gắng gửi.
Bước 2: Kiểm tra số lượng message thực tế trong Kafka.
kafka-run-class.sh org.apache.kafka.tools.GetOffsetShell --broker-list kafka:9092 --topic time-series-data --time -1
Kết quả mong đợi: Offset hiện tại của topic. Offset này phải xấp xỉ với số lượng message Vector đã gửi (tính trừ offset ban đầu).
Bước 3: Kiểm tra số lượng record đã lưu vào ClickHouse.
clickhouse-client -q "SELECT count() FROM destination_table"
Kết quả mong đợi: Số lượng dòng trong bảng đích. Nếu nhỏ hơn offset Kafka, ClickHouse đang gặp lỗi parse hoặc lỗi write (check log ClickHouse: `tail -f /var/log/clickhouse-server/clickhouse-server.log | grep "Error"`).
2. Debug độ trễ cao (High Latency)
Độ trễ cao thường do ClickHouse tiêu thụ chậm hơn Vector gửi vào, hoặc Kafka bị backlog.
Bước 1: Kiểm tra số lượng message chưa được tiêu thụ (Lag) trong Kafka.
kafka-consumer-groups.sh --bootstrap-server kafka:9092 --describe --group clickhouse_consumer_group
Kết quả mong đợi: Cột "LAG" tăng liên tục. Nếu Lag > 0 và tăng, ClickHouse không theo kịp tốc độ nhập liệu.
Bước 2: Kiểm tra CPU và I/O của ClickHouse.
clickhouse-client -q "SELECT name, value FROM system.metrics WHERE name LIKE '%Inserts%'"
Kết quả mong đợi: Nếu `Inserts` tăng chậm hoặc `InsertsTotal` không tăng trong khi Kafka lag tăng, ClickHouse bị nghẽn CPU hoặc Disk I/O.
Chiến lược Backup và Restore dữ liệu ClickHouse
Với dữ liệu Time-Series, backup truyền thống (mysqldump) không khả thi do dữ liệu quá lớn. ClickHouse sử dụng cơ chế file-based storage, cho phép backup bằng cách copy thư mục dữ liệu (ZFS snapshot hoặc rsync) và restore bằng cách copy ngược lại.
1. Cấu hình Backup bằng ClickHouse Keeper (Zookeeper) và ClickHouse Backup
Sử dụng công cụ `clickhouse-backup` để tự động hóa quá trình copy data vào S3 hoặc NFS.
Bước 1: Cài đặt `clickhouse-backup` trên máy chủ ClickHouse.
apt-get update && apt-get install -y clickhouse-backup
Kết quả mong đợi: Package được cài đặt thành công.
Bước 2: Cấu hình file `/etc/clickhouse-backup/config.yaml` để lưu vào S3.
[storage]
provider: S3
bucket: my-clickhouse-backup-bucket
region: us-east-1
access_key_id: YOUR_AWS_ACCESS_KEY
secret_access_key: YOUR_AWS_SECRET_KEY
[s3]
server_side_encryption: AES256
[retention]
keep_last: 7
keep_hourly: 24
keep_daily: 7
keep_weekly: 4
Kết quả mong đợi: File cấu hình sẵn sàng để backup tự động.
Bước 3: Chạy lệnh backup toàn bộ (Full) hoặc chỉ backup bảng cụ thể.
clickhouse-backup create full_backup_20231027
Kết quả mong đợi: Xuất hiện thông báo "Backup created successfully" và file nén được đẩy lên S3.
2. Restore dữ liệu từ Backup
Khi cần khôi phục dữ liệu bị mất hoặc lỗi, bạn restore từ backup đã tạo.
Bước 1: Liệt kê các backup có sẵn.
clickhouse-backup list
Kết quả mong đợi: Danh sách các backup với thời gian tạo và kích thước.
Bước 2: Restore toàn bộ hệ thống (khuyến nghị: chỉ thực hiện trên máy mới hoặc khi cần khôi phục toàn bộ).
clickhouse-backup restore full_backup_20231027
Kết quả mong đợi: Dữ liệu được giải nén và đặt lại vào `/var/lib/clickhouse/`. ClickHouse cần được restart để nhận diện lại dữ liệu.
Bước 3: Restore một bảng cụ thể (tốt cho recovery lỗi đơn lẻ).
clickhouse-backup restore full_backup_20231027 --only-tables "my_time_series_db.my_table"
Kết quả mong đợi: Chỉ bảng `my_table` được khôi phục, các bảng khác không bị ảnh hưởng.
Lời khuyên về Monitoring và Alerting cho hệ thống Production
Trong môi trường production, bạn không thể chờ đến khi lỗi xảy ra mới xem log. Cần thiết lập dashboard và alert pro-active để cảnh báo sớm các dấu hiệu bất thường.
1. Các chỉ số quan trọng cần giám sát (Key Metrics)
Thiết lập monitoring cho các chỉ số sau để đảm bảo hệ thống hoạt động ổn định.
- Kafka:
- Consumer Lag: Khoảng cách giữa offset producer và consumer. Nếu lag tăng liên tục, hệ thống đang bị nghẽn.
- Under Replicated Partitions: Số lượng partition bị mất replica. Nếu > 0, dữ liệu có nguy cơ mất.
- Vector:
- Events dropped: Số lượng sự kiện bị loại bỏ do buffer đầy hoặc lỗi.
- Bytes received/sent: Tốc độ dữ liệu vào/ra.
- ClickHouse:
- Inserts/sec: Tốc độ ghi dữ liệu.
- Query execution time: Thời gian thực hiện query (đặc biệt là query aggregate).
- Memory usage: Sử dụng RAM của server ClickHouse.
2. Cấu hình Alerting với Prometheus và Grafana
Sử dụng Exporter của Kafka và ClickHouse để đẩy metric vào Prometheus, sau đó thiết lập Alert trong Grafana.
Bước 1: Cài đặt ClickHouse Exporter để expose metrics.
# Thêm vào /etc/clickhouse-server/config.d/exporter.xml
/metrics
/status
Kết quả mong đợi: Truy cập `http://clickhost:9116/metrics` (port mặc định của exporter) thấy danh sách metric ClickHouse.
Bước 2: Cấu hình Alert Rule trong Prometheus (file `/etc/prometheus/prometheus.yml` hoặc trong UI).
groups:
- name: clickhouse_alerts
rules:
- alert: HighConsumerLag
expr: kafka_consumer_lag > 10000
for: 5m
labels:
severity: critical
annotations:
summary: "Kafka Consumer Lag cao ({{ $value }})"
description: "Consumer không theo kịp Producer trong {{ $labels.topic }}"
- alert: ClickHouseInsertSlow
expr: rate(clickhouse_inserts_total[5m]) < 100
for: 5m
labels:
severity: warning
annotations:
summary: "Tốc độ ghi dữ liệu ClickHouse giảm đột ngột"
Kết quả mong đợi: Khi lag vượt quá 10,000 message trong 5 phút, Prometheus sẽ trigger alert gửi về PagerDuty/Slack.
Bước 3: Tạo Dashboard Grafana để trực quan hóa.
# Ví dụ truy vấn PromQL để vẽ biểu đồ Lag
sum by (topic, consumer_group) (kafka_consumer_lag)
Kết quả mong đợi: Dashboard hiển thị biểu đồ trend của lag theo thời gian thực, giúp phát hiện sớm điểm nghẽn.
3. Chiến lược Log Rotation và Retention
Log của Vector và ClickHouse có thể phát triển rất nhanh và làm đầy disk.
Bước 1: Cấu hình log rotation cho ClickHouse trong `/etc/clickhouse-server/config.d/log_rotate.xml`.
information
/var/log/clickhouse-server/clickhouse-server.log
/var/log/clickhouse-server/clickhouse-server.err.log
100M
10
Kết quả mong đợi: Log file tự động được cắt (rotate) khi đạt 100MB, chỉ giữ lại 10 file mới nhất, đảm bảo disk không bị full.
Bước 2: Cấu hình log rotation cho Vector trong `/etc/vector/vector.toml`.
[internal_logging]
level = "info"
format = "json"
include_timestamp = true
Kết quả mong đợi: Log của Vector được quản lý bởi systemd journal, sử dụng lệnh `journalctl --vacuum-size=500M` để tự động dọn dẹp log cũ.
Bước 3: Chạy lệnh dọn dẹp log cũ định kỳ (cron job).
0 3 * * * journalctl --vacuum-size=500M
Kết quả mong đợi: Hệ thống tự động giải phóng dung lượng disk vào 3 giờ sáng mỗi ngày.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Data Streaming Time-Series với Kafka, ClickHouse và Vector
« Phần 8: Tối ưu hóa hiệu năng và scaling hệ thống