Sử dụng Proxy trong monitoring

1. Tổng quan.

Trong các hệ thống giám sát phân tán, việc sử dụng một thành phần proxy để thu thập và lưu trữ tạm thời dữ liệu từ các thiết bị hoặc dịch vụ trước khi gửi về máy chủ trung tâm là rất phổ biến. Những hệ thống như Zabbix cung cấp giải pháp Zabbix Proxy, giúp lưu trữ cục bộ dữ liệu metrics trong trường hợp mất kết nối với máy chủ giám sát chính và sau đó gửi dữ liệu lại khi kết nối được khôi phục. Điều này đảm bảo tính toàn vẹn dữ liệu, không bị mất mát do các sự cố về mạng.

Tương tự, các hệ thống như Prometheus và Cortex trong lĩnh vực monitoring metrics cũng có thể được triển khai theo kiến trúc phân tán, thu thập dữ liệu từ nhiều khu vực khác nhau, gửi về một cụm trung tâm để xử lý và lưu trữ. Mặc dù Prometheus không có tính năng proxy nội tại, nhưng cơ chế remote_write kết hợp với Cortex hoặc các giải pháp hàng đợi như Kafka có thể đảm bảo dữ liệu không bị mất khi gặp sự cố về mạng.

Telegraf, một agent phổ biến trong việc thu thập dữ liệu metrics, không có khả năng lưu trữ tạm thời trong thời gian dài, nhưng có thể được cấu hình với bộ đệm và tích hợp với các hệ thống lưu trữ hàng đợi (như Kafka) để giảm thiểu việc mất dữ liệu.

2. Zabbix Proxy.

Hình ảnh dưới đây mô tả mô hình giám sát của Zabbix với sự sử dụng Zabbix Proxy để thu thập dữ liệu từ các thiết bị ở các vị trí (site) từ xa và chuyển tiếp về Zabbix Server trung tâm. Đây là cách mà Zabbix triển khai giám sát phân tán trong môi trường với nhiều site.

Mô hình này giúp bạn giám sát phân tán các thiết bị tại nhiều vị trí địa lý khác nhau, với Proxy đảm bảo dữ liệu không bị mất khi mạng gián đoạn và giảm tải cho Zabbix Server trung tâm.

Giải thích các thành phần:

• Devices (Thiết bị giám sát):
  • Đây là các thiết bị hoặc hệ thống mà bạn muốn giám sát. Chúng có thể là máy chủ, thiết bị mạng, dịch vụ, hoặc bất kỳ đối tượng nào mà Zabbix có thể giám sát.
• Zabbix Proxy (Proxy 1, Proxy 2, Proxy 3):
  • Zabbix Proxy đóng vai trò trung gian giữa Zabbix Server và các thiết bị tại các site từ xa. Proxy sẽ thu thập dữ liệu từ các thiết bị và lưu trữ dữ liệu tạm thời.
  • Zabbix Proxy 1 có vẻ hoạt động trong central location cùng với Zabbix Server.
  • Zabbix Proxy 2 và Proxy 3 ở các remote location (vị trí từ xa A và B) và có thể được bảo vệ bởi các tường lửa (firewalls).
  • Proxy giúp giảm tải cho Zabbix Server, đồng thời giúp đảm bảo rằng dữ liệu không bị mất trong trường hợp kết nối mạng giữa Proxy và Zabbix Server bị gián đoạn. Khi kết nối mạng khôi phục, Proxy sẽ gửi lại dữ liệu về Zabbix Server.
• Zabbix Server:
  • Đây là thành phần trung tâm của hệ thống Zabbix. Nó nhận dữ liệu từ các proxy và lưu trữ trong cơ sở dữ liệu. Zabbix Server chịu trách nhiệm xử lý dữ liệu giám sát, cảnh báo khi có sự cố và hiển thị thông tin trên giao diện web (Frontend).
• Database:
  • Đây là nơi lưu trữ tất cả dữ liệu giám sát và cấu hình của Zabbix Server. Mỗi lần Zabbix Proxy hoặc Server nhận dữ liệu từ thiết bị, chúng sẽ ghi vào cơ sở dữ liệu này.
• Frontend:
  • Đây là giao diện web nơi người quản trị có thể xem dữ liệu giám sát, cấu hình thiết bị và tạo các báo cáo. Tất cả các thao tác quản lý và giám sát của Zabbix đều được thực hiện thông qua Frontend.

Quá trình hoạt động:

• Thu thập dữ liệu từ xa: Các Zabbix Proxy (Proxy 1, Proxy 2, Proxy 3) sẽ thu thập dữ liệu từ các thiết bị tại từng site của mình. Chúng hoạt động giống như một agent để lấy dữ liệu và lưu trữ tạm thời.
• Chuyển tiếp dữ liệu: Zabbix Proxy sẽ chuyển tiếp dữ liệu này về Zabbix Server ở central location. Nếu mạng giữa Proxy và Server bị gián đoạn, Proxy sẽ lưu dữ liệu và chờ đến khi kết nối trở lại để gửi đi.
• Xử lý và lưu trữ: Zabbix Server nhận dữ liệu từ các proxy, xử lý chúng, lưu trữ trong cơ sở dữ liệu và hiển thị thông qua Frontend.

Ưu điểm của mô hình:

• Giảm tải cho Zabbix Server: Các Proxy giúp phân tán công việc thu thập dữ liệu, giảm tải cho server chính và giúp giám sát hệ thống quy mô lớn dễ dàng hơn.
• Bảo vệ dữ liệu khi mất kết nối mạng: Nếu kết nối mạng giữa site từ xa và server bị mất, Proxy vẫn có thể lưu trữ dữ liệu tạm thời và gửi lại khi kết nối được phục hồi, đảm bảo không mất dữ liệu giám sát.
• Quản lý tường lửa dễ dàng: Zabbix Proxy có thể hoạt động ở các site có tường lửa, chỉ cần một kết nối từ Proxy đến Server, giúp dễ dàng cấu hình mạng và bảo mật.

2. Prometheus với Remote Write và Federation.

Trong Prometheus và InfluxDB, không có khái niệm proxy tương tự như Zabbix Proxy một cách trực tiếp, nhưng cả hai hệ thống đều có các giải pháp tương tự để phân phối dữ liệu thu thập từ nhiều nguồn về một điểm trung tâm. Dưới đây là một số giải pháp tương đương:

• Prometheus Agent hoặc Server tại mỗi site: Mỗi site sẽ có một Prometheus server (hoặc có thể sử dụng Prometheus agent mode để chỉ thu thập dữ liệu mà không lưu trữ cục bộ). Server này sẽ lưu trữ dữ liệu metric cục bộ.
• Mất kết nối mạng giữa site và server chính: Khi có sự cố mạng giữa Prometheus server tại site và Prometheus server chính hoặc hệ thống lưu trữ trung tâm, dữ liệu vẫn sẽ được lưu trữ tại Prometheus server cục bộ.
• Khi mạng hoạt động lại: Sau khi kết nối mạng được khôi phục, Prometheus server tại site sẽ tiếp tục gửi dữ liệu (nếu dùng remote write) hoặc Prometheus server chính sẽ lấy lại dữ liệu bằng Federation. Vì dữ liệu đã được lưu trữ cục bộ, nên không có metric nào bị mất trong thời gian mạng bị đứt.
• Cách bảo vệ dữ liệu cục bộ: Prometheus server tại mỗi site sẽ lưu trữ các metric cục bộ trong khoảng thời gian nhất định (tùy thuộc vào dung lượng ổ đĩa và cấu hình retention của bạn). Trong thời gian đó, server chính có thể thu thập lại dữ liệu khi mạng được phục hồi.

Quan sát tham khảo mô hình dưới đây, bạn thấy mô hình sử dụng Cortex trong hệ thống giám sát với các vùng (region) khác nhau.

Mô hình này tương tự như kiến trúc phân tán của Zabbix Proxy, nhưng sử dụng Prometheus và Cortex để thu thập, xử lý và lưu trữ dữ liệu metrics từ nhiều vùng khác nhau, với một cụm trung tâm tập trung xử lý và quản lý.

Các thành phần chính của nó sẽ như sau:

• Central Cortex Cluster (Cụm Cortex trung tâm):
  • Cortex là một hệ thống thu thập và lưu trữ Prometheus metrics phân tán, có khả năng mở rộng lớn. Cụm Cortex này đóng vai trò là trung tâm, nơi dữ liệu từ các vùng (region) khác nhau sẽ được thu thập, lưu trữ và xử lý.
  • Dữ liệu metrics từ tất cả các vùng (ví dụ: eu-west-1, us-central-1, asia-east-1) sẽ được đẩy về cụm Cortex trung tâm để phân tích, hiển thị trên Grafana hoặc các công cụ khác.
• Các vùng địa lý (eu-west-1, us-central-1, asia-east-1):
  • Mỗi vùng (region) đại diện cho một khu vực địa lý riêng biệt và có một cụm hạ tầng riêng để thu thập và xử lý dữ liệu cục bộ. Các vùng này có thể là các cụm Kubernetes hoặc các hạ tầng đám mây khác nhau.
  • Trong mô hình, các vùng này được cấu trúc để thu thập dữ liệu từ các dịch vụ và hệ thống ở từng khu vực, sau đó gửi dữ liệu metrics về cụm Cortex trung tâm.
• Prometheus.
  • Tại mỗi vùng, Prometheus đóng vai trò là hệ thống thu thập dữ liệu metrics từ các dịch vụ và ứng dụng cục bộ.
  • Prometheus thu thập dữ liệu từ các thiết bị và dịch vụ (như Nginx, ứng dụng cục bộ, cơ sở dữ liệu, v.v.) và có thể tạm thời lưu trữ metrics cục bộ trước khi đẩy chúng về cụm Cortex trung tâm.
  • Prometheus có thể được cấu hình với remote_write để gửi dữ liệu đến Cortex.
• Các dịch vụ được monitoring
  • Nginx là một thành phần trong hạ tầng, có thể đại diện cho các dịch vụ mà Prometheus đang giám sát.
  • Các ứng dụng, cơ sở dữ liệu và dịch vụ trong từng vùng cũng sẽ được giám sát bằng Prometheus. Prometheus sẽ thu thập dữ liệu từ các nguồn này (ví dụ: sử dụng exporters hoặc qua trực tiếp các API).

Quá trình hoạt động:

• Thu thập dữ liệu: Mỗi vùng (region) có một hệ thống Prometheus để thu thập dữ liệu metrics từ các dịch vụ cục bộ như Nginx, cơ sở dữ liệu, và các ứng dụng khác.
• Gửi dữ liệu về Cortex trung tâm: Các instance Prometheus tại mỗi vùng sử dụng cơ chế remote write để đẩy dữ liệu metrics về cụm Cortex trung tâm. Cortex sẽ xử lý, lưu trữ và phân tích dữ liệu này.
• Phân tích và hiển thị: Dữ liệu metrics được xử lý bởi cụm Cortex trung tâm có thể được hiển thị trên các công cụ như Grafana để theo dõi, phân tích, và cảnh báo.

Ưu điểm của mô hình này:

• Phân tán và mở rộng: Prometheus tại mỗi vùng đảm bảo việc thu thập dữ liệu cục bộ mà không phải phụ thuộc vào cụm trung tâm ngay lập tức. Cortex trung tâm đảm nhận nhiệm vụ lưu trữ và xử lý dữ liệu lớn, có thể mở rộng dễ dàng.
• Giám sát nhiều vùng địa lý: Mô hình này phù hợp cho các tổ chức có hạ tầng phân tán ở nhiều khu vực địa lý khác nhau, cho phép giám sát toàn diện.
• Khả năng phục hồi: Nếu kết nối giữa các vùng và cụm trung tâm bị gián đoạn, Prometheus tại các vùng có thể tiếp tục thu thập dữ liệu và gửi về khi kết nối được khôi phục.
• Tối ưu hóa dữ liệu: Các instance Prometheus cục bộ giảm tải cho hệ thống trung tâm, vì chúng có thể xử lý và nén dữ liệu trước khi gửi đi.

3. Telegraf với InfluxDB.

Telegraf là giải pháp tương tự như Zabbix Proxy trong InfluxDB. Telegraf là một agent thu thập và gửi dữ liệu tới InfluxDB. Bạn có thể chạy Telegraf trên các hệ thống từ xa, và nó sẽ đẩy dữ liệu đến InfluxDB server chính.

Telegraf tại mỗi site: Mỗi site sẽ có một instance của Telegraf hoạt động như một agent. Nó sẽ thu thập các metric cục bộ và gửi tới InfluxDB server chính.

Mất kết nối mạng giữa site và server chính: Khi mạng bị đứt, Telegraf sẽ lưu trữ dữ liệu tạm thời cục bộ (tùy thuộc vào cấu hình buffer). Dữ liệu sẽ không bị mất mà sẽ nằm tại buffer của Telegraf.

Khi có sự cố về kết nối mạng hoặc mất kết nối đến hệ thống đích, Telegraf không có cơ chế tích hợp sẵn để lưu trữ tạm thời dữ liệu để gửi lại sau khi kết nối khôi phục. Tuy nhiên, bạn có thể sử dụng các giải pháp sau để bổ sung tính năng lưu trữ tạm thời cho Telegraf:

• Cơ chế Output Buffering (Bộ đệm đầu ra):
  • Telegraf có thể sử dụng tính năng buffering ở mức output, có thể được cấu hình bằng cách sử dụng các tham số như flush_interval, metric_batch_size và metric_buffer_limit. Điều này giúp Telegraf giữ lại một lượng nhỏ dữ liệu trong bộ nhớ tạm nếu kết nối bị gián đoạn. Tuy nhiên, nếu bộ đệm này đầy hoặc nếu Telegraf bị tắt, dữ liệu vẫn sẽ bị mất.

Ví dụ, cấu hình buffer trong Telegraf:

[[outputs.influxdb]]
  urls = ["http://localhost:8086"]
  database = "metrics"
  metric_batch_size = 1000
  metric_buffer_limit = 10000

Sử dụng hệ thống hàng đợi (Queue System):

Một giải pháp mạnh mẽ hơn là cấu hình Telegraf gửi dữ liệu đến các hệ thống hàng đợi như Kafka hoặc Redis trước khi đẩy dữ liệu đến đích cuối cùng. Các hệ thống này có khả năng lưu trữ dữ liệu tạm thời và đảm bảo việc gửi lại khi kết nối khôi phục.

Ví dụ, Telegraf có plugin output cho Kafka, và bạn có thể cấu hình nó để Telegraf gửi dữ liệu tới Kafka, nơi dữ liệu được lưu tạm trước khi chuyển tới hệ thống chính.

Khi mạng hoạt động lại: Telegraf sẽ gửi lại các dữ liệu đã thu thập trong thời gian mạng bị mất kết nối về InfluxDB server chính. Như vậy, InfluxDB vẫn có được đầy đủ các metric mà không bị gián đoạn.

4. So sánh với Zabbix Proxy.

Zabbix Proxy hoạt động với cơ chế tương tự: nó thu thập dữ liệu từ các agent (hoặc thiết bị) tại site, lưu tạm thời nếu không thể gửi được về Zabbix Server do lỗi mạng, và khi kết nối trở lại, nó sẽ đẩy dữ liệu đã lưu về server chính.

Với Prometheus và InfluxDB, mặc dù không có khái niệm “proxy” y hệt, nhưng cách các hệ thống này hoạt động vẫn đảm bảo dữ liệu metric không bị mất khi có sự cố mạng, tương tự như Zabbix Proxy.

5. Kết luận.

Sử dụng proxy hoặc các thành phần tương tự trong hệ thống giám sát phân tán là một cách tiếp cận hiệu quả để đảm bảo tính toàn vẹn và liên tục của dữ liệu khi có sự cố về kết nối mạng. Mỗi giải pháp (Zabbix Proxy, Prometheus với Cortex, hoặc Telegraf kết hợp Kafka) đều có ưu và nhược điểm riêng, và việc chọn lựa phụ thuộc vào yêu cầu về độ tin cậy, khả năng mở rộng, và tính chất phân tán của hệ thống.

• Prometheus có thể lưu trữ cục bộ tại mỗi site và khi kết nối mạng khôi phục, server chính có thể tiếp tục thu thập đầy đủ dữ liệu thông qua remote write hoặc federation.
• Telegraf có thể lưu trữ tạm thời trong buffer cục bộ khi kết nối mạng bị mất, và sau đó gửi lại dữ liệu cho InfluxDB server khi mạng hoạt động trở lại.

Trong cả hai trường hợp, dữ liệu không bị mất trong thời gian gián đoạn mạng, giống như cơ chế của Zabbix Proxy.