> For the complete documentation index, see [llms.txt](https://docs.groundcover.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.groundcover.com/~/revisions/ETrLpNk6KtHjyaVUTLoE/logs-to-metrics-parsing.md).
# Logs To Metrics Parsing
#### What is Logs-to-Metrics?
At its simplest, logs-to-metrics is the process of extracting numerical, structured data from your unstructured, text-based logs and converting it into time-series metrics.
Think of it like this:
* A Log is a Sentence: `INFO: HTTP GET /api/users request completed in 55ms with status 200.`
* A Metric is a Spreadsheet Row:
| Timestamp | Metric Name | Value | Labels |
| --------- | -------------------------- | ----- | --------------------------------------------- |
| `[now]` | `http_requests_total` | `1` | `method:GET, endpoint:/api/users, status:200` |
| `[now]` | `http_request_duration_ms` | `55` | `method:GET, endpoint:/api/users, status:200` |
You are essentially turning descriptive sentences into countable, measurable data points.
#### Where Should You Use It?
Logs-to-metrics is not for replacing logs entirely. Logs are essential for debugging specific events. Instead, you should use it in these key scenarios:
**1. Counting Key Business or Application Events**
You want to count how often something happens.
* Use Case: Count the number of user logins, failed payments, or items added to a shopping cart.
* Example: Create a metric named `user_logins_total` by counting every log line that contains `"User successfully authenticated"`.
**2. Monitoring Error Rates**
You want to track the frequency of errors to understand system health.
* Use Case: Alerting when the rate of `500` status codes or `ERROR` level logs spikes.
* Example: Create a metric named `http_requests_total` with a label for the status code. Then you can easily calculate the error rate: `rate(http_requests_total{status="500"}) / rate(http_requests_total)`.
**3. Monitoring Legacy or Third-Party Applications**
You need to monitor an application that you cannot modify to expose its own metrics.
* Use Case: An old Java application or a third-party tool only writes its status to a log file.
* Example: You can parse that log file to extract key performance indicators (like active connections or tasks processed) and turn them into metrics, giving you visibility you wouldn't otherwise have.
## How to Apply Log to Metric Parsing Rule
To create achieve log to metric we will need to create [parsing rule](/~/revisions/ETrLpNk6KtHjyaVUTLoE/log-parsing-with-opentelemetry-pipelines.md#deploying-ottl-in-groundcover).
The rule will be structured from defending the `l2m` values or attributes
and from the `log_to_metric_X` logic that can be one of the following:
* `log_to_metric_count` - count all logs with the desired values or attributes
* `log_to_metric_max` - max value of logs with the desired values or attributes
* `log_to_metric_min` - mix value of logs with the desired values or attributes
* `log_to_metric_sum` - summarize value of logs with the desired values or attributes
{% hint style="success" %}
Please note that groundcover adds `gc_op` suffix with the numeric operation
{% endhint %}
Example Structure
```
- ruleName: l2m-kong
statements:
- set(l2m["request_path"],attributes["request.path"])
- set(l2m["cluster"],cluster)
- log_to_metric_sum("kong_request_volume", l2m,
Double(attributes["bytes"]))
- log_to_metric_min("kong_request_volume", l2m,
Double(attributes["bytes"]))
- log_to_metric_max("kong_request_volume", l2m,
Double(attributes["bytes"]))
- set(l2m["status_code"],attributes["status_code"])
- log_to_metric_count("kong_access_log_metrics", l2m)
conditions:
- container_name == "proxy"
- workload == "groundcover-incloud-kong"
statementsErrorMode: propagate
conditionLogicOperator: and
```
log 1
```
10.1.139.127 - - [07/Aug/2025:12:07:00 +0000] "GET /fleet-manager/api/client/config HTTP/2.0" 403 19 "-" "Go-http-client/2.0"
```
log 2
```
10.1.139.127 - - [07/Aug/2025:12:08:00 +0000] "GET /fleet-manager/api/client/config HTTP/2.0" 403 189 "-" "Go-http-client/2.0"
```
log 3
```
10.1.139.127 - - [07/Aug/2025:12:10:00 +0000] "GET /fleet-manager/api/client/config HTTP/2.0" 403 6 "-" "Go-http-client/2.0"
```
Results:
| Metric | Value |
| --------------------------------- | ----- |
| kong\_access\_log\_metrics\_sum | 214 |
| kong\_access\_log\_metrics\_min | 6 |
| kong\_access\_log\_metrics\_max | 189 |
| kong\_access\_log\_metrics\_count | 4 |
Those result are also create a metric which will be available at [Metric explorer ](/~/revisions/ETrLpNk6KtHjyaVUTLoE/use-groundcover/explore-and-monitors-query-builder.md):
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.groundcover.com/~/revisions/ETrLpNk6KtHjyaVUTLoE/logs-to-metrics-parsing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.