8000 WIP: Text format parser for Python by brian-brazil · Pull Request #54 · prometheus/client_python · GitHub
[go: up one dir, main page]
Skip to content

WIP: Text format parser for Python #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 4 commits into from
Oct 9, 2015
Merged

WIP: Text format parser for Python #54

merged 4 commits into from
Oct 9, 2015

Conversation

brian-brazil
Copy link
Contributor

@beorn7 Would you mind taking a peek at this to see if I've missed anything major? Main code is in parser.py, the rest is surrounding changes for this to make sense and have the right data structures.

The motivation is that Zalando's Zmon has a partial implementation of the text parser, so I'd like to offer them an official option.

@beorn7
Copy link
Member
beorn7 commented Oct 5, 2015

I'll have a look ASAP.

beorn7
beorn7 reviewed Oct 7, 2015
View reviewed changes
prometheus_client/core.py

Custom collectors should use GaugeMetricFamily, CounterMetricFamily
and SummaryMetricFamily instead.
'''
def __init__(self, name, documentation, typ):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has nothing to do with the change, but: Why typ and not type?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NM, keywords are evil... :-(

@beorn7
Copy link
Member
beorn7 commented Oct 7, 2015

Before checking further: Let's confirm what the intention WRT whitespace is. The text format is supposed to have any amount of non-new-line whitespace between tokens. text_parse_test.go includes things like

 # HELP  name2      doc str"ing 2
  #    TYPE    name2 gauge
name2{labelname="val2"  ,basename   =   "basevalue2"        } +Inf 54321
name2{ labelname = "val1" , }-Inf

@beorn7
Copy link
Member
beorn7 commented Oct 8, 2015

OK, looks sane to me. Just sprinkle a few crazy whitespace characters over the test cases to see if it works.

@brian-brazil
Copy link
Contributor Author

The test_spaces test should cover that. If we ever make a breaking change to the text format, it'd be good to get rid of all this space flexibility from a parsing standpoint.

@beorn7
Copy link
Member
beorn7 commented Oct 8, 2015

Ah, didn't see that... with the pre-squashed commits, it's difficult to see what has changed...

👍

But definitely leave the whitespace flexibility in place. That's what people expect when they see this kind of syntax. Remember that the text format is also meant to be easy for humans to assemble.

@brian-brazil
Improve tests.
c9d89ba 
Split out test files.
Add missing histogram exposition test.
Add unittests for metric families.
@brian-brazil
Make metric fields public.
854b401
@brian-brazil
Add a text format parser.
a2dae6c 
Fix exposition of 'NaN' in text format (Python uses 'nan').
brian-brazil added a commit that referenced this pull request Oct 9, 2015
@brian-brazil
Merge pull request #54 from prometheus/parser
ac1c45f 
WIP: Text format parser for Python
@brian-brazil brian-brazil merged commit ac1c45f into master Oct 9, 2015
@brian-brazil brian-brazil deleted the parser branch October 9, 2015 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@brian-brazil @beorn7
0