Labels questions

Support: Full-Stack Observability (FSO) Application Performance Monitoring
, ,
#1

I am a big fan of the labels that you can add to monitors, apps, etc to group and filter items but I have notice some quirks.

In APM only the first letter of a label will be capitalized, so Environment:NFT becomes Environment:Nft, however this is not the case in the Monitors labels.

If you have an existing label and want to add another which is similar but shorter, it will select the existing label and not let you add the shorter. So if I had Group:ProductionWeb and wanted to add Group:Production then the Group:ProductionWeb will automatically be selected.

Are we looking at undocumented “features” here? :smirk:

Manipulating label names
Labels case sensitivity
Rest API and Web UI have inconsistent label capitalization policy
#2

To resolve this, first use the API Explorer to delete the longer label, then add the short label prior to adding the longer label.

#3

Are we looking at undocumented “features” here? :smirk:

What is that saying? “That’s a feature not a bug!” - in all seriousness I’m not sure if this is expected behavior here. I suspect that the code is working “as expected” even if that is not necessarily what is desired (or expected by others). :innocent:

In any case, checking in: did you just answer your own question? :Let me know if you’re looking for help from us. I could submit a feature request around being less finicky about sanitizing such capitalization as well as that second label addition. Please let me know how you’d like to proceed!

#4

Hey @stefan_garnham - follow-up on this one, I am going to go ahead and submit these requests as Feature Requests. Thanks for sharing your needs here as well as following up with a solution to one of them!

#5

Thanks @Lisa I hope the new features being added will assist users with their labelling needs

1 Like
#6

Hey Lisa! I think this should actually be filed as a bug. I just tried creating a camelCase label on a Synthetics monitor and it creates it appropriate (and honors my camelCase), example:

Screen Shot 2015-11-12 at 9.56.51 PM.png1004Ă—596 38.8 KB

but if I do the same thing with an application inside of APM, I get this:

Screen Shot 2015-11-12 at 9.57.00 PM.png986Ă—662 40.3 KB

I’d have to check which of the two is actually correctly (either Synthetics should be lower casing everything or APM shouldn’t be) but whichever, we should be consistent.

I’ll check with the team and post back here.

AJ

1 Like
#7

AJ,
What was the final decision on this? I’ve been adding labels to our Synthetics monitors and somehow have ended up with two categories: “Status” and “status”. Since they don’t match, I can’t roll up by the categories, and so far haven’t been able to get rid of the “status” category (I’m going to try through the API next).

Adam

#8

Hey @AdamB – Thanks for following up here! You’re correct: to fully delete the offending category:label pair, the API is required:

  1. Remove the target category:value from all Synthetics monitors.
  2. Delete the category:value pair via the labels api: https://rpm.newrelic.com/api/explore/labels/delete?key=category:value (case sensitive)
  3. Apply category:value with preferred case to monitor, to create new label.

As far as label case enforcement with Synthetics - we are tracking this issue internally, and I have added this post to the discussion. In the meantime, please use the preferred case when adding new category:value labels to your Synthetics monitors.

If the unwanted label persists, just let us know!

#9

Thank you @btribbia! I also found that Safari (10.0.3 / Mac OS 10.12.3) was caching some of the labels and so after deleting the offending label using the API explorer, I had to then quit and re-open Safari before creating the new (case-corrected) labels.

#10