dynamic configuration service

[davexroth]

Use Case

• hypertrace agents should be able to obtain and update their configuration dynamically from a service.

Proposal

• Define a grpc service which the hypertrace agents can use to obtain the AgentConfig configuration. If no config file is specified, and instead a HT_CONFIGURATION_ENDPOINT env var (or arg) is defined the agent will make a client request to the config endpoint to get the configuration. The agent will not start until it's successfully received its configuration.

Below is a proposed grpc service

service ConfigurationService {
  rpc InitialConfiguration(InitialConfigurationRequest) returns (InitialConfigurationRequest) {}
  rpc UpdateConfiguration(UpdateConfigurationRequest) return (UpdateConfigurationResponse) {}
}

message InitialConfigurationRequest {
  // service name is optional, but if set this
  // value will be used for the service name in the returned AgentConfig
  // if empty, the configuration service will define the config name 
  string service_name = 1;
  // hostname on which the agent is running
  string hostname = 2;
  // if running in a containerized environment the container id in which the agent is running
  string container_id = 3;
  // a map of identifiers the configuration service can use to apply a specific configuration to an agent
  map<string, string> identifiers = 4;
}

message InitialConfigurationRequest {
  // the timestamp associated with the configuration. This is the time
  // the configuration was persisted, not when it was sent.  The timestamp
  // should only change when the persisted configuration has changed.
  google.protobuf.Timestamp timestamp = 1;
  // configuration to be applied to the agent at initialization
  AgentConfig agent_config = 2;
}

message UpdateConfigurationRequest {
  // the timestamp of the current configuration
  google.protobuf.Timestamp timestamp = 1;
}

// not all configuration can be changed after the agent has started
// these are the properties which can be dynamically configured
// without restarting the agent
message UpdateConfigurationResponse {
  // the timestamp associated with the configuration
  // if there are no configuration change, this value will
  // equal UpdateConfigurationRequest.timestamp
  google.protobuf.Timestamp timestamp = 1;
  // enable or disable the agent.  This will not remove
  // any instrumentation when set to false, but the agent
  // will turn stop reporting spans, metrics etc
  google.protobuf.BoolValue enabled = 2;
  // data capture configuration which applies to all agents
  DataCapture data_capture = 3;
  // java agent specific configuration
  JavaAgent java_agent = 4;
}

The InitialConfigurationRequest will provide a number of properties which the configuration service can use to associate a configuration with the requesting agent. hostname should always be defined, and container_id should be defined whenever possible.

[pavolloffay]

the agent will not start until it's successfully received its configuration.

This concerns me a bit. Will we support runtime configuration updates as well? If yes the agent could start and in the background get the config.

[pavolloffay]

Shouldn't UpdateConfigurationResponse embed the full AgentConfig object?