Skip to content
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

Monolog logging handler for Managed VMs #9

Closed
tmatsuo opened this issue Nov 6, 2015 · 8 comments
Closed

Monolog logging handler for Managed VMs #9

tmatsuo opened this issue Nov 6, 2015 · 8 comments
Assignees
Labels
🚨 This issue needs some love. triage me I really want to be triaged.

Comments

@tmatsuo
Copy link
Contributor

tmatsuo commented Nov 6, 2015

I'm thinking to write a monolog logging handler for Managed VMs, which is equivalent to this:
https://github.com/GoogleCloudPlatform/appengine-python-vm-runtime/pull/18/files

Does it make sense to have this logging handler in this repo?

@bshaffer
Copy link
Contributor

bshaffer commented Nov 7, 2015

It might be more appropriate to put in https://github.com/GoogleCloudPlatform/appengine-php-sdk

@JustinBeckwith
Copy link
Contributor

I'd rather see us write a proper cloud logging veneer in PHP, and then have
a thin monolog handler on top of that. There's an existing veneer for Go:

https://github.com/GoogleCloudPlatform/gcloud-golang/tree/master/logging

The Python code we're looking at writes files to a magic directory that
Managed VMs uses with fluentd. It will only work on App Engine. If we
build cloud logging support into the veneer, then build monolog on top of
that - it will work from anywhere (k8s, compute, aws).

On Fri, Nov 6, 2015 at 4:27 PM, Brent Shaffer [email protected]
wrote:

It might be more appropriate to put in
https://github.com/GoogleCloudPlatform/appengine-php-sdk


Reply to this email directly or view it on GitHub
#9 (comment)
.

Justin Beckwith | Google Cloud Platform | @JustinBeckwith
http://twitter.com/JustinBeckwith | http://jbeckwith.com

@bshaffer
Copy link
Contributor

bshaffer commented Nov 9, 2015

Currently the AppEngine Logs API uses syslog. Perhaps the veneer library (and also the Google PHP Client library) should detect AppEngine and use monolog's syslog handler when present.

@JustinBeckwith
Copy link
Contributor

That's the App Engine v1 API :/ App Engine Managed VMs writes log files in a JSON
format to a magic path on disk. There's a fluentd agent that picks up the
log entries and shuffles them over to cloud logging.

There are a few options brewing here:

Do PHP developers expect to be able to just write straight to syslog?
Papertrail seems to think this is important:
http://help.papertrailapp.com/kb/configuration/configuring-centralized-logging-from-php-apps/

Monolog+fluentd (no syslog support) would be consistent with what we're
doing with other languages.

@mcrumm
Copy link
Contributor

mcrumm commented Mar 18, 2016

Is this possible on Container Engine, currently? I've been experimenting with monolog-fluentd (https://github.com/nrk/monolog-fluent), but realized after the fact that I have no way to talk to fluentd directly.

Is there a "magic path" that the fluentd agent will check on a Container Engine instance?

@tmatsuo
Copy link
Contributor Author

tmatsuo commented Apr 2, 2016

Combined solutions sounds great, but I don't know the concrete specs for those.

At least on App Engine flexible environment, I know what to do. I will try to add Logging handlers for App Engine flexible environment first. We can revisit the handlers to support other platforms later.

SG?

@JustinBeckwith
Copy link
Contributor

Yup, that's a good first step. Are you building a new package, or just using gcloud-php?

@tmatsuo
Copy link
Contributor Author

tmatsuo commented Apr 2, 2016

I'm thinking a sub namespace Google\Cloud\Logger or something in this repo.

The code looks like:

$app['monolog.handler'] = new Google\Cloud\Logger\AppEngineFlexHandler();

The downside of this is gcloud-php will have a dependency for monolog/monolog.

I'm fine with creating another repo though.

What do you guys think?

jdpedrie added a commit that referenced this issue Mar 10, 2017
* Reorganize namespaces and fix tests

* # This is a combination of 9 commits.
# This is the 1st commit message:
Reorganize namespaces and fix tests

Update component versions via the CLI

# This is the commit message #2:

Create tags in components

# This is the commit message #3:

Send component name and version in user agent

# This is the commit message #4:

Add README files

# This is the commit message #5:

Fix CLI

# This is the commit message #6:

Add split to travis

# This is the commit message #7:

Test datastore release

# This is the commit message #8:

Compile splitsh

# This is the commit message #9:

Reintroduce full split process

* # This is a combination of 2 commits.
# This is the 1st commit message:

Reorganize namespaces and fix tests

Update component versions via the CLI

Create tags in components

Send component name and version in user agent

Add README files

Fix CLI

Add split to travis

Test datastore release

Compile splitsh

Reintroduce full split process

Release patches

# This is the commit message #2:

Run split in each build matrix

* Reorganize namespaces and fix tests

Update component versions via the CLI

Create tags in components

Send component name and version in user agent

Add README files

Fix CLI

Add split to travis

Test datastore release

Compile splitsh

Reintroduce full split process

Release patches

Run split in each build matrix

Release datastore patch

enable set -e

* Work with github API directly

* Fix Vision class reference

* Create VERSION file for all components

* Remove componentName

* Fix int64 snippet tests

* Update component release target

* Parse documentation separately for each component

* This works now

* Add flag to docs to use JSON_PRETTY_PRINT for debugging

* Parse correct links between components

* Fix unit tests

* Doc links within component should not change version

* Cross-component links should go to the correct version docs

* Update snippets to remove refs to ServiceBuilder

* Remove unnecessary env vars

* Don't write VERSION for parent

* Release packages

* release v0.24.1

* Add autoloaders to each component

* Pass libVersion to gax config

* Update push docs command

* add gcsUri helper

* allow gcsUri or storage object

* Release 0.24.2

* Update things again

* this is the worst

* Link to upstream tag

* tag

* Update table of contents

* Reset versions

* Update suggests and requires

* fix build docs trigger

* dont throw exceptions on decode

* Fix docs link

* Fix various doc issues

* fix namespace
@yoshi-automation yoshi-automation added 🚨 This issue needs some love. triage me I really want to be triaged. labels Apr 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚨 This issue needs some love. triage me I really want to be triaged.
Projects
None yet
Development

No branches or pull requests

6 participants