dovecot - Aug 2020 - Metric label values truncated when using OpenMetrics endpoint

Hi,

Recently we upgraded to Dovecot 2.3.11.3 and configured an example metric like
this:


metric imap_command {
  event_name = imap_command_finished
  group_by = cmd_name tagged_reply_state user remote_ip
}

And enabled the OpenMetrics listener like this:

service stats {
  inet_listener http {
    port = 5000
  }
}

While the result is great, I noticed that some metrics are being truncated
(three dots at the end of the label value):

dovecot_imap_command_duration_usecs_sum{cmd_name="FETCH",tagged_reply_state="OK",user="xxxxxxxxxxx.inbox
at xxxxxxxxxxxxx?",remote_ip="XXXX:XXXX:XXXX:XXXX:cc6b:cc7a:d?"}
2346 1598055662473

I couldn't find this information in the documentation so I'm wondering
if this is a bug.

Thank you for your time.

Regards,
Daan



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200822/20e09ba5/attachment-0001.html>

On Sat, Aug 22, 2020 at 00:31:36 +0000, Daan van Gorkum
wrote:
> Hi,
> 
> Recently we upgraded to Dovecot 2.3.11.3 and configured an example metric
> like this:
> 
> 
> metric imap_command {
>   event_name = imap_command_finished
>   group_by = cmd_name tagged_reply_state user remote_ip
Grouping by remote_ip seems a bit dangerous unless the ips are somehow
limited.  Each unique value will result in (permanent) memory allocation, so
this has the potential to slowly grow the stats process large enough that
the vsize limit kicks in and the stats process gets killed and respawned.
> }
...
> While the result is great, I noticed that some metrics are being truncated
> (three dots at the end of the label value):
> 
>
dovecot_imap_command_duration_usecs_sum{cmd_name="FETCH",tagged_reply_state="OK",user="xxxxxxxxxxx.inbox
at xxxxxxxxxxxxx?",remote_ip="XXXX:XXXX:XXXX:XXXX:cc6b:cc7a:d?"}
2346 1598055662473
> 
> I couldn't find this information in the documentation so I'm
wondering if
> this is a bug.
Hm.  The submetric names are truncated to 32 bytes because nobody will ever
want metrics bigger than that. ;)  Obviously, we need to revisit that
decision.  There is no workaround that I can think of.

Jeff.

-- 
I'm somewhere between geek and normal.
		- Linus Torvalds

Hi Jeff,

Thanks for your reply!

Regarding grouping by remote address, I understand and for now I'll keep a
close eye. Maybe it's an option to group by /24 for ipv4 and /64 for IPv6?
We currently do that based on the logs but the OpenMetrics endpoint seem a lot
easier.

A slight hijack of the original question: but I tried to log only IP addresses
(+ result) of failed login attempts but it seems I cannot find a metric that
would contain that information. Am I looking in the wrong direction? The
auth_userdb_request_finished and auth_passdb_request_finished stats work as
intended but they do not contain any information about the connecting client.

Thanks again!

Daan

________________________________
From: Josef 'Jeff' Sipek <jeff.sipek at open-xchange.com>
Sent: 24 August 2020 20:47
To: Daan van Gorkum <daan.vangorkum at vusam.com>
Cc: Dovecot Mailing List <dovecot at dovecot.org>
Subject: Re: Metric label values truncated when using OpenMetrics endpoint

On Sat, Aug 22, 2020 at 00:31:36 +0000, Daan van Gorkum
wrote:
> Hi,
>
> Recently we upgraded to Dovecot 2.3.11.3 and configured an example metric
> like this:
>
>
> metric imap_command {
>   event_name = imap_command_finished
>   group_by = cmd_name tagged_reply_state user remote_ip
Grouping by remote_ip seems a bit dangerous unless the ips are somehow
limited.  Each unique value will result in (permanent) memory allocation, so
this has the potential to slowly grow the stats process large enough that
the vsize limit kicks in and the stats process gets killed and respawned.
> }
...
> While the result is great, I noticed that some metrics are being truncated
> (three dots at the end of the label value):
>
>
dovecot_imap_command_duration_usecs_sum{cmd_name="FETCH",tagged_reply_state="OK",user="xxxxxxxxxxx.inbox
at xxxxxxxxxxxxx?",remote_ip="XXXX:XXXX:XXXX:XXXX:cc6b:cc7a:d?"}
2346 1598055662473
>
> I couldn't find this information in the documentation so I'm
wondering if
> this is a bug.
Hm.  The submetric names are truncated to 32 bytes because nobody will ever
want metrics bigger than that. ;)  Obviously, we need to revisit that
decision.  There is no workaround that I can think of.

Jeff.

--
I'm somewhere between geek and normal.
                - Linus Torvalds
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200825/28995b75/attachment-0001.html>