15.2.4 Khai thác các chỉ số thời gian chạy

Endpoint /metrics có thể báo cáo nhiều chỉ số (metrics) được tạo ra bởi một ứng dụng đang chạy, bao gồm bộ nhớ, vi xử lý, thu gom rác (garbage collection) và các yêu cầu HTTP. Actuator cung cấp hơn hai chục danh mục chỉ số ngay từ đầu, như được minh họa bởi danh sách các danh mục chỉ số được trả về khi gửi một yêu cầu GET tới /metrics:

$ curl localhost:8081/actuator/metrics | jq
{
  "names": [
    "jvm.memory.max",
    "process.files.max",
    "jvm.gc.memory.promoted",
    "http.server.requests",
    "system.load.average.1m",
    "jvm.memory.used",
    "jvm.gc.max.data.size",
    "jvm.memory.committed",
    "system.cpu.count",
    "logback.events",
    "jvm.buffer.memory.used",
    "jvm.threads.daemon",
    "system.cpu.usage",
    "jvm.gc.memory.allocated",
    "jvm.threads.live",
    "jvm.threads.peak",
    "process.uptime",
    "process.cpu.usage",
    "jvm.classes.loaded",
    "jvm.gc.pause",
    "jvm.classes.unloaded",
    "jvm.gc.live.data.size",
    "process.files.open",
    "jvm.buffer.count",
    "jvm.buffer.total.capacity",
    "process.start.time"
  ]
}

Có quá nhiều chỉ số được cung cấp để có thể thảo luận hết một cách có ý nghĩa trong chương này. Thay vào đó, chúng ta sẽ tập trung vào một danh mục chỉ số là http.server.requests, như một ví dụ về cách sử dụng endpoint /metrics.

Nếu thay vì chỉ yêu cầu /metrics, bạn gửi yêu cầu GET tới /metrics/{metrics name}, bạn sẽ nhận được thông tin chi tiết hơn về các chỉ số thuộc danh mục đó. Trong trường hợp http.server.requests, một yêu cầu GET tới /metrics/http.server.requests sẽ trả về dữ liệu có dạng như sau:

$ curl localhost:8081/actuator/metrics/http.server.requests
{
  "name": "http.server.requests",
  "measurements": [
    { "statistic": "COUNT", "value": 2103 },
    { "statistic": "TOTAL_TIME", "value": 18.086334315 },
    { "statistic": "MAX", "value": 0.028926313 }
  ],
  "availableTags": [
    { "tag": "exception",
      "values": [ "ResponseStatusException",
                  "IllegalArgumentException", "none" ] },
    { "tag": "method", "values": [ "GET" ] },
    { "tag": "uri",
      "values": [
        "/actuator/metrics/{requiredMetricName}",
        "/actuator/health", "/actuator/info", "/ingredients",
        "/actuator/metrics", "/**" ] },
    { "tag": "status", "values": [ "404", "500", "200" ] }
  ]
}

Phần quan trọng nhất trong phản hồi là mục measurements, trong đó bao gồm tất cả các chỉ số của danh mục đã yêu cầu. Trong trường hợp này, nó báo cáo rằng đã có 2.103 yêu cầu HTTP. Tổng thời gian xử lý các yêu cầu đó là 18.086334315 giây, và thời gian xử lý dài nhất cho một yêu cầu là 0.028926313 giây.

Những chỉ số tổng quát như vậy rất thú vị, nhưng bạn có thể thu hẹp kết quả hơn nữa bằng cách sử dụng các thẻ (tags) được liệt kê trong mục availableTags. Ví dụ, bạn biết rằng có 2.103 yêu cầu, nhưng chưa rõ bao nhiêu trong số đó dẫn đến mã trạng thái HTTP 200 so với 404 hay 500. Sử dụng tag status, bạn có thể lấy các chỉ số cho những yêu cầu dẫn đến trạng thái HTTP 404 như sau:

$ curl localhost:8081/actuator/metrics/http.server.requests?tag=status:404
{
  "name": "http.server.requests",
  "measurements": [
    { "statistic": "COUNT", "value": 31 },
    { "statistic": "TOTAL_TIME", "value": 0.522061212 },
    { "statistic": "MAX", "value": 0 }
  ],
  "availableTags": [
    { "tag": "exception",
      "values": [ "ResponseStatusException", "none" ] },
    { "tag": "method", "values": [ "GET" ] },
    { "tag": "uri",
      "values": [
            "/actuator/metrics/{requiredMetricName}", "/**" ] }
  ]
}

Bằng cách chỉ định tên và giá trị tag thông qua thuộc tính tag trong yêu cầu, giờ đây bạn có thể xem các chỉ số cụ thể cho các yêu cầu trả về phản hồi HTTP 404. Điều này cho thấy đã có 31 yêu cầu dẫn đến 404, và mất tổng cộng 0.522061212 giây để xử lý chúng. Hơn nữa, rõ ràng rằng một số yêu cầu thất bại đó là các yêu cầu GET tới /actuator/metrics/{requiredMetricsName} (dù chưa rõ {requiredMetricsName} được ánh xạ tới giá trị gì). Và một số yêu cầu khác là tới những đường dẫn được biểu diễn bởi wildcard /**.

Hmm... giả sử bạn muốn biết có bao nhiêu trong số các phản hồi HTTP 404 đó là cho đường dẫn /**? Tất cả những gì bạn cần làm để lọc thêm là chỉ định thêm tag uri trong yêu cầu, như sau:

% curl "localhost:8081/actuator/metrics/http.server.requests?tag=status:404&tag=uri:/**"
{
  "name": "http.server.requests",
  "measurements": [
    { "statistic": "COUNT", "value": 30 },
    { "statistic": "TOTAL_TIME", "value": 0.519791548 },
    { "statistic": "MAX", "value": 0 }
  ],
  "availableTags": [
    { "tag": "exception", "values": [ "ResponseStatusException" ] },
    { "tag": "method", "values": [ "GET" ] }
  ]
}

Giờ bạn có thể thấy rằng đã có 30 yêu cầu đến các đường dẫn khớp với /** và kết thúc bằng phản hồi HTTP 404, với tổng thời gian xử lý là 0.519791548 giây.

Bạn cũng sẽ nhận thấy rằng khi bạn tinh chỉnh yêu cầu, các tag có sẵn sẽ bị giới hạn hơn. Các tag được cung cấp chỉ là những tag khớp với các yêu cầu được phản ánh bởi các chỉ số đang hiển thị. Trong trường hợp này, các tag exception và method chỉ có một giá trị duy nhất; rõ ràng rằng cả 30 yêu cầu đều là các yêu cầu GET dẫn đến lỗi 404 do ResponseStatusException.

Việc điều hướng trong endpoint /metrics có thể hơi rắc rối, nhưng với một chút luyện tập, bạn hoàn toàn có thể truy xuất được dữ liệu mình cần. Trong chương 16, bạn sẽ thấy cách Spring Boot Admin giúp việc tiêu thụ dữ liệu từ endpoint /metrics trở nên dễ dàng hơn rất nhiều.

Mặc dù thông tin được cung cấp bởi các endpoint của Actuator mang đến cái nhìn sâu sắc hữu ích về hoạt động bên trong của một ứng dụng Spring Boot đang chạy, nhưng nó không thực sự thân thiện với con người. Vì các endpoint của Actuator là các endpoint REST, dữ liệu mà chúng cung cấp được thiết kế để được tiêu thụ bởi một ứng dụng khác, chẳng hạn như một giao diện người dùng. Với suy nghĩ đó, hãy cùng xem cách bạn có thể trình bày thông tin Actuator trong một ứng dụng web thân thiện với người dùng.