diff --git a/src/bitdrift_public/protobuf/ingest/v1/api.proto b/src/bitdrift_public/protobuf/ingest/v1/api.proto deleted file mode 100644 index a267af7..0000000 --- a/src/bitdrift_public/protobuf/ingest/v1/api.proto +++ /dev/null @@ -1,70 +0,0 @@ -// api - bitdrift's client/server API definitions -// Copyright Bitdrift, Inc. All rights reserved. -// -// Use of this source code and APIs are governed by a source available license that can be found in -// the LICENSE file or at: -// https://polyformproject.org/wp-content/uploads/2020/06/PolyForm-Shield-1.0.0.txt - -syntax = "proto3"; - -package bitdrift_public.protobuf.ingest.v1; - -import "google/protobuf/timestamp.proto"; -import "validate/validate.proto"; - -enum MetricPlatformType { - UNSPECIFIED = 0; - APPLE = 1; - ANDROID = 2; - ELECTRON = 3; -} - -message IngestMetricRequest { - // The metric ID that this ingestion request applies to. This ingestion ID will be made available - // in different ways depending on the integration point. See the product documentation for - // when and how this should be used. - string metric_id = 1 [(validate.rules).string = {min_len: 1}]; - - // Metrics must have an attached platform type. For server-side integrations, the platform must - // be propagated from the client. UNSPECIFIED is not a valid platform type and will result in an - // error. - MetricPlatformType platform_type = 2 [(validate.rules).enum.defined_only = true]; - - // Metrics must have an attached app_id. For server-side integrations, the app_id must be - // propagated from the client. - string app_id = 3 [(validate.rules).string = {min_len: 1}]; - - // Metrics must have an attached app_version. For server-side integrations, the app_version - // must be propagated from the client. - string app_version = 4 [(validate.rules).string = {min_len: 1}]; - - // An optional timestamp that the metric should be recorded at. If not supplied, defaults to - // the current server time. - google.protobuf.Timestamp timestamp = 5; - - oneof metric_value_type { - option (validate.required) = true; - - // Increments an integer counter by the supplied delta. If the metric_id does not point to a - // counter, this request will fail. - uint64 counter_delta = 6; - } -} - -message IngestMetricResponse {} - -// All APIs are available at api.bitdrift.io and require token authentication. The product API -// key should be supplied as the x-bitdrift-api-key header. APIs can be called in the following -// forms: -// 1) Standard gRPC (application/grpc) -// 2) Connect (https://connectrpc.com/docs/protocol/) via either application/proto or -// application/json. application/proto is preferred for performance reasons. JSON transcoding -// uses the standard proto3 JSON format as documented here: -// https://developers.google.com/protocol-buffers/docs/proto3#json -service IngestService { - // Ingest a metric into bitdrift as a server-side integration. See the product documentation - // for when and how this should be used. - // - // POST https://api.bitdrift.io/bitdrift_public.protobuf.ingest.v1.IngestService/IngestMetric - rpc IngestMetric(IngestMetricRequest) returns (IngestMetricResponse) {} -} diff --git a/src/bitdrift_public/protobuf/pulse/v1/pulse.proto b/src/bitdrift_public/protobuf/pulse/v1/pulse.proto deleted file mode 100644 index 63bc9fb..0000000 --- a/src/bitdrift_public/protobuf/pulse/v1/pulse.proto +++ /dev/null @@ -1,107 +0,0 @@ -// api - bitdrift's client/server API definitions -// Copyright Bitdrift, Inc. All rights reserved. -// -// Use of this source code and APIs are governed by a source available license that can be found in -// the LICENSE file or at: -// https://polyformproject.org/wp-content/uploads/2020/06/PolyForm-Shield-1.0.0.txt - -syntax = "proto3"; - -package bitdrift_public.protobuf.pulse.v1; - -import "validate/validate.proto"; - -message Kubelet {} -message PodName {} -message Namespace {} -message Service {} -message Deployment {} -message UserProvided { - string name = 1; -} - -message EntityType { - oneof entity_type { - option (validate.required) = true; - - Kubelet kubelet = 1; - Deployment deployment = 2; - PodName pod_name = 3; - Namespace namespace = 4; - Service service = 5; - UserProvided user_provided = 6; - } -} - -message ExtraMetadata { - repeated Metadata items = 1; -} - -message Metadata { - message Annotation { - string key = 1; - string value = 2; - } - - string value = 2; - EntityType metadata_type = 3; - repeated Annotation annotations = 4; -} - -message LoggingObservations { - repeated LoggingObservation observations = 1; -} - -// A set of logging observations that are associated with a specific entity. Pulse will periodically report the logging usage per entity. -// The entities are hierarchical, allowing for the server to aggregate usage at different levels of the system. -message LoggingObservation { - // The number of logs seen since the last observation was sent for this entity. - uint64 delta_count = 1; - - // The total number of number of log bytes seen since the last observation was sent for this entity. - uint64 delta_byte_count = 2; - - // The metadata associated with entity. By reporting a number of different metadata for the entity, the control plane is able to place - // the entity within the topology, allowing for aggregation of usage at different levels of the system. - // - // For example: - // Given - // - The pod PodA that belongs to a ServivceA, and ServiceB - // - The service ServiceA has a team annotation InfraTeam - // - The service ServiceB has a team annotation NetworkingTeam - // - PodA is namespaced with Infra - // - PodA is deployed to a kubelet node1 - // - // The reported metadata will then look like: - // - // metadata: ExtraMetadata { - // items: [ - // Metadata { value: "PodA", entity_type: PodName, annotations: [] }, - // Metadata { value: "ServiceA", entity_type: Service, - // annotations: [ Annotation { key: "team", value: "InfraTeam" }] - // }, - // Metadata { value: "ServiceB", entity_type: Service, - // annotations: [ Annotation { key: "team", value: "NetworkingTeam" }] - // }, - // Metadata { value: "Infra", entity_type: Namespace, annotations: [] }, - // Metadata { value: "node1", entity_type: Kubelet, annotations: [] }, - // ] - // } - // - // The control plane will be able to build following hierarchies: - // - // Team(infra) -> Service(service_a) -> Pod(pod_a) - // Team(networking) -> Service(service_b) -> Pod(pod_a) - // Namespace(infra) -> Pod(pod_a) - // Kubelet(node_1) -> Pod(pod_a) - // - // TODO(snowp): This would be better expressed via a notion of sub-streams, where we initiate - // a stream of data associated with extra metadata. This avoids the repetition of all this data - // and makes it easier to explicitly notify the backend about changes to the system. To support - // this we need extra work to have the client observe the system to know when to drop the sub-streams. - oneof additional_metadata { - option (validate.required) = true; - - ExtraMetadata metadata = 3; - } -}