New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658441 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 620149
issue 665199



Sign in to add a comment

eventmon implemented in golang

Project Member Reported by estaab@chromium.org, Oct 21 2016

Issue description

We need a Go client equivalent for our Python event_mon to support collecting event logs when build runs on swarming instead of buildbot, as well as for other services in Go (e.g. test-results).

Go tsmon is here and should go in ../eventmon (or equivalent):
https://chromium.googlesource.com/external/github.com/luci/luci-go/+/master/common/tsmon/

Python event_mon is here:
https://chromium.googlesource.com/infra/infra/+/master/packages/infra_libs/infra_libs/event_mon/

Comments from dsansome on suggested API changes:
"""
My biggest problem with the event_mon API is that it knows too much about the internals of the messages being logged.  Extending it to support new event types requires code changes to event_mon itself:
https://chromium.googlesource.com/infra/infra/+/master/packages/infra_libs/infra_libs/event_mon/monitoring.py#433
All that validation code for individual message types should be moved to separate packages.

This tight coupling has also leaked into the send_monitoring_event command-line tool:
https://chromium.googlesource.com/infra/infra/+/master/infra/tools/send_monitoring_event/common.py#69
We shouldn't have a flag for each field in the message, but rather accept a text protobuf on stdin or the commandline.

I think event_mon should just be about sending protobufs to an endpoint with oauth authentication.  All details of the contents of those protobufs, the different types of events, should be done by consumers of the library.
"""

 

Comment 1 by no...@chromium.org, Nov 2 2016

Blocking: 620149
Owner: mcgreevy@chromium.org
Status: Started (was: Available)

Comment 3 by estaab@chromium.org, Nov 14 2016

Blocking: 665199

Comment 4 by estaab@chromium.org, Nov 14 2016

Hi Michael, any updates on this? I'm updating the platform backlog since we'll use this for migrating off of buildbot.

Also, if you want to know another place this will be immediately useful see  http://crbug.com/665199 . :)
I'm hoping to have something that we can use in the isolate client by the end of this week.  This will won't be particularly performant (it will have a synchronous Log method; no fancy request-batching), but I should get to those kind of optimizations at the beginning of next week.
Project Member

Comment 7 by bugdroid1@chromium.org, Nov 28 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/infra.git/+/270fc63ac55da555323bd8dfa995fd78d6d90def

commit 270fc63ac55da555323bd8dfa995fd78d6d90def
Author: Michael McGreevy <mcgreevy@chromium.org>
Date: Tue Nov 22 00:15:20 2016

Add support/bundler to Go deps.

This is in preparation for use by the eventlog library.

BUG= 658441 

Change-Id: I92d5841a28a21a64e9d17c8b9e98a665653410cc
Reviewed-on: https://chromium-review.googlesource.com/412623
Reviewed-by: Tim Ansell <tansell@chromium.org>
Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
Commit-Queue: Tim Ansell <tansell@chromium.org>

[modify] https://crrev.com/270fc63ac55da555323bd8dfa995fd78d6d90def/go/deps.lock
[modify] https://crrev.com/270fc63ac55da555323bd8dfa995fd78d6d90def/go/deps.yaml

Ping - please provide an update to your high priority bug. This bug is stale. Is it really P-1?

Comment 10 by no...@chromium.org, Feb 22 2017

(bulk edit) setting P2 because this bug has luci label and not _required_ for the current milestone

Comment 11 by no...@chromium.org, Feb 22 2017

Labels: Pri-2

Comment 12 by efoo@chromium.org, Apr 6 2017

Components: -Infra>Monitoring
Is this done?

Moved to Infra>Platform since this is a service specific alert update. Added label "Ops-AddMonitoring" to track monitoring tasks over services.
Status: Fixed (was: Started)
I'm going to mark this as fixed since last I remember talking to Michael he said we could start using it. Thanks!

Sign in to add a comment