Log service

By default, Emissary-ingress puts the access logs on stdout; such that the can be read using kubectl logs. The format of those logs, and the local destination of them, can be configured using the envoy_log_ settings in the ambassador Module. However, the options there only allow for logging local to Emissary-ingress's Pod. By configuring a LogService, you can configure Emissary-ingress to report its access logs to a remote service, in addition to the usual ambassador Module configured logging.

The remote access log service (or ALS) must implement the AccessLogService gRPC interface, defined in Envoy's als.proto.

• service is where to route the access log gRPC requests to

• driver identifies which type of accesses to log; HTTP requests ("http") or TLS connections ("tcp").

• driver_config stores the configuration that is specific to the driver:

  • driver: tcp has no additional configuration; the config must be set as driver_config: {}.

  • driver: http

    • additional_log_headers identifies HTTP headers to include in the access log, and when in the logged-request's lifecycle to include them.

• flush_interval_time is the maximum number of seconds to buffer accesses for before sending them to the ALS. The logs will be flushed to the ALS every time this duration is reached, or when the buffered data reaches flush_interval_byte_size, whichever comes first. See the Envoy documentation on buffer_flush_interval for more information.

• flush_interval_byte_size is a soft size limit for the access log buffer. The logs will be flushed to the ALS every time the buffered data reaches this size, or whenever flush_interval_time elapses, whichever comes first. See the Envoy documentation on buffer_size_bytes for more information.

• grpc must be true.

• protocol_version was used in previous versions of Emissary-ingress to control the gRPC service name used to communicate with the LogService. Emissary-ingress 3.x is running an updated version of Envoy that has dropped support for the v2 protocol, so starting in 3.x, if protocol_version is not specified, the default value of v2 will cause an error to be posted and a static response will be returned. Therefore, you must set it to protocol_version: v3. If upgrading from a previous version, you will want to set it to v3 and ensure it is working before upgrading to Emissary-ingress 3.Y. The default value for protocol_version remains v2 in the getambassador.io/v3alpha1 CRD specifications to avoid making breaking changes outside of a CRD version change. Future versions of CRD's will deprecate it.

Example

Transport Protocol Migration

Note: The following information is only applicable to AuthServices using proto: grpc As of Emissary-ingress version 2.3, the v2 transport protocol is deprecated and any AuthServices making use of it should migrate to v3 before support for v2 is removed in a future release.

The following imports simply need to be updated to migrate an AuthService

v2 Imports:

v3 Imports: