Dọn dẹp ổ cứng đầu năm & hiểu thêm về ClickHouse log

Posted on: 2/3/2025 1:49:00 PM

Ngày đầu tiên đi làm trở lại sau tết, dính ngay vấn đề ổ cứng server chứa clickhouse bị full. OK, không lòng vòng bắt tay vào tìm hiểu nguyên nhân luôn.

Tìm thư mục nào đang chiếm file dung lượng lớn

sudo du -h --max-depth=1 -t 1G /var/log | sort -n | tail -10

Ở đây anh em có thể thay:

• 1G thành 10G hoặc giới hạn dung lượng mà anh em muốn lọc
• /var/log là thư mục muốn quét.

Lệnh trên mục đích chung là để biết thư mục nào chứa file nặng để xóa.

Sau khi chạy thì mình thấy thư mục /home/clickhouse chiếm đến 1.9TB/ tổng số 2TB ổ cứng.

Kiểm tra bảng nặng trong clickhouse

SELECT
 database,
 table,
 formatReadableSize(sum(bytes)) AS size
FROM system.parts
WHERE active
GROUP BY
 database,
 table
ORDER BY sum(bytes) DESC

Wow, xuất hiện bảng opentelemetry_span_log  chiếm tới 1.7TB 😁😁😁. Ngoài ra còn 1 số bảng khác như: trace_log, query_log, asynchronous_metric_log, metric_log, part_log, query_views_log cũng chiếm 1 dung lượng kha khá.

==> Nghĩ ngay việc cần làm là xóa mấy bảng này vì nó chả liên quan gì đến nghiệp vụ của mình. Vậy bảng này để làm gì?

opentelemetry_span_log  

Bảng opentelemetry_span_log trong ClickHouse là một trong những bảng log được sử dụng để lưu trữ các thông tin liên quan đến tracing spans khi tích hợp với OpenTelemetry – một tiêu chuẩn mở nhằm thu thập dữ liệu giám sát (observability) bao gồm traces, metrics và logs.

• Mục đích sử dụng

  • Ghi nhận tracing spans:
    Mỗi "span" đại diện cho một đơn vị công việc hoặc một hoạt động (operation) trong hệ thống phân tán. Bảng opentelemetry_span_log lưu trữ các thông tin của các span này, cho phép anh em truy vết (trace) hành trình của một yêu cầu khi nó đi qua nhiều dịch vụ hoặc thành phần.
  • Giám sát và debug:
    Thông qua các thông tin của span, anh em có thể theo dõi hiệu năng của từng phần trong hệ thống, xác định điểm nghẽn (bottleneck) hoặc phát hiện lỗi, từ đó hỗ trợ việc tối ưu hóa và xử lý vấn đề.

• Các thông tin thường được lưu trữ
  Mặc dù cấu trúc chính xác có thể thay đổi theo phiên bản hoặc cấu hình, các trường dữ liệu thường gặp trong opentelemetry_span_log bao gồm:

  • trace_id: Nhận dạng duy nhất cho toàn bộ trace, giúp liên kết tất cả các span thuộc cùng một trace.
  • span_id: Nhận dạng duy nhất của span hiện tại.
  • parent_span_id: Nếu span hiện tại được sinh ra từ một span khác, trường này sẽ lưu id của span cha.
  • start_time: Thời điểm bắt đầu của span.
  • duration: Thời gian thực hiện của span.
  • operation_name: Tên của hoạt động hoặc tác vụ mà span đại diện.
  • tags/attributes: Các nhãn hoặc thuộc tính bổ sung, giúp cung cấp ngữ cảnh như tên dịch vụ, thông tin về môi trường, trạng thái, v.v.

• Khi nào thì dùng?

  • Theo dõi hành trình của yêu cầu: Giúp anh em hiểu rõ hơn về cách thức các yêu cầu di chuyển qua các dịch vụ và thành phần của hệ thống.
  • Phân tích hiệu năng: Cho phép phát hiện các điểm chậm trễ hoặc lỗi trong hệ thống phân tán, từ đó tối ưu hóa hiệu năng.
  • Tích hợp với các công cụ observability: Dữ liệu từ bảng opentelemetry_span_log có thể được sử dụng kết hợp với các công cụ trực quan hóa và phân tích như Jaeger, Zipkin hoặc các giải pháp dashboard nội bộ khác.

• Cấu hình và quản lý

  • Retention (Thời gian lưu trữ): Do lượng dữ liệu traces có thể rất lớn, việc cấu hình thời gian lưu trữ hợp lý cho bảng này là cần thiết để tránh lãng phí tài nguyên lưu trữ.
  • Sampling (Lấy mẫu): Trong một số trường hợp, để giảm tải ghi log, hệ thống có thể áp dụng cơ chế lấy mẫu (sampling) cho các spans. Điều này giúp chỉ lưu lại một phần các span thay vì lưu toàn bộ, đảm bảo hiệu năng của hệ thống.

• Ứng dụng thực tế

  • Khi hệ thống của anh em gặp phải các vấn đề về hiệu năng hoặc lỗi bất thường, anh em có thể truy vấn bảng opentelemetry_span_log để xem xét chuỗi các hoạt động được ghi nhận qua các spans.
  • Ví dụ, anh em có thể truy vấn các spans của một trace cụ thể để kiểm tra thời gian thực hiện của từng bước, từ đó xác định vị trí có thể xảy ra sự cố.

Đã hiểu thêm về nó, vậy xóa dữ liệu bằng cách nào?

Mặc định thì Clickhouse sẽ không cho drop bảng có dụng lượng lớn hơn 50GB. Đầu tiên cần tạo 1 cờ cho phép xóa bảng

sudo touch /home/clickhouse/flags/force_drop_table

File /home/clickhouse/flags/force_drop_table được sử dụng như một “công tắc” báo hiệu cho ClickHouse rằng anh em đã nhận thức được việc xóa dữ liệu lớn và muốn thực hiện hành động đó. Khi file này tồn tại, hệ thống sẽ bỏ qua cơ chế bảo vệ kích thước và cho phép thực hiện lệnh DROP TABLE ngay cả khi bảng có dung lượng trên 50GB.

Ok, giờ drop bảng bình thường.

DROP TABLE opentelemetry_span_log;

Anh em có thể cấu hình tắt các bảng log bằng cách sau:

$ cat /etc/clickhouse-server/config.d/z_log_disable.xml
<?xml version="1.0"?>
<clickhouse>
    <asynchronous_metric_log remove="1"/>
    <backup_log remove="1"/>
    <error_log remove="1"/>
    <metric_log remove="1"/>
    <query_thread_log remove="1" />  
    <query_log remove="1" />
    <query_views_log remove="1" />
    <part_log remove="1"/>
    <session_log remove="1"/>
    <text_log remove="1" />
    <trace_log remove="1"/>
    <crash_log remove="1"/>
    <opentelemetry_span_log remove="1"/>
    <zookeeper_log remove="1"/>
    <processors_profile_log remove="1"/>
</clickhouse>

Tất nhiên, anh em cần restart ClickHouse server để hệ thống cập nhật cấu hình.

Ở file trên, anh em thấy ClickHouse có rất nhiều loại log giúp anh em dễ dàng theo dõi để tối ưu hệ thống cũng như tìm lỗi. Cùng hiểu thêm tí về các loại log:

Các loại log system của ClickHouse

• system.query_log

  • Mục đích: Lưu trữ thông tin về các truy vấn được thực thi trên server.
  • Nội dung lưu trữ: Bao gồm thời gian bắt đầu và kết thúc của truy vấn, query ID, nội dung truy vấn, trạng thái thực hiện, số liệu thống kê (như số dòng đọc, số dòng ghi, thời gian thực thi, v.v.), thông tin lỗi (nếu có), và nhiều thông tin hữu ích khác.
  • Ứng dụng: Giúp quản trị viên theo dõi lịch sử truy vấn, phân tích hiệu năng, phát hiện truy vấn chậm, và debug các vấn đề liên quan đến truy vấn.

• system.part_log

  • Mục đích: Ghi lại các hoạt động liên quan đến việc xử lý các phần (parts) của table như merge, insert, và các sự kiện liên quan đến replication.
  • Nội dung lưu trữ: Thông tin về các thao tác trên parts (ví dụ: số lượng parts được merge, thời gian merge, các thao tác liên quan đến lưu trữ dữ liệu).
  • Ứng dụng: Hữu ích trong việc giám sát các hoạt động nội bộ của engine lưu trữ, phát hiện các vấn đề về merge hoặc replication, và tối ưu hóa hiệu năng lưu trữ.

• system.metric_log

  • Mục đích: Lưu trữ các số liệu đo lường (metrics) của hệ thống theo thời gian.
  • Nội dung lưu trữ: Bao gồm các chỉ số như tải CPU, số lượng truy vấn đang chạy, số lượng kết nối, lưu lượng dữ liệu, và các số liệu thống kê hệ thống khác.
  • Ứng dụng: Giúp theo dõi tình trạng sức khỏe của server, hỗ trợ việc giám sát và cảnh báo khi có sự cố hoặc khi tài nguyên hệ thống vượt ngưỡng cho phép.

• system.text_log

  • Mục đích: Lưu trữ các log dạng text được sinh ra bởi hệ thống, như thông báo lỗi, cảnh báo, hoặc các thông tin sự kiện khác không nằm trong các log chuyên biệt nêu trên.
  • Nội dung lưu trữ: Các thông báo từ hệ thống, log về việc khởi động, tắt server, và các thông báo khác mà anh em có thể cần để debug hoặc theo dõi các sự kiện bất thường.
  • Ứng dụng: Dùng để theo dõi các sự kiện hệ thống chung, cung cấp thông tin hỗ trợ khi xử lý lỗi hoặc khi cần kiểm tra hoạt động của server.

Một số điểm cần lưu ý

• Thời gian lưu trữ log: Một số bảng log như system.query_log và system.metric_log thường được cấu hình để lưu trữ dữ liệu trong một khoảng thời gian nhất định (ví dụ: vài ngày đến vài tuần) nhằm tránh việc tích lũy dữ liệu quá lớn. Anh em có thể cấu hình thông số lưu trữ log trong file cấu hình của ClickHouse.
• Hiệu năng: Việc ghi log có thể ảnh hưởng đến hiệu năng nếu mức độ log quá cao, do đó cần cân nhắc cấu hình mức độ log phù hợp với nhu cầu giám sát mà không gây ảnh hưởng xấu đến hoạt động của hệ thống.
• Truy vấn log: Các bảng log của ClickHouse thường nằm trong database system, và anh em có thể truy vấn trực tiếp các bảng này để lấy thông tin theo nhu cầu của anh em. Ví dụ:

SELECT query, event_time, query_duration_ms
FROM system.query_log
WHERE event_time >= now() - INTERVAL 1 DAY
ORDER BY event_time DESC
LIMIT 10;

Tóm lại, các bảng log của ClickHouse cung cấp một bộ công cụ mạnh mẽ cho việc giám sát, phân tích và debug hoạt động của hệ thống, giúp anh em nắm bắt được hiệu năng, xử lý lỗi và tối ưu hóa việc vận hành server một cách hiệu quả. Tuy nhiên cũng cần chú ý đừng để hết ổ cứng như mình 😂😂😂😂😂😂

Tham khảo

• https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-system-tables-eat-my-disk/