Log Based Metrics – Stackdriver GCP
Also read Error Reporting on GCP, Agent Metrics on GCP and Debugging on GCP
Overview
One of the things that confused me was the term log-based metrics. What does log-based mean?
Logs were one thing (a recording of events, a time series) and metrics were another (averaged operational numbers used to perform a variety of actions).
It turns out, one can perform the same 'averaged' operation on log events. For example - say your logs contain an error 500 from app engine. And say this reoccurs every so often. One could build a custom metric around this time series - and call it error500 average metric.
Custom Metrics versus Log Based Metrics
If none of the 1500+ built in metrics meet your needs, you can always define your own custom metric, using code. Here is an example of a custom metric defined using python. Each metric has to have a TYPE and a DESCRIPTOR.
Alert Conditions
- Metric Threshold: It triggers if the metric's value is sustained above or below the threshold for a given time
- Metric Absence: It triggers if the metric is absent for the given period
- Metric Rate of Change: True when the metric increases or decreases greater than the given rate over a given period
- Uptime Check Health: It triggers when two or more user-defined uptime checks fail
- Process Health: It triggers if the number of matching processes on a VM running the Stackdriver Monitoring Agent falls above or below the threshold for a given time
Summary - Log Based Metrics versus Custom Metrics
A Custom Metric is custom code that creates a special type of aggregate.
A Log based metric is a way to get averaged (or other aggregated) information out of your logs, without having to dump those logs into a sink and perform all kinds of queries.
Need an experienced Cloud Security Expert?
Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.
Leave a Reply