Posted inDevOps

Quan sát Toàn diện trong DevOps: Hướng dẫn về OpenTelemetry

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Quan sát Toàn diện trong DevOps: Hướng dẫn về OpenTelemetry

Lúc đó là 2 giờ sáng. Thiết bị nhắn tin của tôi réo lên, báo hiệu một sự cố sản xuất khác. Nhật ký bị phân tán, các chỉ số cho thấy một đợt tăng đột biến mơ hồ, và việc theo dõi chỉ là một suy nghĩ muộn màng. Nghe có quen không? Tôi đã từng ở trong hoàn cảnh đó, gỡ lỗi trong mù mịt, sàng lọc qua hàng núi dữ liệu rời rạc. Mục tiêu: xác định nguyên nhân gốc rễ trước bình minh. Những tình huống này đã thúc đẩy tôi tìm kiếm một cách tốt hơn: khả năng quan sát toàn diện, đặc biệt với OpenTelemetry.

Khả năng quan sát không chỉ là về việc thu thập dữ liệu. Đó là về việc đặt *bất kỳ* câu hỏi nào cho hệ thống của bạn và nhận được câu trả lời, ngay cả đối với những kịch bản mà bạn không lường trước. Hãy nghĩ nó như chiếc đèn pin bạn cầm lấy khi hệ thống phức tạp gặp sự cố. Đối với nhiều người trong chúng ta đang phải vật lộn với kiến trúc microservices, serverless và cloud-native, OpenTelemetry đang nhanh chóng trở thành tiêu chuẩn. Nó mang lại trật tự cần thiết cho sự hỗn loạn.

So sánh cách tiếp cận: Giám sát truyền thống so với Khả năng quan sát hợp nhất

Giám sát truyền thống: Phương pháp dựa trên triệu chứng

Trong nhiều năm, chúng ta đã dựa vào một tập hợp các công cụ chắp vá. Bạn có thể sử dụng Prometheus cho các chỉ số, có thể là ELK stack (Elasticsearch, Logstash, Kibana) cho nhật ký, và một hệ thống theo dõi riêng biệt như Jaeger hoặc Zipkin.

Mỗi công cụ đều xuất sắc trong nhiệm vụ cụ thể của nó, nhưng việc đối chiếu dữ liệu là một cơn ác mộng. Khi một khách hàng báo cáo sự cố, bạn sẽ chuyển từ bảng điều khiển Grafana (chỉ số Prometheus) sang Kibana (nhật ký Elasticsearch). Bạn sẽ khó khăn trong việc khớp các dấu thời gian, sau đó có thể tìm kiếm trong Jaeger một ID dấu vết mà *có thể* xuất hiện trong nhật ký.

  • Ưu điểm: Trưởng thành, được áp dụng rộng rãi, hỗ trợ cộng đồng mạnh mẽ cho từng thành phần.
  • Nhược điểm: Dữ liệu bị phân tán, chi phí chuyển đổi ngữ cảnh cao, khó đối chiếu các tín hiệu đo từ xa khác nhau và thường là phản ứng. Cảnh báo thường chỉ kích hoạt cho các chế độ lỗi đã biết. Thời gian trung bình để giải quyết (MTTR) có thể kéo dài hàng giờ do nỗ lực thủ công cần thiết để kết nối các điểm.

OpenTelemetry: Tương lai tích hợp

OpenTelemetry (OTel) ra đời từ sự hợp nhất của OpenTracing và OpenCensus. Nó đã tạo ra một bộ API, SDK và công cụ duy nhất để đo lường, tạo, thu thập và xuất dữ liệu đo từ xa: dấu vết, chỉ số và nhật ký. Đây là một tiêu chuẩn độc lập với nhà cung cấp. Điều này có nghĩa là bạn đo lường ứng dụng của mình một lần, sau đó gửi dữ liệu đó đến bất kỳ hệ thống phụ trợ tương thích nào—cho dù là mã nguồn mở hay thương mại. Điều này đơn giản hóa đáng kể cách bạn nắm bắt và quản lý trạng thái nội bộ của hệ thống.

  • Ưu điểm: Đo lường hợp nhất, truyền ngữ cảnh nhất quán (quan trọng đối với các dấu vết phân tán), giảm sự phụ thuộc vào nhà cung cấp và phát triển cộng đồng tích cực. OTel được thiết kế cho môi trường cloud-native. Nó nhằm mục đích giảm MTTR bằng cách cung cấp một cái nhìn tổng thể về hành vi của hệ thống.
  • Nhược điểm: Vẫn đang phát triển (đặc biệt đối với nhật ký, mặc dù đang trưởng thành nhanh chóng), đường cong học tập ban đầu để hiểu các thành phần của nó, và việc quản lý khối lượng lớn dữ liệu đo từ xa đòi hỏi phải lập kế hoạch cẩn thận.

Các trụ cột của OpenTelemetry: Dấu vết, Chỉ số và Nhật ký

OpenTelemetry tiêu chuẩn hóa việc thu thập ba tín hiệu đo từ xa cơ bản:

Truy vết phân tán: Theo dõi hành trình của yêu cầu

Hãy tưởng tượng một yêu cầu người dùng duy nhất chảy qua hàng tá microservices, hàng đợi không đồng bộ và các lệnh gọi cơ sở dữ liệu. Không có truy vết, hành trình này là một hộp đen. Truy vết phân tán cho phép bạn hình dung toàn bộ đường đi của yêu cầu đó.

Nó hiển thị độ trễ ở mỗi bước, xác định các nút thắt cổ chai và chỉ ra chính xác các lỗi dịch vụ. Mỗi hoạt động trở thành một ‘span’, và một tập hợp các span liên quan tạo thành một ‘trace’. OTel đảm bảo rằng một ID dấu vết và ID span duy nhất được truyền qua các ranh giới dịch vụ, liên kết mọi thứ lại với nhau một cách liền mạch.


from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor

# Thiết lập một nhà cung cấp tracer
provider = TracerProvider()
processor = SimpleSpanProcessor(ConsoleSpanExporter())
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# Lấy một tracer cho ứng dụng của bạn
tracer = trace.get_tracer("my-app-tracer")

def process_order(order_id):
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        print(f"Đang xử lý đơn hàng: {order_id}")
        # Mô phỏng một số công việc
        do_inventory_check(order_id)
        do_payment_processing(order_id)

def do_inventory_check(order_id):
    with tracer.start_as_current_span("inventory_check"):
        print(f"  Đang kiểm tra kho cho đơn hàng {order_id}")
        # ... logic kiểm tra kho thực tế ...

def do_payment_processing(order_id):
    with tracer.start_as_current_span("payment_processing"):
        print(f"  Đang xử lý thanh toán cho đơn hàng {order_id}")
        # ... logic xử lý thanh toán thực tế ...

process_order("12345")

Chỉ số: Hiểu rõ tình trạng hệ thống trong nháy mắt

Các chỉ số cung cấp dữ liệu tổng hợp, định lượng về hành vi của hệ thống theo thời gian. Hãy nghĩ đến tốc độ yêu cầu, số lượng lỗi, mức sử dụng CPU, mức sử dụng bộ nhớ và các chỉ số kinh doanh tùy chỉnh. OTel định nghĩa nhiều công cụ đo lường khác nhau như Counters (cho các giá trị tăng), Gauges (cho các giá trị hiện tại) và Histograms (cho phân phối thống kê các giá trị, chẳng hạn như độ trễ yêu cầu). Những điều này là vô giá để phát hiện xu hướng, đặt cảnh báo và giám sát tình trạng hệ thống tổng thể.


from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import ConsoleMetricExporter, PeriodicExportingMetricReader

# Thiết lập một nhà cung cấp meter
reader = PeriodicExportingMetricReader(ConsoleMetricExporter())
provider = MeterProvider(metric_readers=[reader])
metrics.set_meter_provider(provider)

# Lấy một meter cho ứng dụng của bạn
meter = metrics.get_meter("my-app-meter")

# Tạo một công cụ Counter
requests_counter = meter.create_counter(
    "http.server.requests",
    description="Tổng số yêu cầu HTTP",
    unit="{requests}",
)

# Tạo một công cụ Histogram cho thời lượng yêu cầu
request_duration_histogram = meter.create_histogram(
    "http.server.request.duration",
    description="Thời lượng của các yêu cầu HTTP",
    unit="s",
)

def handle_request(path, duration):
    requests_counter.add(1, {"http.route": path, "http.method": "GET"})
    request_duration_histogram.record(duration, {"http.route": path, "http.method": "GET"})
    print(f"Đã xử lý yêu cầu tới {path} trong {duration}s")

handle_request("/api/users", 0.05)
handle_request("/api/products", 0.12)

Nhật ký: Chi tiết ẩn chứa

Nhật ký vẫn rất quan trọng đối với các chi tiết cấp sự kiện, chi tiết nhỏ. OpenTelemetry tăng cường khả năng ghi nhật ký truyền thống bằng cách chèn ID dấu vết và ID span trực tiếp vào các bản ghi nhật ký của bạn. Thay đổi tưởng chừng nhỏ bé này lại là một yếu tố thay đổi cuộc chơi. Khi bạn đang xem xét một mục nhật ký trong một sự cố lúc 2 giờ sáng, bạn ngay lập tức biết nó thuộc về dấu vết và span nào. Điều này cho phép bạn chuyển trực tiếp từ một thông báo nhật ký đến ngữ cảnh dấu vết đầy đủ trong giao diện người dùng truy vết của bạn.


import logging
from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor
from opentelemetry.sdk.logs import LogRecordsProcessor, LoggerProvider
from opentelemetry.sdk.logs.export import ConsoleLogExporter, SimpleLogRecordProcessor
from opentelemetry.instrumentation.logging import LoggingInstrumentor

# Thiết lập Nhà cung cấp Tracer
resource = Resource.create({"service.name": "my-log-service"})
provider = TracerProvider(resource=resource)
span_processor = SimpleSpanProcessor(ConsoleSpanExporter())
provider.add_span_processor(span_processor)
trace.set_tracer_provider(provider)

# Thiết lập Nhà cung cấp Logger
logger_provider = LoggerProvider(resource=resource)
log_processor = SimpleLogRecordProcessor(ConsoleLogExporter())
logger_provider.add_log_record_processor(log_processor)

# Đo lường thư viện ghi nhật ký Python tiêu chuẩn
LoggingInstrumentor().instrument(set_logging_format=True, log_level=logging.INFO, logger_provider=logger_provider)

# Lấy một tracer và logger
tracer = trace.get_tracer("my-log-service-tracer")
logger = logging.getLogger(__name__)

logger.info("Ứng dụng đã khởi động.")

with tracer.start_as_current_span("main_operation") as span:
    span.set_attribute("user.id", "testuser")
    logger.warning("Phát hiện tải cao tiềm ẩn.")
    # Một số logic
    with tracer.start_as_current_span("sub_operation"):
        logger.debug("Hoạt động phụ đang tiến hành.")
    logger.info("Hoạt động chính đã hoàn thành.")

logger.info("Ứng dụng đã tắt.")

Thiết lập được đề xuất: Một Stack OpenTelemetry sẵn sàng cho sản xuất

Để thực sự khai thác OpenTelemetry trong môi trường DevOps, bạn cần nhiều hơn là chỉ đo lường ứng dụng. Bạn cần một đường ống mạnh mẽ để thu thập, xử lý và phân tích dữ liệu. Dưới đây là một stack điển hình sẵn sàng cho sản xuất:

OpenTelemetry Collectors: Cổng Telemetry

OpenTelemetry Collector là một proxy mạnh mẽ, độc lập với nhà cung cấp. Nó có thể nhận, xử lý và xuất dữ liệu đo từ xa.

Hoạt động như một trung tâm, nó tách rời việc đo lường ứng dụng của bạn khỏi các hệ thống phụ trợ. Điều này cho phép bạn chuyển đổi, lọc, nhóm và thậm chí lấy mẫu dữ liệu trước khi nó đến các công cụ phân tích có thể tốn kém của bạn. Bạn thường triển khai các collector dưới dạng agent (sidecars hoặc DaemonSets trong Kubernetes) cùng với các ứng dụng của bạn để thu thập cục bộ, và dưới dạng gateway (triển khai chuyên dụng) để tổng hợp và định tuyến.

Một cấu hình collector cơ bản để nhận OTLP (OpenTelemetry Protocol) và xuất sang Jaeger, Prometheus và Loki có thể trông như thế này:


receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  prometheus:
    endpoint: "0.0.0.0:8889"
  loki:
    endpoint: http://loki:3100/api/prom/push

processors:
  batch:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

Lưu trữ & Phân tích Backend: Giải mã dữ liệu

Sau khi dữ liệu của bạn chảy qua collector, bạn cần một nơi để lưu trữ và trực quan hóa nó:

  • Dấu vết: Jaeger và Tempo (một phần của hệ sinh thái Grafana Labs) là những lựa chọn phổ biến để lưu trữ và trực quan hóa các dấu vết phân tán.
  • Chỉ số: Prometheus là tiêu chuẩn thực tế cho các chỉ số chuỗi thời gian. Mimir cung cấp khả năng lưu trữ Prometheus có thể mở rộng, đa người thuê.
  • Nhật ký: Loki (Grafana Labs) là một hệ thống tổng hợp nhật ký được thiết kế để tiết kiệm chi phí và tích hợp dễ dàng với Grafana. Elasticsearch là một tùy chọn mạnh mẽ khác, thường được ghép nối với Kibana.
  • Bảng điều khiển & Cảnh báo: Grafana là công cụ bảng điều khiển phổ quát. Nó kết nối với tất cả các hệ thống phụ trợ được đề cập ở trên để cung cấp một cái nhìn hợp nhất về toàn bộ hệ thống của bạn.

Hướng dẫn triển khai: Bắt tay vào thực hiện

Hãy cùng xem qua một ví dụ đơn giản. Chúng ta sẽ làm cho OpenTelemetry hoạt động cho một ứng dụng Python Flask. Mục tiêu của tôi ở đây là chỉ cho bạn thấy bạn có thể nhanh chóng đạt được khả năng quan sát cơ bản như thế nào.

Bước 1: Đo lường ứng dụng của bạn (Ví dụ Python Flask)

Đầu tiên, cài đặt các gói OpenTelemetry cần thiết cho ứng dụng Python của bạn:


pip install opentelemetry-sdk opentelemetry-api opentelemetry-exporter-otlp opentelemetry-instrumentation-flask opentelemetry-instrumentation-requests opentelemetry-instrumentation-logging

Bây giờ, hãy tạo một tệp (ví dụ: app_instrumentation.py) để thiết lập việc đo lường toàn cục. Sau đó, sử dụng nó trong ứng dụng Flask của bạn:


# app_instrumentation.py

from opentelemetry import trace, metrics
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from opentelemetry.instrumentation.logging import LoggingInstrumentor
from opentelemetry.sdk.logs import LoggerProvider, BatchLogRecordProcessor
from opentelemetry.exporter.otlp.proto.grpc.log_exporter import OTLPLogExporter
import logging

def configure_opentelemetry(service_name):
    resource = Resource.create({"service.name": service_name})

    # Cấu hình Truy vết
    trace_provider = TracerProvider(resource=resource)
    span_exporter = OTLPSpanExporter(endpoint="localhost:4317") # Điểm cuối OTLP gRPC
    trace_provider.add_span_processor(BatchSpanProcessor(span_exporter))
    trace.set_tracer_provider(trace_provider)

    # Cấu hình Chỉ số
    metric_reader = PeriodicExportingMetricReader(
        OTLPMetricExporter(endpoint="localhost:4317")
    )
    metric_provider = MeterProvider(resource=resource, metric_readers=[metric_reader])
    metrics.set_meter_provider(metric_provider)

    # Cấu hình Nhật ký
    logger_provider = LoggerProvider(resource=resource)
    log_exporter = OTLPLogExporter(endpoint="localhost:4317")
    logger_provider.add_log_record_processor(BatchLogRecordProcessor(log_exporter))
    LoggingInstrumentor().instrument(set_logging_format=True, log_level=logging.INFO, logger_provider=logger_provider)

    # Tự động đo lường các framework web và client HTTP
    FlaskInstrumentor().instrument()
    RequestsInstrumentor().instrument()

    print(f"OpenTelemetry đã cấu hình cho dịch vụ: {service_name}")

# app.py
from flask import Flask, request
import requests
import logging
from app_instrumentation import configure_opentelemetry

configure_opentelemetry("my-flask-app")
app = Flask(__name__)
logger = logging.getLogger(__name__)

@app.route('/')
def hello():
    logger.info("Yêu cầu đến /.")
    # Thực hiện một yêu cầu HTTP đi để minh họa truy vết phân tán
    try:
        requests.get("http://example.com", timeout=1)
    except requests.exceptions.Timeout:
        logger.warning("Yêu cầu tới example.com đã hết thời gian chờ.")
    except Exception as e:
        logger.error(f"Lỗi khi thực hiện yêu cầu tới example.com: {e}")

    return "Xin chào, Observability!"

@app.route('/slow')
def slow_route():
    logger.info("Yêu cầu đến /slow.")
    import time
    time.sleep(0.1)
    logger.info("Đường dẫn chậm đã hoàn thành.")
    return "Đường dẫn này chậm quá!"

if __name__ == '__main__':
    app.run(debug=True, port=5000)

Thiết lập này gửi dấu vết, chỉ số và nhật ký qua OTLP (gRPC) đến localhost:4317, nơi OpenTelemetry Collector của chúng ta sẽ lắng nghe.

Bước 2: Triển khai OpenTelemetry Collectors

Để phát triển cục bộ hoặc thiết lập đơn giản, bạn có thể chạy OpenTelemetry Collector qua Docker Compose. Tạo một tệp docker-compose.yaml và một tệp collector-config.yaml (sử dụng cấu hình từ trên) trong cùng thư mục với ứng dụng của bạn.


# docker-compose.yaml
version: '3.8'
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: [--config=/etc/otel-collector-config.yaml]
    volumes:
      - ./collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317" # OTLP gRPC receiver
      - "4318:4318" # OTLP HTTP receiver (if enabled in config)
      - "8889:8889" # Prometheus metrics exporter

  jaeger:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686" # Jaeger UI
      - "14250:14250" # gRPC collector

  prometheus:
    image: prom/prometheus:latest
    command: --config.file=/etc/prometheus/prometheus.yml
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  loki:
    image: grafana/loki:latest
    command: -config.file=/etc/loki/local-config.yaml
    volumes:
      - ./loki-local-config.yaml:/etc/loki/local-config.yaml
    ports:
      - "3100:3100"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_PATHS_PROVISIONING=/etc/grafana/provisioning
    volumes:
      - ./grafana-provisioning/:/etc/grafana/provisioning
    ports:
      - "3000:3000"

Và một tệp prometheus.yml cơ bản để Prometheus scrape collector:


# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8889']

Và loki-local-config.yaml:


# loki-local-config.yaml
auth_enabled: false

server:
  http_listen_port: 3100

common:
  instance_path: /loki
  path_prefix: /tmp/loki
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory
  replication_factor: 1

schema_config:
  configs:
    - from: 2020-10-27
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      period: 24h

compactor:
  compaction_interval: 10m

query_range:
  align_queries_with_step: true
  cache_results: true

chunks:
  max_chunk_age: 1h

memberlist:
  abort_if_cluster_join_fails: false

Cuối cùng, một số cấu hình Grafana cho nguồn dữ liệu (ví dụ: grafana-provisioning/datasources.yaml):


# grafana-provisioning/datasources.yaml
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus:9090
    access: proxy
    isDefault: true
    version: 1

  - name: Jaeger
    type: jaeger
    url: http://jaeger:16686
    access: proxy
    version: 1

  - name: Loki
    type: loki
    url: http://loki:3100
    access: proxy
    version: 1

Khởi động mọi thứ bằng lệnh docker-compose up -d. Sau đó chạy ứng dụng Python Flask của bạn.

Bước 3: Thiết lập Backend quan sát của bạn

Với thiết lập Docker Compose, bạn sẽ có Jaeger, Prometheus, Loki và Grafana đang chạy. Truy cập Grafana tại http://localhost:3000. Bạn sẽ thấy Prometheus, Jaeger và Loki được cấu hình làm nguồn dữ liệu. Bây giờ, bạn có thể xây dựng các bảng điều khiển để trực quan hóa các chỉ số ứng dụng của bạn. Sử dụng tab Explore để truy vấn nhật ký, và đi sâu vào các dấu vết trong giao diện người dùng Jaeger (`http://localhost:16686`) hoặc tab Explore của Grafana (khi Loki được tích hợp để truy vết qua Tempo).

Bước 4: Xác thực và Lặp lại

Thực hiện một số yêu cầu đối với ứng dụng Flask của bạn (`http://localhost:5000`, `http://localhost:5000/slow`). Sau đó, kiểm tra Grafana, Jaeger và Loki. Bạn sẽ thấy:

  • Dấu vết trong Jaeger/Grafana hiển thị đường paths yêu cầu thông qua ứng dụng Flask của bạn và lệnh gọi đi đến example.com.
  • Các chỉ số trong Prometheus/Grafana cho http.server.requests và http.server.request.duration của bạn.
  • Nhật ký trong Loki/Grafana với các ID dấu vết và span liên quan.

Sức mạnh thực sự của cách tiếp cận tích hợp này tỏa sáng khi một cảnh báo được kích hoạt. Thay vì đoán, bạn có thể nhảy từ bảng điều khiển Grafana hiển thị một đỉnh chỉ số trực tiếp đến các dấu vết và nhật ký có liên quan.

Tất cả đều được làm giàu với cùng một ngữ cảnh. Tôi đã áp dụng cách tiếp cận này trong môi trường sản xuất, và kết quả luôn ổn định và có tác động. Ví dụ, trong một sự cố đặc biệt khó khăn, một dịch vụ upstream đã intermittently bị lỗi. Các dấu vết hợp nhất ngay lập tức làm nổi bật nút thắt cổ chai, cho phép nhóm của tôi cô lập vấn đề và triển khai một circuit breaker trong vòng chưa đầy 30 phút, giảm đáng kể thời gian có thể là hàng giờ tìm kiếm nhật ký điên cuồng.

Kết luận: Áp dụng khả năng quan sát để duy trì sự minh mẫn

Những ngày giám sát rời rạc đã lùi về quá khứ. Trong các hệ thống phân tán phức tạp ngày nay, một cách tiếp cận thống nhất đối với khả năng quan sát không chỉ là một ‘thứ nên có’. Nó rất cần thiết để duy trì sự minh mẫn, giảm thời gian phản ứng sự cố và thực sự hiểu cách hệ thống của bạn hoạt động.

OpenTelemetry cung cấp tiêu chuẩn hóa cần thiết để đạt được điều này, mang lại cho bạn khả năng đo lường một lần và phân tích ở bất cứ đâu. Bắt đầu từ nhỏ, đo lường một dịch vụ quan trọng và dần dần mở rộng. Bạn sẽ sớm tự hỏi làm thế nào bạn có thể quản lý mà không có nó.

Share:
Tags: