lrs.proto 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103
  1. syntax = "proto3";
  2. package envoy.service.load_stats.v3;
  3. import "envoy/config/core/v3/base.proto";
  4. import "envoy/config/endpoint/v3/load_report.proto";
  5. import "google/protobuf/duration.proto";
  6. import "udpa/annotations/status.proto";
  7. import "udpa/annotations/versioning.proto";
  8. option java_package = "io.envoyproxy.envoy.service.load_stats.v3";
  9. option java_outer_classname = "LrsProto";
  10. option java_multiple_files = true;
  11. option go_package = "github.com/envoyproxy/go-control-plane/envoy/service/load_stats/v3;load_statsv3";
  12. option java_generic_services = true;
  13. option (udpa.annotations.file_status).package_version_status = ACTIVE;
  14. // [#protodoc-title: Load Reporting service (LRS)]
  15. // Load Reporting Service is an Envoy API to emit load reports. Envoy will initiate a bi-directional
  16. // stream with a management server. Upon connecting, the management server can send a
  17. // :ref:`LoadStatsResponse <envoy_v3_api_msg_service.load_stats.v3.LoadStatsResponse>` to a node it is
  18. // interested in getting the load reports for. Envoy in this node will start sending
  19. // :ref:`LoadStatsRequest <envoy_v3_api_msg_service.load_stats.v3.LoadStatsRequest>`. This is done periodically
  20. // based on the :ref:`load reporting interval <envoy_v3_api_field_service.load_stats.v3.LoadStatsResponse.load_reporting_interval>`
  21. // For details, take a look at the :ref:`Load Reporting Service sandbox example <install_sandboxes_load_reporting_service>`.
  22. service LoadReportingService {
  23. // Advanced API to allow for multi-dimensional load balancing by remote
  24. // server. For receiving LB assignments, the steps are:
  25. // 1, The management server is configured with per cluster/zone/load metric
  26. // capacity configuration. The capacity configuration definition is
  27. // outside of the scope of this document.
  28. // 2. Envoy issues a standard {Stream,Fetch}Endpoints request for the clusters
  29. // to balance.
  30. //
  31. // Independently, Envoy will initiate a StreamLoadStats bidi stream with a
  32. // management server:
  33. // 1. Once a connection establishes, the management server publishes a
  34. // LoadStatsResponse for all clusters it is interested in learning load
  35. // stats about.
  36. // 2. For each cluster, Envoy load balances incoming traffic to upstream hosts
  37. // based on per-zone weights and/or per-instance weights (if specified)
  38. // based on intra-zone LbPolicy. This information comes from the above
  39. // {Stream,Fetch}Endpoints.
  40. // 3. When upstream hosts reply, they optionally add header <define header
  41. // name> with ASCII representation of EndpointLoadMetricStats.
  42. // 4. Envoy aggregates load reports over the period of time given to it in
  43. // LoadStatsResponse.load_reporting_interval. This includes aggregation
  44. // stats Envoy maintains by itself (total_requests, rpc_errors etc.) as
  45. // well as load metrics from upstream hosts.
  46. // 5. When the timer of load_reporting_interval expires, Envoy sends new
  47. // LoadStatsRequest filled with load reports for each cluster.
  48. // 6. The management server uses the load reports from all reported Envoys
  49. // from around the world, computes global assignment and prepares traffic
  50. // assignment destined for each zone Envoys are located in. Goto 2.
  51. rpc StreamLoadStats(stream LoadStatsRequest) returns (stream LoadStatsResponse) {
  52. }
  53. }
  54. // A load report Envoy sends to the management server.
  55. message LoadStatsRequest {
  56. option (udpa.annotations.versioning).previous_message_type =
  57. "envoy.service.load_stats.v2.LoadStatsRequest";
  58. // Node identifier for Envoy instance.
  59. config.core.v3.Node node = 1;
  60. // A list of load stats to report.
  61. repeated config.endpoint.v3.ClusterStats cluster_stats = 2;
  62. }
  63. // The management server sends envoy a LoadStatsResponse with all clusters it
  64. // is interested in learning load stats about.
  65. message LoadStatsResponse {
  66. option (udpa.annotations.versioning).previous_message_type =
  67. "envoy.service.load_stats.v2.LoadStatsResponse";
  68. // Clusters to report stats for.
  69. // Not populated if *send_all_clusters* is true.
  70. repeated string clusters = 1;
  71. // If true, the client should send all clusters it knows about.
  72. // Only clients that advertise the "envoy.lrs.supports_send_all_clusters" capability in their
  73. // :ref:`client_features<envoy_v3_api_field_config.core.v3.Node.client_features>` field will honor this field.
  74. bool send_all_clusters = 4;
  75. // The minimum interval of time to collect stats over. This is only a minimum for two reasons:
  76. //
  77. // 1. There may be some delay from when the timer fires until stats sampling occurs.
  78. // 2. For clusters that were already feature in the previous *LoadStatsResponse*, any traffic
  79. // that is observed in between the corresponding previous *LoadStatsRequest* and this
  80. // *LoadStatsResponse* will also be accumulated and billed to the cluster. This avoids a period
  81. // of inobservability that might otherwise exists between the messages. New clusters are not
  82. // subject to this consideration.
  83. google.protobuf.Duration load_reporting_interval = 2;
  84. // Set to *true* if the management server supports endpoint granularity
  85. // report.
  86. bool report_endpoint_granularity = 3;
  87. }