Get desktop application:
View/edit binary Protocol Buffers messages
Administration interface :ref:`operations documentation <operations_admin_interface>`. [#next-free-field: 7]
Used in:
Configuration for :ref:`access logs <arch_overview_access_logs>` emitted by the administration server.
The path to write the access log for the administration server. If no access log is desired specify ‘/dev/null’. This is only required if :ref:`address <envoy_v3_api_field_config.bootstrap.v3.Admin.address>` is set. Deprecated in favor of ``access_log`` which offers more options.
The cpu profiler output path for the administration server. If no profile path is specified, the default is ‘/var/log/envoy/envoy.prof’.
The TCP address that the administration server will listen on. If not specified, Envoy will not start an administration server.
Additional socket options that may not be present in Envoy source code or precompiled binaries.
Indicates whether :ref:`global_downstream_max_connections <config_overload_manager_limiting_connections>` should apply to the admin interface or not.
Bootstrap :ref:`configuration overview <config_overview_bootstrap>`. [#next-free-field: 42]
Used in:
Node identity to present to the management server and for instance identification purposes (e.g. in generated headers).
A list of :ref:`Node <envoy_v3_api_msg_config.core.v3.Node>` field names that will be included in the context parameters of the effective xdstp:// URL that is sent in a discovery request when resource locators are used for LDS/CDS. Any non-string field will have its JSON encoding set as the context parameter value, with the exception of metadata, which will be flattened (see example below). The supported field names are: - "cluster" - "id" - "locality.region" - "locality.sub_zone" - "locality.zone" - "metadata" - "user_agent_build_version.metadata" - "user_agent_build_version.version" - "user_agent_name" - "user_agent_version" The node context parameters act as a base layer dictionary for the context parameters (i.e. more specific resource specific context parameters will override). Field names will be prefixed with “udpa.node.” when included in context parameters. For example, if node_context_params is ``["user_agent_name", "metadata"]``, the implied context parameters might be:: node.user_agent_name: "envoy" node.metadata.foo: "{\"bar\": \"baz\"}" node.metadata.some: "42" node.metadata.thing: "\"thing\"" [#not-implemented-hide:]
Statically specified resources.
xDS configuration sources.
Configuration for the cluster manager which owns all upstream clusters within the server.
Health discovery service config option. (:ref:`core.ApiConfigSource <envoy_v3_api_msg_config.core.v3.ApiConfigSource>`)
Optional file system path to search for startup flag files.
Optional set of stats sinks.
Options to control behaviors of deferred creation compatible stats.
Configuration for internal processing of stats.
Optional duration between flushes to configured stats sinks. For performance reasons Envoy latches counters and only flushes counters and gauges at a periodic interval. If not specified the default is 5000ms (5 seconds). Only one of ``stats_flush_interval`` or ``stats_flush_on_admin`` can be set. Duration must be at least 1ms and at most 5 min.
Flush stats to sinks only when queried for on the admin interface. If set, a flush timer is not created. Only one of ``stats_flush_on_admin`` or ``stats_flush_interval`` can be set.
Optional watchdog configuration. This is for a single watchdog configuration for the entire system. Deprecated in favor of ``watchdogs`` which has finer granularity.
Optional watchdogs configuration. This is used for specifying different watchdogs for the different subsystems. [#extension-category: envoy.guarddog_actions]
Configuration for an external tracing provider. .. attention:: This field has been deprecated in favor of :ref:`HttpConnectionManager.Tracing.provider <envoy_v3_api_field_extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.Tracing.provider>`.
Configuration for the runtime configuration provider. If not specified, a “null” provider will be used which will result in all defaults being used.
Configuration for the local administration HTTP server.
Optional overload manager configuration.
Enable :ref:`stats for event dispatcher <operations_performance>`, defaults to false. Note that this records a value for each iteration of the event loop on every thread. This should normally be minimal overhead, but when using :ref:`statsd <envoy_v3_api_msg_config.metrics.v3.StatsdSink>`, it will send each observed value over the wire individually because the statsd protocol doesn't have any way to represent a histogram summary. Be aware that this can be a very large volume of data.
Optional string which will be used in lieu of x-envoy in prefixing headers. For example, if this string is present and set to X-Foo, then x-envoy-retry-on will be transformed into x-foo-retry-on etc. Note this applies to the headers Envoy will generate, the headers Envoy will sanitize, and the headers Envoy will trust for core code and core extensions only. Be VERY careful making changes to this string, especially in multi-layer Envoy deployments or deployments using extensions which are not upstream.
Optional proxy version which will be used to set the value of :ref:`server.version statistic <server_statistics>` if specified. Envoy will not process this value, it will be sent as is to :ref:`stats sinks <envoy_v3_api_msg_config.metrics.v3.StatsSink>`.
Always use TCP queries instead of UDP queries for DNS lookups. This may be overridden on a per-cluster basis in cds_config, when :ref:`dns_resolvers <envoy_v3_api_field_config.cluster.v3.Cluster.dns_resolvers>` and :ref:`use_tcp_for_dns_lookups <envoy_v3_api_field_config.cluster.v3.Cluster.use_tcp_for_dns_lookups>` are specified. This field is deprecated in favor of ``dns_resolution_config`` which aggregates all of the DNS resolver configuration in a single message.
DNS resolution configuration which includes the underlying dns resolver addresses and options. This may be overridden on a per-cluster basis in cds_config, when :ref:`dns_resolution_config <envoy_v3_api_field_config.cluster.v3.Cluster.dns_resolution_config>` is specified. This field is deprecated in favor of :ref:`typed_dns_resolver_config <envoy_v3_api_field_config.bootstrap.v3.Bootstrap.typed_dns_resolver_config>`.
DNS resolver type configuration extension. This extension can be used to configure c-ares, apple, or any other DNS resolver types and the related parameters. For example, an object of :ref:`CaresDnsResolverConfig <envoy_v3_api_msg_extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig>` can be packed into this ``typed_dns_resolver_config``. This configuration replaces the :ref:`dns_resolution_config <envoy_v3_api_field_config.bootstrap.v3.Bootstrap.dns_resolution_config>` configuration. During the transition period when both ``dns_resolution_config`` and ``typed_dns_resolver_config`` exists, when ``typed_dns_resolver_config`` is in place, Envoy will use it and ignore ``dns_resolution_config``. When ``typed_dns_resolver_config`` is missing, the default behavior is in place. [#extension-category: envoy.network.dns_resolver]
Specifies optional bootstrap extensions to be instantiated at startup time. Each item contains extension specific configuration. [#extension-category: envoy.bootstrap]
Specifies optional extensions instantiated at startup time and invoked during crash time on the request that caused the crash.
Configuration sources that will participate in xdstp:// URL authority resolution. The algorithm is as follows: 1. The authority field is taken from the xdstp:// URL, call this ``resource_authority``. 2. ``resource_authority`` is compared against the authorities in any peer ``ConfigSource``. The peer ``ConfigSource`` is the configuration source message which would have been used unconditionally for resolution with opaque resource names. If there is a match with an authority, the peer ``ConfigSource`` message is used. 3. ``resource_authority`` is compared sequentially with the authorities in each configuration source in ``config_sources``. The first ``ConfigSource`` to match wins. 4. As a fallback, if no configuration source matches, then ``default_config_source`` is used. 5. If ``default_config_source`` is not specified, resolution fails. [#not-implemented-hide:]
Default configuration source for xdstp:// URLs if all other resolution fails. [#not-implemented-hide:]
Optional overriding of default socket interface. The value must be the name of one of the socket interface factories initialized through a bootstrap extension
Global map of CertificateProvider instances. These instances are referred to by name in the :ref:`CommonTlsContext.CertificateProviderInstance.instance_name <envoy_v3_api_field_extensions.transport_sockets.tls.v3.CommonTlsContext.CertificateProviderInstance.instance_name>` field. [#not-implemented-hide:]
Specifies a set of headers that need to be registered as inline header. This configuration allows users to customize the inline headers on-demand at Envoy startup without modifying Envoy's source code. Note that the 'set-cookie' header cannot be registered as inline header.
Optional path to a file with performance tracing data created by "Perfetto" SDK in binary ProtoBuf format. The default value is "envoy.pftrace".
Optional overriding of default regex engine. If the value is not specified, Google RE2 will be used by default. [#extension-category: envoy.regex_engines]
Optional XdsResourcesDelegate configuration, which allows plugging custom logic into both fetch and load events during xDS processing. If a value is not specified, no XdsResourcesDelegate will be used. TODO(abeyad): Add public-facing documentation. [#not-implemented-hide:]
Optional XdsConfigTracker configuration, which allows tracking xDS responses in external components, e.g., external tracer or monitor. It provides the process point when receive, ingest, or fail to process xDS resources and messages. If a value is not specified, no XdsConfigTracker will be used. .. note:: There are no in-repo extensions currently, and the :repo:`XdsConfigTracker <envoy/config/xds_config_tracker.h>` interface should be implemented before using. See :repo:`xds_config_tracker_integration_test <test/integration/xds_config_tracker_integration_test.cc>` for an example usage of the interface.
[#not-implemented-hide:] This controls the type of listener manager configured for Envoy. Currently Envoy only supports ListenerManager for this field and Envoy Mobile supports ApiListenerManager.
Optional application log configuration.
Optional gRPC async manager config.
Optional configuration for memory allocation manager. Memory releasing is only supported for `tcmalloc allocator <https://github.com/google/tcmalloc>`_.
Used in:
Optional field to set the application logs format. If this field is set, it will override the default log format. Setting both this field and :option:`--log-format` command line option is not allowed, and will cause a bootstrap error.
Used in:
Flush application logs in JSON format. The configured JSON struct can support all the format flags specified in the :option:`--log-format` command line options section, except for the ``%v`` and ``%_`` flags.
Flush application log in a format defined by a string. The text format can support all the format flags specified in the :option:`--log-format` command line option section.
Used in:
When the flag is enabled, Envoy will lazily initialize a subset of the stats (see below). This will save memory and CPU cycles when creating the objects that own these stats, if those stats are never referenced throughout the lifetime of the process. However, it will incur additional memory overhead for these objects, and a small increase of CPU usage when a at least one of the stats is updated for the first time. Groups of stats that will be lazily initialized: - Cluster traffic stats: a subgroup of the :ref:`cluster statistics <config_cluster_manager_cluster_stats>` that are used when requests are routed to the cluster.
[#next-free-field: 7]
Used in:
All :ref:`Listeners <envoy_v3_api_msg_config.listener.v3.Listener>` are provided by a single :ref:`LDS <arch_overview_dynamic_config_lds>` configuration source.
xdstp:// resource locator for listener collection. [#not-implemented-hide:]
All post-bootstrap :ref:`Cluster <envoy_v3_api_msg_config.cluster.v3.Cluster>` definitions are provided by a single :ref:`CDS <arch_overview_dynamic_config_cds>` configuration source.
xdstp:// resource locator for cluster collection. [#not-implemented-hide:]
A single :ref:`ADS <config_overview_ads>` source may be optionally specified. This must have :ref:`api_type <envoy_v3_api_field_config.core.v3.ApiConfigSource.api_type>` :ref:`GRPC <envoy_v3_api_enum_value_config.core.v3.ApiConfigSource.ApiType.GRPC>`. Only :ref:`ConfigSources <envoy_v3_api_msg_config.core.v3.ConfigSource>` that have the :ref:`ads <envoy_v3_api_field_config.core.v3.ConfigSource.ads>` field set will be streamed on the ADS channel.
Used in:
Optional field to set the expiration time for the cached gRPC client object. The minimal value is 5s and the default is 50s.
Used in:
Static :ref:`Listeners <envoy_v3_api_msg_config.listener.v3.Listener>`. These listeners are available regardless of LDS configuration.
If a network based configuration source is specified for :ref:`cds_config <envoy_v3_api_field_config.bootstrap.v3.Bootstrap.DynamicResources.cds_config>`, it's necessary to have some initial cluster definitions available to allow Envoy to know how to speak to the management server. These cluster definitions may not use :ref:`EDS <arch_overview_dynamic_config_eds>` (i.e. they should be static IP or DNS-based).
These static secrets can be used by :ref:`SdsSecretConfig <envoy_v3_api_msg_extensions.transport_sockets.tls.v3.SdsSecretConfig>`
Cluster manager :ref:`architecture overview <arch_overview_cluster_manager>`. [#next-free-field: 6]
Used in:
Name of the local cluster (i.e., the cluster that owns the Envoy running this configuration). In order to enable :ref:`zone aware routing <arch_overview_load_balancing_zone_aware_routing>` this option must be set. If ``local_cluster_name`` is defined then :ref:`clusters <envoy_v3_api_msg_config.cluster.v3.Cluster>` must be defined in the :ref:`Bootstrap static cluster resources <envoy_v3_api_field_config.bootstrap.v3.Bootstrap.StaticResources.clusters>`. This is unrelated to the :option:`--service-cluster` option which does not `affect zone aware routing <https://github.com/envoyproxy/envoy/issues/774>`_.
Optional global configuration for outlier detection.
Optional configuration used to bind newly established upstream connections. This may be overridden on a per-cluster basis by upstream_bind_config in the cds_config.
A management server endpoint to stream load stats to via ``StreamLoadStats``. This must have :ref:`api_type <envoy_v3_api_field_config.core.v3.ApiConfigSource.api_type>` :ref:`GRPC <envoy_v3_api_enum_value_config.core.v3.ApiConfigSource.ApiType.GRPC>`.
Whether the ClusterManager will create clusters on the worker threads inline during requests. This will save memory and CPU cycles in cases where there are lots of inactive clusters and > 1 worker thread.
Used in:
Specifies the path to the outlier event log.
[#not-implemented-hide:] The gRPC service for the outlier detection event service. If empty, outlier detection events won't be sent to a remote endpoint.
Used to specify the header that needs to be registered as an inline header. If request or response contain multiple headers with the same name and the header name is registered as an inline header. Then multiple headers will be folded into one, and multiple header values will be concatenated by a suitable delimiter. The delimiter is generally a comma. For example, if 'foo' is registered as an inline header, and the headers contains the following two headers: .. code-block:: text foo: bar foo: eep Then they will eventually be folded into: .. code-block:: text foo: bar, eep Inline headers provide O(1) search performance, but each inline header imposes an additional memory overhead on all instances of the corresponding type of HeaderMap or TrailerMap.
Used in:
The name of the header that is expected to be set as the inline header.
The type of the header that is expected to be set as the inline header.
Used in:
Fatal actions to run while crashing. Actions can be safe (meaning they are async-signal safe) or unsafe. We run all safe actions before we run unsafe actions. If using an unsafe action that could get stuck or deadlock, it important to have an out of band system to terminate the process. The interface for the extension is ``Envoy::Server::Configuration::FatalAction``. ``FatalAction`` extensions live in the ``envoy.extensions.fatal_actions`` API namespace.
Used in:
Extension specific configuration for the action. It's expected to conform to the ``Envoy::Server::Configuration::FatalAction`` interface.
Runtime :ref:`configuration overview <config_runtime>`.
Used in:
The :ref:`layers <config_runtime_layering>` of the runtime. This is ordered such that later layers in the list overlay earlier entries.
Used in:
Configures tcmalloc to perform background release of free memory in amount of bytes per ``memory_release_interval`` interval. If equals to ``0``, no memory release will occur. Defaults to ``0``.
Interval in milliseconds for memory releasing. If specified, during every interval Envoy will try to release ``bytes_to_release`` of free memory back to operating system for reuse. Defaults to 1000 milliseconds.
Runtime :ref:`configuration overview <config_runtime>` (deprecated).
The implementation assumes that the file system tree is accessed via a symbolic link. An atomic link swap is used when a new tree should be switched to. This parameter specifies the path to the symbolic link. Envoy will watch the location for changes and reload the file system tree when they happen. If this parameter is not set, there will be no disk based runtime.
Specifies the subdirectory to load within the root directory. This is useful if multiple systems share the same delivery mechanism. Envoy configuration elements can be contained in a dedicated subdirectory.
Specifies an optional subdirectory to load within the root directory. If specified and the directory exists, configuration values within this directory will override those found in the primary subdirectory. This is useful when Envoy is deployed across many different types of servers. Sometimes it is useful to have a per service cluster directory for runtime configuration. See below for exactly how the override directory is used.
Static base runtime. This will be :ref:`overridden <config_runtime_layering>` by other runtime layers, e.g. disk or admin. This follows the :ref:`runtime protobuf JSON representation encoding <config_runtime_proto_json>`.
[#next-free-field: 6]
Used in:
Descriptive name for the runtime layer. This is only used for the runtime :http:get:`/runtime` output.
:ref:`Static runtime <config_runtime_bootstrap>` layer. This follows the :ref:`runtime protobuf JSON representation encoding <config_runtime_proto_json>`. Unlike static xDS resources, this static layer is overridable by later layers in the runtime virtual filesystem.
:ref:`Admin console runtime <config_runtime_admin>` layer.
Used in:
(message has no fields)
:ref:`Disk runtime <config_runtime_local_disk>` layer.
Used in:
The implementation assumes that the file system tree is accessed via a symbolic link. An atomic link swap is used when a new tree should be switched to. This parameter specifies the path to the symbolic link. Envoy will watch the location for changes and reload the file system tree when they happen. See documentation on runtime :ref:`atomicity <config_runtime_atomicity>` for further details on how reloads are treated.
Specifies the subdirectory to load within the root directory. This is useful if multiple systems share the same delivery mechanism. Envoy configuration elements can be contained in a dedicated subdirectory.
:ref:`Append <config_runtime_local_disk_service_cluster_subdirs>` the service cluster to the path under symlink root.
:ref:`Runtime Discovery Service (RTDS) <config_runtime_rtds>` layer.
Used in:
Resource to subscribe to at ``rtds_config`` for the RTDS layer.
RTDS configuration source.
Envoy process watchdog configuration. When configured, this monitors for nonresponsive threads and kills the process after the configured thresholds. See the :ref:`watchdog documentation <operations_performance_watchdog>` for more information. [#next-free-field: 8]
Used in:
,Register actions that will fire on given WatchDog events. See ``WatchDogAction`` for priority of events.
The duration after which Envoy counts a nonresponsive thread in the ``watchdog_miss`` statistic. If not specified the default is 200ms.
The duration after which Envoy counts a nonresponsive thread in the ``watchdog_mega_miss`` statistic. If not specified the default is 1000ms.
If a watched thread has been nonresponsive for this duration, assume a programming error and kill the entire Envoy process. Set to 0 to disable kill behavior. If not specified the default is 0 (disabled).
Defines the maximum jitter used to adjust the ``kill_timeout`` if ``kill_timeout`` is enabled. Enabling this feature would help to reduce risk of synchronized watchdog kill events across proxies due to external triggers. Set to 0 to disable. If not specified the default is 0 (disabled).
If ``max(2, ceil(registered_threads * Fraction(*multikill_threshold*)))`` threads have been nonresponsive for at least this duration kill the entire Envoy process. Set to 0 to disable this behavior. If not specified the default is 0 (disabled).
Sets the threshold for ``multikill_timeout`` in terms of the percentage of nonresponsive threads required for the ``multikill_timeout``. If not specified the default is 0.
Used in:
Extension specific configuration for the action.
The events are fired in this order: KILL, MULTIKILL, MEGAMISS, MISS. Within an event type, actions execute in the order they are configured. For KILL/MULTIKILL there is a default PANIC that will run after the registered actions and kills the process if it wasn't already killed. It might be useful to specify several debug actions, and possibly an alternate FATAL action.
Used in:
Allows you to specify different watchdog configs for different subsystems. This allows finer tuned policies for the watchdog. If a subsystem is omitted the default values for that system will be used.
Used in:
Watchdog for the main thread.
Watchdog for the worker threads.