I don't think the lack of principal normalization was intentional. Why spread that further? Don't we also have some normalization today?
Having slashes show up in components complicates parsing (can no longer split on '/'), no? For example, if we were to introduce the ability to query a subset of metrics with a simple matcher (e.g. /frameworks/*/messages_received), then this would be complicated by the presence of slashes in the principal or other user supplied strings. On Tue, Jul 3, 2018 at 3:17 PM, Greg Mann <g...@mesosphere.io> wrote: > Hi all! > I'm currently working on adding a suite of new per-framework metrics to > help schedulers better debug unexpected/unwanted behavior (MESOS-8842 > <https://issues.apache.org/jira/browse/MESOS-8842>). One issue that has > come up during this work is how we should handle strings like the framework > name or role name in metric keys, since those strings may contain > characters like '/' which already have a meaning in our metrics interface. > I intend to place the framework name and ID in the keys for the new > per-framework metrics, delimited by a sufficiently-unique separator so that > operators can decode the name/ID in their metrics tooling. An example > per-framework metric key: > > master/frameworks/<framework_name>###<framework_id>/tasks/task_running > > > I recently realized that we actually already allow the '/' character in > metric keys, since we include the framework principal in these keys: > > frameworks/<framework_principal>/messages_received > frameworks/<framework_principal>/messages_processed > > We don't disallow any characters in the principal, so anything could > appear in those keys. > > *Since we don't normalize the principal in the above keys, my proposal is > that we do not normalize the framework name at all when constructing the > new per-framework metric keys.* > > > Let me know what you think! > > Cheers, > Greg >
