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

Muting an extremely chatty log line. #33

Merged
merged 1 commit into from Jan 15, 2015
Merged

Muting an extremely chatty log line. #33

merged 1 commit into from Jan 15, 2015

Conversation

nicolasnoble
Copy link
Member

No description provided.

ctiller added a commit that referenced this pull request Jan 15, 2015
Muting an extremely chatty log line.
@ctiller ctiller merged commit e55e115 into grpc:master Jan 15, 2015
@nicolasnoble nicolasnoble deleted the quiet branch January 15, 2015 00:04
jtattermusch pushed a commit that referenced this pull request Jun 18, 2016
Fixed endpoint tests.  Also more boolification.
apolcyn referenced this pull request in apolcyn/grpc Jul 25, 2016
Changed teeny weeny font for protobuf landing page snippet
@lock lock bot locked as resolved and limited conversation to collaborators Feb 2, 2019
lidizheng referenced this pull request in lidizheng/grpc Feb 12, 2021
There are multiple uses for opaque metadata that is associated with the
specific listener/filter chain/route that a request matches on:

1. Logging. Similar to header values, we can log the metadata values.
   A listener might belong to a higher level concept in the
   configuration language that generated LDS protos, e.g. there might be
   a rule identifier expressed. This metadata allows logs to reflect the
   rule identifier.

2. Future custom stats backends might use metadata to guide where and
   how stats are emitted. E.g. the metadata might include information
   about which stats collector to emit to.

3. Proprietary filters can receive additional inputs via the metadata.
   The per-filter metadata generalizes and replaces the opaque_config in
   RDS ForwardAction.

The metadata is structured such that each filter's metadata is under the
reverse DNS namespace defined by the filter. Shared metadata may be
arranged by coordinating on the reverse DNS namespace.

As an example, the "envoy.http_connection_manager.access_log" filter
namespace is suggested to be used for HTTP access logging.

Fixes #33.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants