-
Notifications
You must be signed in to change notification settings - Fork 105
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.
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
feat: Add support for MeterReportService #231
Conversation
Please try to run the linter with |
super().__init__(name, tags) | ||
self.count = 0 | ||
self.previous = 0 | ||
self.mode = mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incompatible attribute type: Attribute mode
declared in class Counter
has type BoundMethod[typing.Callable(Counter.mode)[[Named(self, Counter), Named(mode, unknown)], typing.Any], Counter]
but is used as type CounterMode
.
Reply with "@sonatype-lift help" for info about LiftBot commands.
Reply with "@sonatype-lift ignore" to tell LiftBot to leave out the above finding from this PR.
Reply with "@sonatype-lift ignoreall" to tell LiftBot to leave out all the findings from this PR and from the status bar in Github.
When talking to LiftBot, you need to refresh the page to see its response. Click here to get to know more about LiftBot commands.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
@@ -28,6 +28,9 @@ class TraceSegmentReportService(object): | |||
def report(self, generator): | |||
raise NotImplementedError() | |||
|
|||
class MeterReportService(object): | |||
def report(self, generator): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also report_batch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could be used. These two report
receive different generators
. The former needs a generator that generates MeterData
and the latter MeterDataCollection
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jiang1997 I collected the call times of an interface through Counter and reported it to skywalking. Now I want to display this metric on the ui page. How do I do it? Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Learn MAL and Dashboard setup.
- https://skywalking.apache.org/docs/main/next/en/setup/backend/backend-meter/
- https://skywalking.apache.org/docs/main/next/en/concepts-and-designs/mal/
- Examples, https://github.com/apache/skywalking/tree/89d14e6256338840cd4a9b37f76980c8558e50c3/oap-server/server-starter/src/main/resources/meter-analyzer-config/
- Dashboard, https://skywalking.apache.org/docs/main/next/en/ui/readme/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@March225
This is just a simple supplement to wu-sheng's advice for the sake of simplicity.
- Try to append your metric's definition to the server-side config file like these predefined metrics as below
https://github.com/apache/skywalking/blob/e2f1c0eadb52082e16f3abfc29dd8860000b596b/oap-server/server-starter/src/main/resources/meter-analyzer-config/python-runtime.yaml#L31-L36 - Then edit the dashboard and add a new widget to show your metric.
If nothing goes wrong, you should find your metric here.
99a357d
to
5c05dcd
Compare
@@ -0,0 +1,120 @@ | |||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parsing failure: Could not parse file at skywalking/meter/histogram.py
Reply with "@sonatype-lift help" for info about LiftBot commands.
Reply with "@sonatype-lift ignore" to tell LiftBot to leave out the above finding from this PR.
Reply with "@sonatype-lift ignoreall" to tell LiftBot to leave out all the findings from this PR and from the status bar in Github.
When talking to LiftBot, you need to refresh the page to see its response. Click here to get to know more about LiftBot commands.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
Sorry for messing up the commit history. |
skywalking/agent/__init__.py
Outdated
@@ -37,7 +38,7 @@ | |||
__started = False | |||
__protocol = Protocol() # type: Protocol | |||
__heartbeat_thread = __report_thread = __log_report_thread = __query_profile_thread = __command_dispatch_thread \ | |||
= __send_profile_thread = __queue = __log_queue = __snapshot_queue = __finished = None | |||
= __send_profile_thread = meter_service_thread = __queue = __log_queue = __snapshot_queue = __finished = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to name meter_service_thread
as __meter_service_thread
to comply with the naming convention here. But only to find that double underscore has its own specific behaviour when importing double underscore variable from another file. More details here. https://stackoverflow.com/questions/1301346/what-is-the-meaning-of-single-and-double-underscore-before-an-object-name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jiang1997 Thanks, good finding! I believe __
prefixed variables are not supposed to be referred to by external classes, but when it is defined outside of classes, it doesn't do much other than the meaning of "you probably shouldn't use (import) this".
Anyway, I see the current implementation bit out of sync with the previous reporter styles.
That is, you provided a new MeterService(Thread)
, and the result of defining threads outside of agent/__init__.py
is that the code base becomes weird in terms of calling topology, and there are some odd references because of it.
Maybe try two steps to make our agent startup behaviour better organized, given __init__.py
was never intended to be this big and also not supposed to have logic scattered around in other modules.
- Follow the existing style to see how you can write the MeterService class without the Threading part, like the existing profiling service (put the threading part back to
agent/__init__.py
. (If you understand this already, look at step 2) - Try to make the existing
__init__.py
into more organized modules at theagent/
directory; essentially, minimizeagent/__init__.py
and decouple the current mess. (If you meet obstacles, revert to step 1, and it will be good enough)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
It's okay, everything will be squashed in the end. |
Yes, it makes sense for both the end of this pr and the universe. |
Let's clear this policy. The result is YES, we would squash all the commits to merge as one single commit in the main branch. A real good commit log should be like this Introducing the clear context of why this PR changed in this way and how we apply the changes. Multiple commit logs could be automatically merged into one commit log in merging. |
Really good example, thanks! |
Thanks for elaborating! |
It's kind of weird. I passed
|
Indeed weird, but what the linter pointed out was right. I'm not sure what happened. |
How about creating a new pr to fix these errors that linter reported? I'm willing to. |
Well technically you could, but the PR cannot be allowed to merge until CI passes, unless you can bypass it. |
@jiang1997 can you please fix the linter errors in another PR. This should be because we didn’t pin the linter version and the linter updated recently. I just tried rerun a previously successful CI and it now failed. Anyway, the linter errors in this PR look reasonable to be fixed. Please fix them in another PR |
Generally looks good; please add the PVM metrics in the following PR and provide additional E2E test cases (refer to the currently commented @kezhenxu94 Please also take a look :) |
Got it. |
I think you should update the docs about meter APIs. @Superskyyy We also miss the tracing APIs doc. |
Ok, we will provide both API docs next! |
I noticed this, is it configurable? Usually metrics don't report so frequently considering backend load and necessarily. |
Thanks for the suggestion. I will make it configurable later. |
321ce2d
to
9b77a18
Compare
9b77a18
to
4847c40
Compare
Thanks! Looking good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jiang1997, thanks for the patience and hard work!! I'm going to merge this PR to unblock your next steps, also I left some comments that you might want address in a following minor PR, or in your next large PR with the PVM metrics.
@@ -0,0 +1,110 @@ | |||
# Python Agent Meter Reporter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please also add a link in the menu to this doc?
skywalking-python/docs/menu.yml
Lines 34 to 38 in aad9034
catalog: | |
- name: "Log Reporter" | |
path: "/en/setup/advanced/LogReporter" | |
- name: "Manual Instrumentation" | |
path: "/en/setup/advanced/API" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
## Counter | ||
* `Counter` API represents a single monotonically increasing counter, automatic collect data and report to backend. | ||
```python | ||
tg_ls = [MeterTag("key", "value")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be awesome if we can just pass in a Python tuple
tg_ls = [MeterTag("key", "value")] | |
tg_ls = [("key", "value")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good idea.
### Syntactic sugars | ||
```python | ||
c = Counter('c2', CounterMode.INCREMENT) | ||
c.build() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like every meter should invoke build
after construction, what about just embed the build
inside the construction of the meters? So that users won't forget to call the build
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. This is the sequelae of imitating java agent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason we need build method because we separate tags definition from construction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason we need build method because we separate tags definition from construction.
Thanks for reminding. Here also separate tags definition from construction, so seems build
is still needed.
Add support for MeterReportService
Behavior
This service runs along with the agent like other services and reports roughly every 20 seconds.
Syntactic sugar
Counter
Histogram
Simple test
insert following codes below this line
agent/__init__.py#L151