From ca4929b78323e5d5063dad39d8740d8f3b5c0697 Mon Sep 17 00:00:00 2001 From: Gopi-eng2202 Date: Fri, 15 Nov 2024 15:23:53 +0530 Subject: [PATCH] Updating "Best practices: Naming lables" #2469 Signed-off-by: Gopi-eng2202 --- content/docs/practices/naming.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/practices/naming.md b/content/docs/practices/naming.md index 6f3cc5e49..6668e91e9 100644 --- a/content/docs/practices/naming.md +++ b/content/docs/practices/naming.md @@ -41,13 +41,13 @@ A metric name... (for a timestamp that tracks the time of the latest record processed in a data processing pipeline) * ...that has a `unit` in its name, must always have that `unit` as the last word. Note that an accumulating count such as `total` will be the last word, in addition to the unit if applicable. Examples, * request\_size\_bytes - * request\_size\_bytes_total + * request\_size\_bytes\_total * process\_cpu\_seconds - * process\_cpu\_seconds_total + * process\_cpu\_seconds\_total * ...that has a accumulating count such as `total`, can have two different naming scenarios. * If the metric name has a unit, then the unit must be the last word before the accumulating count. Examples, - * process\_cpu\_seconds_total - * request\_size\_bytes_total + * process\_cpu\_seconds\_total + * request\_size\_bytes\_total * If the metric name does'nt have a real unit, then the naming can follow any sorting order in a way that it fits your use case, such as `grouping similar metric names`. Examples, * If you decided to name something as "net\_conntrack\_dialer\_conn", then it can have the following group names. (Note that this is only an example and you can follow your own order, if it improves your work flow) * net\_conntrack\_dialer\_conn\_total