SigNoz là một hệ thống giám sát và theo dõi phân tán dựa trên OpenTelemetry, cung cấp khả năng theo dõi hiệu suất và log của các ứng dụng phân tán. Dưới đây là cơ chế hoạt động của SigNoz và cách nó thu thập, xử lý, và hiển thị dữ liệu từ các dịch vụ của bạn:

SigNoz có một kiến trúc gồm nhiều thành phần chính:

• Ứng dụng phân tán (Distributed Applications): Đây là các ứng dụng mà bạn đang theo dõi, bao gồm các dịch vụ microservices hoặc các ứng dụng lớn.
• OpenTelemetry SDK: Mỗi ứng dụng cần phải tích hợp SDK của OpenTelemetry để thu thập traces, metrics, và logs.
• SigNoz Collector: Đây là thành phần thu thập dữ liệu từ các ứng dụng thông qua giao thức OTLP (OpenTelemetry Protocol). SigNoz Collector xử lý dữ liệu thu thập được và gửi đến hệ thống lưu trữ.
• Cơ sở dữ liệu:
  • ClickHouse: Dùng để lưu trữ các dữ liệu trace và metrics hiệu năng.
  • Kafka (tùy chọn): Một hệ thống nhắn tin dùng để xử lý dữ liệu theo thời gian thực giữa các thành phần.
• SigNoz Backend: Đảm nhận việc xử lý dữ liệu truy vấn từ cơ sở dữ liệu và cung cấp API cho giao diện người dùng (dashboard).
• SigNoz Frontend: Dashboard cho phép người dùng theo dõi các dịch vụ và sự kiện theo thời gian thực.

• Instrumentation: Bạn cần tích hợp OpenTelemetry SDK vào ứng dụng của mình (có thể là ứng dụng PHP, Node.js, Python, Java, v.v.) để thu thập dữ liệu theo dõi.
• Traces: OpenTelemetry sẽ thu thập traces từ các yêu cầu HTTP, truy vấn cơ sở dữ liệu, xử lý sự kiện và các hành động quan trọng trong hệ thống của bạn.
• Metrics: OpenTelemetry cũng có thể thu thập metrics liên quan đến hiệu năng, ví dụ như độ trễ (latency), tỷ lệ lỗi, số lượng yêu cầu, v.v.

• Ứng dụng gửi dữ liệu trace, metrics và logs đến Collector: Dữ liệu này được gửi qua giao thức OTLP tới SigNoz Collector thông qua endpoint (ví dụ: http://localhost:4318/v1/traces).
• Xử lý dữ liệu trong Collector: SigNoz Collector nhận dữ liệu này và có thể xử lý, lọc, hoặc chuyển đổi dữ liệu nếu cần trước khi gửi đến hệ thống lưu trữ.

• ClickHouse: Dữ liệu trace và metrics được gửi tới ClickHouse, một cơ sở dữ liệu hiệu năng cao dành cho việc xử lý lượng lớn dữ liệu theo thời gian thực.
• Kafka (tùy chọn): Trong một số triển khai, Kafka có thể được sử dụng để luân chuyển dữ liệu từ Collector sang ClickHouse.

• Giao diện người dùng (Dashboard): SigNoz Frontend là nơi hiển thị dữ liệu cho người dùng, bao gồm các trace, metrics, và logs. Người dùng có thể xem chi tiết về các request, dịch vụ và sự kiện cụ thể trong hệ thống, và tìm hiểu nguyên nhân gốc rễ của các vấn đề về hiệu năng.
• Phân tích chi tiết: SigNoz cho phép bạn phân tích từng trace chi tiết với các span, event, và các thuộc tính liên quan đến mỗi hành động trong hệ thống.
• Cảnh báo (Alerting): SigNoz cũng hỗ trợ hệ thống cảnh báo để thông báo cho người dùng khi phát hiện các sự cố dựa trên các ngưỡng đã cấu hình sẵn.

• Bước 1: OpenTelemetry SDK được tích hợp vào các ứng dụng của bạn (Laravel, Node.js, Go, v.v.).
• Bước 2: Ứng dụng tạo ra traces, metrics, và logs trong quá trình hoạt động (như xử lý yêu cầu HTTP, truy vấn cơ sở dữ liệu, v.v.).
• Bước 3: OpenTelemetry Collector nhận dữ liệu này và gửi đến cơ sở dữ liệu ClickHouse.
• Bước 4: Người dùng có thể truy cập dashboard của SigNoz để xem các trace, metrics và logs theo thời gian thực.
• Bước 5: Sử dụng dashboard để phân tích nguyên nhân gốc rễ của các vấn đề về hiệu suất hoặc lỗi.

• Theo dõi phân tán: Hỗ trợ theo dõi các ứng dụng phân tán, đặc biệt là các hệ thống microservices.
• Tích hợp với OpenTelemetry: Sử dụng OpenTelemetry, một tiêu chuẩn mở để thu thập dữ liệu theo dõi mà không bị ràng buộc vào một công cụ giám sát cụ thể.
• Lưu trữ dữ liệu hiệu quả: Sử dụng ClickHouse để lưu trữ dữ liệu theo thời gian thực với hiệu suất cao.
• Khả năng phân tích chi tiết: Hỗ trợ xem trace chi tiết, bao gồm các event và span liên quan, giúp bạn dễ dàng tìm ra điểm gây nghẽn trong hệ thống.

Việc gửi dữ liệu trace, metrics, và logs đến OpenTelemetry Collector trong quá trình giám sát ứng dụng có thể có ảnh hưởng nhỏ đến hiệu năng, nhưng OpenTelemetry và SigNoz được thiết kế để giảm thiểu tối đa tác động này. Mức độ ảnh hưởng phụ thuộc vào nhiều yếu tố như cách bạn cấu hình OpenTelemetry SDK, khối lượng dữ liệu giám sát, và cách thức truyền tải dữ liệu.

• Overhead của OpenTelemetry SDK: Khi tích hợp OpenTelemetry vào ứng dụng, SDK sẽ thu thập dữ liệu theo dõi (trace, metrics) trong quá trình xử lý các yêu cầu hoặc công việc. Điều này thêm một chút tải (overhead) vì mỗi yêu cầu sẽ được ghi lại thông qua các span và event.
  • Tuy nhiên, OpenTelemetry SDK được tối ưu để hoạt động với chi phí thấp, sử dụng non-blocking I/O và các cơ chế đệm (buffering) để hạn chế ảnh hưởng đến hiệu suất của ứng dụng.
• Gửi dữ liệu trace, metrics và logs: Việc gửi dữ liệu tới OpenTelemetry Collector sử dụng các giao thức như HTTP/OTLP (giao thức OpenTelemetry) và thường được thực hiện theo kiểu asynchronous (bất đồng bộ), giúp giảm thiểu sự chậm trễ trong xử lý chính của ứng dụng.
  • Dữ liệu thường được ghi vào bộ đệm và gửi theo lô (batch), thay vì gửi từng sự kiện riêng lẻ, giúp giảm tải mạng và CPU trong quá trình truyền tải.

Một số yếu tố có thể ảnh hưởng đến hiệu năng ứng dụng khi tích hợp SigNoz và OpenTelemetry:

• Tần suất thu thập dữ liệu: Nếu bạn thu thập rất nhiều dữ liệu hoặc theo dõi mọi yêu cầu chi tiết, điều này có thể gây ra tải lớn cho hệ thống. Bạn nên chỉ thu thập dữ liệu cần thiết.
• Cấu hình sampling (lấy mẫu): OpenTelemetry hỗ trợ cơ chế sampling để quyết định có nên thu thập và gửi toàn bộ trace không. Với sampling rate phù hợp, bạn có thể chỉ thu thập một phần nhỏ trong số các yêu cầu để theo dõi mà vẫn đảm bảo chất lượng giám sát. Điều này giúp giảm tải đáng kể.
  • Ví dụ: Bạn có thể chỉ lấy mẫu 1% các yêu cầu thay vì theo dõi toàn bộ, giúp giảm tác động đến hiệu năng mà vẫn cung cấp đủ dữ liệu để phân tích.
• Batching và truyền tải: OpenTelemetry sử dụng cơ chế batching (gom nhóm) dữ liệu trước khi gửi đến Collector. Điều này giúp giảm tần suất truyền dữ liệu và do đó giảm thiểu tác động đến ứng dụng.
  • Bạn có thể cấu hình số lượng dữ liệu trong mỗi lô (batch size) và tần suất gửi để tối ưu hóa việc truyền tải.
• Khối lượng và độ chi tiết của dữ liệu: Việc thu thập quá nhiều span, event, hoặc các attribute không cần thiết có thể tạo ra nhiều dữ liệu hơn cần thiết, ảnh hưởng đến cả hiệu năng ứng dụng và khả năng xử lý của Collector. Hãy cân nhắc chỉ theo dõi các sự kiện quan trọng.

Có một số phương pháp để giảm thiểu tác động của việc thu thập dữ liệu lên hiệu năng ứng dụng:

• Cấu hình sampling hợp lý: Điều chỉnh sampling rate để chỉ thu thập những trace quan trọng hoặc những trace liên quan đến lỗi và sự cố hiệu suất. Ví dụ: bạn có thể thiết lập một tỷ lệ sampling thấp hơn để tránh thu thập quá nhiều dữ liệu không cần thiết.
• Gom nhóm và truyền dữ liệu theo lô: Tăng kích thước của lô dữ liệu và giảm tần suất truyền dữ liệu sẽ giảm tải mạng và tác động đến ứng dụng.
• Tối ưu hóa số lượng span và event: Chỉ tạo span và event cho những phần quan trọng của luồng xử lý, tránh việc theo dõi quá chi tiết những phần không cần thiết.
• Sử dụng collector: Đảm bảo rằng bạn đang gửi dữ liệu tới một OpenTelemetry Collector nằm gần ứng dụng của bạn (ví dụ: cùng mạng hoặc cùng máy chủ) để giảm thiểu độ trễ và chi phí truyền tải dữ liệu.

Mục tiêu của việc sử dụng OpenTelemetry và SigNoz là để thu thập dữ liệu có giá trị về hiệu năng và tình trạng ứng dụng mà không ảnh hưởng quá nhiều đến chính hiệu năng của ứng dụng. Dưới đây là một số cân nhắc để đạt được sự cân bằng này:

• Chỉ giám sát những gì quan trọng: Thay vì thu thập tất cả dữ liệu có thể, hãy tập trung vào việc theo dõi các phần chính của ứng dụng như các giao dịch quan trọng, các request chính, và các dịch vụ có thể gặp vấn đề về hiệu suất.
• Theo dõi vấn đề theo thời gian thực: Sử dụng SigNoz để phát hiện và phân tích vấn đề hiệu suất, từ đó có thể tối ưu hóa việc giám sát một cách hợp lý.

• Tác động về CPU và Memory: OpenTelemetry SDK và SigNoz Collector có thể sử dụng một chút CPU và bộ nhớ để thu thập và truyền dữ liệu. Tuy nhiên, với cấu hình hợp lý (batching và sampling), tác động này có thể không đáng kể trong hầu hết các ứng dụng.
• Tác động về băng thông mạng: Dữ liệu trace và metrics được truyền qua mạng, vì vậy nếu bạn thu thập một lượng lớn dữ liệu, điều này có thể gây ra một chút tải mạng. Tuy nhiên, việc truyền theo lô giúp giảm số lần gửi và tiết kiệm băng thông.

Khi sử dụng OpenTelemetry để gửi dữ liệu (traces, metrics, logs) từ ứng dụng tới Collector, có hai giao thức chính thường được sử dụng là HTTP và gRPC. Cả hai đều có thể truyền dữ liệu qua giao thức OTLP (OpenTelemetry Protocol), nhưng chúng khác nhau về cơ chế hoạt động, hiệu suất, và một số khía cạnh kỹ thuật. Dưới đây là sự khác nhau giữa hai phương pháp này:

• HTTP (HyperText Transfer Protocol): Là giao thức truyền tải tiêu chuẩn, phổ biến, không trạng thái. Dữ liệu được truyền qua các request và response độc lập, với mỗi yêu cầu HTTP đều có chi phí khởi tạo kết nối.
• gRPC (gRPC Remote Procedure Calls): Là một giao thức RPC (Remote Procedure Call) hiện đại, hiệu quả, dựa trên HTTP/2 và sử dụng Protocol Buffers (protobuf) để định dạng dữ liệu. gRPC có khả năng duy trì kết nối lâu dài giữa client và server, hỗ trợ truyền dữ liệu song song (bi-directional streaming).

• Tính tương thích: HTTP là giao thức phổ biến, dễ tích hợp với nhiều hệ thống và không yêu cầu cấu hình đặc biệt.
• Hệ thống đơn giản: Nếu ứng dụng của bạn nhỏ hoặc không yêu cầu xử lý dữ liệu phức tạp, HTTP có thể là lựa chọn phù hợp do dễ sử dụng và thiết lập.
• Yêu cầu đơn giản: Nếu bạn chỉ cần gửi các request đơn lẻ, không cần kết nối liên tục hoặc truyền dữ liệu theo thời gian thực.
• Vượt qua tường lửa: HTTP dễ vượt qua các cấu hình firewall, proxy do nó được hỗ trợ rộng rãi và không yêu cầu cấu hình đặc biệt.

• Hiệu năng cao: Nếu hệ thống của bạn cần gửi nhiều dữ liệu với độ trễ thấp và hiệu suất cao, gRPC là lựa chọn tốt nhất.
• Streaming: Nếu bạn cần truyền tải dữ liệu liên tục theo thời gian thực (ví dụ: streaming logs, metrics), gRPC hỗ trợ truyền dữ liệu song song và liên tục tốt hơn nhiều so với HTTP.
• Ứng dụng phân tán lớn: Với các hệ thống microservices lớn, gRPC giúp cải thiện hiệu suất và giảm độ trễ do cơ chế kết nối lâu dài và giao thức nhị phân.
• Sử dụng ít tài nguyên: Do gRPC sử dụng Protocol Buffers, dữ liệu được nén tốt hơn, dẫn đến tiết kiệm băng thông và tài nguyên máy chủ.

SigNoz yêu cầu Docker và Docker Compose để chạy.

Mở Terminal và thực hiện các lệnh dưới đây để tải và cài đặt SigNoz:

git clone https://github.com/SigNoz/signoz.git
 
cd signoz/deploy/
 
./install.sh
 
++++++++++++++++++ SUCCESS ++++++++++++++++++++++
 
🟢 Your installation is complete!
 
🟢 Your frontend is running on http://localhost:3301
 
ℹ️  By default, retention period is set to 15 days for logs and traces, and 30 days for metrics.
To change this, navigate to the General tab on the Settings page of SigNoz UI. For more details, refer to https://signoz.io/docs/userguide/retention-period 
 
ℹ️  To bring down SigNoz and clean volumes :  docker-compose -f ./docker/clickhouse-setup/docker-compose.yaml down -v
 
+++++++++++++++++++++++++++++++++++++++++++++++++

Truy cập SigNoz: Sau khi cài đặt hoàn tất, SigNoz sẽ chạy trên cổng 3301. Bạn có thể truy cập SigNoz thông qua trình duyệt tại địa chỉ: http://localhost:3301

tungnt@MacBook-Pro-cua-Nguyen-2 deploy % docker ps
CONTAINER ID   IMAGE                                        COMMAND                  CREATED         STATUS                   PORTS                                                                              NAMES
b41f37920c44   signoz/frontend:0.56.0                       "nginx -g 'daemon of…"   6 minutes ago   Up 4 minutes             80/tcp, 0.0.0.0:3301->3301/tcp                                                     signoz-frontend
8610bbf57d2d   gliderlabs/logspout:v3.2.14                  "/bin/logspout syslo…"   6 minutes ago   Up 4 minutes             80/tcp                                                                             signoz-logspout
2edc839a6533   signoz/signoz-otel-collector:0.102.12        "/signoz-collector -…"   6 minutes ago   Up 4 minutes             0.0.0.0:4317-4318->4317-4318/tcp                                                   signoz-otel-collector
25c604311ec7   signoz/alertmanager:0.23.7                   "/bin/alertmanager -…"   6 minutes ago   Up 4 minutes             9093/tcp                                                                           signoz-alertmanager
27b434094a49   signoz/query-service:0.56.0                  "./query-service -co…"   6 minutes ago   Up 5 minutes (healthy)   8080/tcp                                                                           signoz-query-service
e52c78f52e83   clickhouse/clickhouse-server:24.1.2-alpine   "/entrypoint.sh"         6 minutes ago   Up 6 minutes (healthy)   0.0.0.0:8123->8123/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:9181->9181/tcp, 9009/tcp   signoz-clickhouse
1166903ee8fb   signoz/locust:1.2.3                          "/docker-entrypoint.…"   6 minutes ago   Up 6 minutes             5557-5558/tcp, 8089/tcp                                                            load-hotrod
46540b384bac   bitnami/zookeeper:3.7.1                      "/opt/bitnami/script…"   6 minutes ago   Up 6 minutes             0.0.0.0:2181->2181/tcp, 0.0.0.0:2888->2888/tcp, 0.0.0.0:3888->3888/tcp, 8080/tcp   signoz-zookeeper-1
d6910ee05e61   jaegertracing/example-hotrod:1.30            "/go/bin/hotrod-linu…"   6 minutes ago   Up 6 minutes             8080-8083/tcp                                                                      hotrod

tungnt@MacBook-Pro-cua-Nguyen-2 deploy % docker logs -f signoz-frontend
2024/10/17 07:33:02 [notice] 1#1: using the "epoll" event method
2024/10/17 07:33:02 [notice] 1#1: nginx/1.26.2
2024/10/17 07:33:02 [notice] 1#1: built by gcc 13.2.1 20240309 (Alpine 13.2.1_git20240309) 
2024/10/17 07:33:02 [notice] 1#1: OS: Linux 6.10.4-linuxkit
2024/10/17 07:33:02 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2024/10/17 07:33:02 [notice] 1#1: start worker processes
2024/10/17 07:33:02 [notice] 1#1: start worker process 6
2024/10/17 07:33:02 [notice] 1#1: start worker process 7

Link hướng dẫn:

• https://signoz.io/docs/instrumentation/php/
• https://signoz.io/blog/opentelemetry-php/
• https://github.com/SigNoz/sample-php-app

pecl install opentelemetry   
pecl install protobuf

php -m | grep opentelemetry

composer config allow-plugins.php-http/discovery false
composer require \
  open-telemetry/sdk \
  open-telemetry/exporter-otlp \
  php-http/guzzle7-adapter \
  open-telemetry/opentelemetry-auto-slim