Our next-gen architecture is built to help you make sense of your ever-growing data Watch a 4-min demo video!
Formats: PNG, PDF, and SVG
Files size: 2.8 MB
For brand guidelines, please click here
Nowadays, as efficiency is the name of the game, companies that store great amounts of data are keeping a mindset of how to optimize data stores –raising the question of what data is more important to have available and what is less?
Coralogix Logs2Metrics enables you to generate metrics from your log data to optimize storage without sacrificing important data. You simply define a query and Coralogix will execute it every minute and store different data aggregations in a long-term index. Metrics start to gather from the point in time in which they were defined. The available query time range for your Logs2Metrics indices is 90 days.
Activating Logs2Metrics allows you to create up to 30 metrics with a 12 months retention period.
When creating a Logs2Metrics that expects a list of labels, logs that do not include some of the labels are converted into metric documents that only have a subset of the expected labels. While this behavior is not an issue in Kibana. When using PromQL with Grafana variables , there is no option to retrieve metrics with a subset of the labels, returning only a partial subset of the results.
See screen shot below.
This behavior has been rectified by populating the missing labels with data and have the correct results showing.
With every L2M created in Coralogix, regardless to specific “Metric Fields” and “Labels” you may define, a default metric is created. This metric will be enabled with the L2M creation in Grafana and when utilizing PromQL. The “Default metric” label will be structured as “<The Metric Name>_cx_docs_total” e.g.: The L2M name is: “Status_500”, then the “Default Metric” name will automatically set as: “Status_500_cx_docs_total”.
A “Count” metric is enabled for tracking the number of logs matches the L2M filters,
i.e.: in Grafana, you can explore the number of logs that meet the L2M conditions such as:
You may also utilize PromQL (while creating a “Metric Alert”) and query the “Default Metric”,
A Logs2metric labels permutations (the unique combination of each of the labels values) is a finite number and it is defined by the user per Metric (at the bottom of the metric definition). By default, it is set to 30,000 permutations and you may choose different max permutations value per Metric, while the maximum permutation per account is 1,000,000.
At the top of your defined Metrics list, you will see how many available permutations you have left for your disposal.
Normally, a metric document will show the count of logs per unique permutation of the chosen labels. If you encounter a metric that shows under permutations amount an exclamation mark near the number of allocated permutations it means you have reached the permutations limit. You should adjust the permutation allocation to accommodate all possible permutations, otherwise, the metric document will contain an aggregated log count under a CoralogixOtherValues bucket.
Once you create log2metrics you want to use it. make visualizations, graphs or tables, or anything you like.
Creating visualizations and dashboards for log2metrics follows the same procedure as creating any Kibana visualizations or dashboards. Make sure to select log2metrics index which is the index that always ends with _log_metrics.
Under Kibana click on visualization.
Select *:33_log_metrics* index
The visualization below shows the different status code over time
The log2metrics index includes logs that hold aggregation about your application and infrastructure logs. This affects the type of Kibana metrics you will use when creating log2metrics visualizations.
As I mentioned above the query section can have whatever query you want to put there. Below are some examples.
You can create any metric using complex queries based on your log data. These are a few examples of common use cases:
Have any questions? check our website and in-app chat for quick help.