Get desktop application:
View/edit binary Protocol Buffers messages
Project to create.
Created project.
ID of the record to get.
Found project.
Filter to apply to the list of projects. The filter and all its fields are optional.
The maximum number of projects to return. The service may return fewer than this value. If unspecified, at most 10 projects will be returned. The maximum value is 100; values above 100 will be coerced to 100.
A page token, received from a previous `ListProjects` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `ListProjects` must match the call that provided the page token.
Found projects.
A token that can be sent as `page_token` to retrieve the next page. If this field is empty, there are no subsequent pages.
Project to update.
Field mask indicating a list of fields to update. Currently supported fields: - `display_name` - `update_record_enabled` - `delete_record_enabled` Support for other fields may be added in the future.
Updated project.
ID of the project to create records in.
Records to create. Maximum number of records in a batch is 100.
Created records.
Record to create.
Created record.
ID of the project that owns the record.
ID of the record to delete.
No response data.
(message has no fields)
ID of the project that owns the record.
ID of the record to retrieve.
Found record.
ID of the project that owns the records.
Filter to apply to the list of records. All filter fields are combined with logical AND. All filter fields are optional.
The maximum number of records to return. The service may return fewer than this value. If unspecified, at most 10 records will be returned. The maximum value is 100; values above 100 will be coerced to 100.
A page token, received from a previous `ListRecords` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `ListRecords` must match the call that provided the page token.
Found records.
A token that can be sent as `page_token` to retrieve the next page. If this field is empty, there are no subsequent pages.
Record to update.
Field mask indicating a list of fields to update. Currently supported fields: - `labels` - `resource` - `operation` - `actor` Support for other fields may be added in the future.
Updated record.
Represents the audit record actor.
Used in:
Type of the actor. This field may be used to distinguish different kinds of actors from each other. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. EXAMPLE. In an example social website domain, the following actor types can be used: - USER for a person that updates the post; - SERVICE_ACCOUNT for a system that automatically archives posts when they become outdated.
Domain/application specific identifier of the actor. This field uniquely identifies the actor who triggered the operation. The id must be unique within a `type`. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. BEST PRACTICE. - The id may refer to a user (staff, customer, etc) or to a system (service account, etc), depending on the context of the operation. - This field is required. If, for any reason, there is a case when it is impossible or not desirable to provide actor identity, use a consistent stub value like "unknown".
Custom properties related to the actor. REQUIREMENTS. Mandatory: Keys must conform to the following regexp: [a-zA-Z0-9-_]+. Keys must be at least 1 byte in length. Configurable defaults: Keys must be at most 64 bytes in length. Values must be at most 256 bytes in length. The total size of all keys and values must be at most 2048 bytes.
Describes a filter to apply to the list of projects.
Used in:
Filter projects by their external identifiers.
Describes a filter to apply to the list of records.
Used in:
Return records with the provided labels. This filter works as "has" semantic: all provided labels must be present in the record, but returned records may have other labels.
Return records with the provided resource type.
Return records with the provided resource ID.
Return records with the provided operation type.
Return records with the provided operation ID.
Return records with operation time starting from the provided time, inclusive.
Return records with operation time up to the provided time, exclusive.
Return records with the provided actor type.
Return records with the provided actor ID.
Represents the audit record operation.
Used in:
Type of the operation. This field may be used to categorize operations / actions / events. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. EXAMPLE. In an example social website domain, the following operation types can be used: - CREATE when the post or comment is created; - UPDATE when the post or comment post is updated; - DELETE when the post or comment post is deleted. BEST PRACTICE. - Use `type` for high-level categorization and `id` for identification. For example, there can be multiple ways to create the resource: a user can create a resource from an app, an administrator can create a resource from the back office, a batch of resources can be created from the API - all of these operations can be of type CREATE.
Domain/application specific identifier of the operation. This field identifies the operation that is audited. REQUIREMENTS. Configurable defaults: The value must be at most 512 bytes in length. EXAMPLE. A few examples on how the operation for creating a post comment can be identified: - Simple identifier like "CreateComment" - Event name, e.g. "CommentCreated" - API operation for HTTP, e.g. "POST /posts/101/comments" - API operation for gRPC, e.g. "example.v1.PostService/CreateComment" - Serverless function name - etc. BEST PRACTICE. - There might be different approaches to identifying operations, see EXAMPLE for ideas and suggestions. It is recommended to keep it consistent. - Remember that `type` field can be used for high-level categorization, so it is possible to have different operations with the same type. See `type` field description.
Time when the operation occurred.
Custom properties related to the operation. REQUIREMENTS. Mandatory: Keys must conform to the following regexp: [a-zA-Z0-9-_]+. Keys must be at least 1 byte in length. Configurable defaults: Keys must be at most 64 bytes in length. Values must be at most 256 bytes in length. The total size of all keys and values must be at most 2048 bytes.
Trace context related to the operation.
Status of the operation to distinguish whether it succeeded or failed. BEST PRACTICE. - Depending on your use case, it may be important not only to record completed operations, but failed attempts too. Use this field to distinguish the operation outcome.
Wraps operation status enumeration.
(message has no fields)
Enumerates available operation statuses.
Used in:
Operation status not provided or unknown.
Operation succeeded.
Operation failed.
Represents a project.
Used in: , , , , ,
Internal project identifier.
Time when the project was created.
Display name of the project. REQUIREMENTS. The value must be 3-64 characters long.
Whether to allow updating records for this project. If set, overrides the global setting. Defaults to unset.
Whether to allow deleting records for this project. If set, overrides the global setting. Defaults to unset.
External project identifier. This is an optional field that can be used to store a custom identifier for the project, e.g. for multi-tenancy purposes. Defaults to unset. REQUIREMENTS. The value must be 3-64 characters long.
Represents an audit record.
Used in: , , , , , , ,
Internal record identifier.
Identifier of the project the record belongs to.
Time when the record was created.
Labels for the record that can be used for filtering. The labels are indexed, unlike metadata fields, which means it is possible to find records by their labels. REQUIREMENTS. Mandatory: Keys must conform to the following regexp: [a-zA-Z0-9-_]+. Keys must be at least 1 byte in length. Configurable defaults: Keys must be at most 64 bytes in length. Values must be at most 256 bytes in length. The total size of all keys and values must be at most 2048 bytes. EXAMPLE. In an example social website domain, records for both POST and COMMENT resources can be created with "post_id" label. This way all records related to the post and its comments can be retrieved in chronological order with one request by filtering with "post_id" label. BEST PRACTICE. - Add only labels that are critical for chronological retrieval of records related to multiple resources. - Do not add labels for standard fields (such as resource type) as they are already available for filtering.
Record resource.
Record operation.
Record actor.
Represents the audit record resource.
Used in:
Type of the resource. This field may be used to distinguish different kinds of resources from each other. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. EXAMPLE. In an example social website domain, the following resource types can be used: - POST for content post; - COMMENT for comment to a post. BEST PRACTICE. - Match resource types according to your business domain model. - Keep the variety of resource types under control. This will make it easier to filter and analyze records.
Domain/application specific identifier of the resource. This field uniquely identifies the resource. The id must be unique within a `type`. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. EXAMPLE. In an example social website domain, the value can represent post id, comment id, etc. For singleton resources the name can be used as a resource identifier, e.g. "site_settings" for global site settings that you want to audit.
Custom properties related to the resource. REQUIREMENTS. Mandatory: Keys must conform to the following regexp: [a-zA-Z0-9-_]+. Keys must be at least 1 byte in length. Configurable defaults: Keys must be at most 64 bytes in length. Values must be at most 256 bytes in length. The total size of all keys and values must be at most 2048 bytes.
A list of changes for the resource. This can be used to provide context into what is actually changed. REQUIREMENTS. Configurable defaults: The number of changes must be at most 20 changes. BEST PRACTICE. - Add only changes that are critical for audit trail. Do not add the whole resource as a change, as it will bloat the audit log, making it harder to trace truly important changes. Instead, add only the fields that were actually changed. - There are two strategies for recording operation about resource creation: 1) Do not add any changes about resource creation. If a particular resource attribute was never changed, the state of the resource itself already provides information about this attribute. 2) Add a change about resource creation with all resource fields. For updates, still follow the rule of adding only changed fields.
Represents the audit record resource change item.
Used in:
Name of the change. The name should answer the question "WHAT is changed?". This may be used to distinguish different kinds of resource fields in the set of changes. REQUIREMENTS. Configurable defaults: The value must be at most 256 bytes in length. EXAMPLE. In an example social website domain, assuming we are recording post update where its title was changed, this field can be set to "title".
Change description. This provides human-readable description of this particular change. REQUIREMENTS. Configurable defaults: The value must be at most 1024 bytes in length.
Original value before the operation. REQUIREMENTS. Configurable defaults: The value must be at most 4096 bytes in length.
Changed value of after the operation. REQUIREMENTS. Configurable defaults: The value must be at most 4096 bytes in length.
Represents the audit record operation trace context. Adheres to the W3C Trace Context specification. See: https://www.w3.org/TR/trace-context/
Used in:
Traceparent Header value. REQUIREMENTS. Mandatory: Must be valid W3C traceparent header value. See: https://www.w3.org/TR/trace-context/#traceparent-header
Tracestate Header value. REQUIREMENTS. Mandatory: Must be valid W3C tracestate header value. See: https://www.w3.org/TR/trace-context/#tracestate-header Maximum length of the tracestate is 512 bytes. Can be provided only if valid traceparent is provided as well.