Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
Key is type name.
Used in:
required; eg "email" for User.email:String!
required; eg "String!" for User.email:String!
Used in:
required; eg "String!" for User.email:String!
Duration histogram; see docs/histograms.md
Used in:
Used in:
,This is the top-level message used by the new traces ingress. This is designed for the apollo-engine-reporting TypeScript agent and will eventually be documented as a public ingress API. This message consists solely of traces; the equivalent of the StatsReport is automatically generated server-side from this message. Agent should either send a trace or include it in the stats for every request in this report. Generally, buffering up until a large size has been reached (say, 4MB) or 5-10 seconds has passed is appropriate. This message used to be know as FullTracesReport, but got renamed since it isn't just for traces anymore
key is statsReportKey (# operationName\nsignature) Note that the nested traces will *not* have a signature or details.operationName (because the key is adequate). We also assume that traces don't have legacy_per_query_implicit_operation_name, and we don't require them to have details.raw_query (which would consume a lot of space and has privacy/data access issues, and isn't currently exposed by our app anyway).
This is the time that the requests in this trace are considered to have taken place If this field is not present the max of the end_time of each trace will be used instead. If there are no traces and no end_time present the report will not be able to be processed. Note: This will override the end_time from traces.
required if no traces in this message
The `service` value embedded within the header key is not guaranteed to contain an actual service, and, in most cases, the service information is trusted to come from upstream processing. If the service _is_ specified in this header, then it is checked to match the context that is reporting it. Otherwise, the service information is deduced from the token context of the reporter and then sent along via other mechanisms (in Kafka, the `ReportKafkaKey). The other information (hostname, agent_version, etc.) is sent by the Apollo Engine Reporting agent, but we do not currently save that information to any of our persistent storage.
Used in:
eg "host-01.example.com"
eg "engineproxy 0.1.0"
required
eg "prod-4279-20160804T065423Z-5-g3cf0aa8" (taken from `git describe --tags`)
eg "node v4.6.0"
eg "Linux box 4.6.5-1-ec2 #1 SMP Mon Aug 1 02:31:38 PDT 2016 x86_64 GNU/Linux"
eg "current", "prod"
An id that is used to represent the schema to Apollo Graph Manager Using this in place of what used to be schema_hash, since that is no longer attached to a schema in the backend.
Used in:
, ,Used in:
,Wall clock time when the trace began.
required
Wall clock time when the trace ended.
required
High precision duration of the trace; may not equal end_time-start_time (eg, if your machine's clock changed during the trace).
required
A tree containing information about all resolvers run directly by this service, including errors.
In addition to details.raw_query, we include a "signature" of the query, which can be normalized: for example, you may want to discard aliases, drop unused operations and fragments, sort fields, etc. The most important thing here is that the signature match the signature in StatsReports. In StatsReports signatures show up as the key in the per_query map (with the operation name prepended). The signature should be a valid GraphQL query. All traces must have a signature; if this Trace is in a FullTracesReport that signature is in the key of traces_per_query rather than in this field. Engineproxy provides the signature in legacy_signature_needs_resigning instead.
Optional: when GraphQL parsing or validation against the GraphQL schema fails, these fields can include reference to the operation being sent for users to dig into the set of operations that are failing validation.
Note: engineproxy always sets client_name, client_version, and client_address to "none". apollo-engine-reporting allows for them to be set by the user.
If this Trace was created by a gateway, this is the query plan, including sub-Traces for federated services. Note that the 'root' tree on the top-level Trace won't contain any resolvers (though it could contain errors that occurred in the gateway itself).
Was this response served from a full query response cache? (In that case the node tree will have no resolvers.)
Was this query specified successfully as a persisted query hash?
Did this query contain both a full query string and a persisted query hash? (This typically means that a previous request was rejected as an unknown persisted query.)
Was this operation registered and a part of the safelist?
Was this operation forbidden due to lack of safelisting?
Older agents (eg the Go engineproxy) relied to some degree on the Engine backend to run their own semi-compatible implementation of a specific variant of query signatures. The backend does not do this for new agents (which set the above 'signature' field). It used to still "re-sign" signatures from engineproxy, but we've now simplified the backend to no longer do this. Deprecated and ignored in FullTracesReports.
Used in:
,use 0 for absent, -1 for 0
Used in:
Used in:
The variables associated with this query (unless the reporting agent is configured to keep them all private). Values are JSON: ie, strings are enclosed in double quotes, etc. The value of a private variable is the empty string.
Deprecated. Engineproxy did not encode variable values as JSON, so you couldn't tell numbers from numeric strings. Send variables_json instead.
This is deprecated and only used for legacy applications don't include this in traces inside a FullTracesReport; the operation name for these traces comes from the key of the traces_per_query map.
Used in:
required
Used in:
Should exclude manual blacklist ("Auth" by default)
TLS was used
by convention "HTTP/1.0", "HTTP/1.1", "HTTP/2" or "h2"
Used in:
Used in:
Used in:
We store information on each resolver execution as a Node on a tree. The structure of the tree corresponds to the structure of the GraphQL response; it does not indicate the order in which resolvers were invoked. Note that nodes representing indexes (and the root node) don't contain all Node fields (eg types and times).
Used in:
The name of the field (for Nodes representing a resolver call) or the index in a list (for intermediate Nodes representing elements of a list). field_name is the name of the field as it appears in the GraphQL response: ie, it may be an alias. (In that case, the original_field_name field holds the actual field name from the schema.) In any context where we're building up a path, we use the response_name rather than the original_field_name.
The field's return type; e.g. "String!" for User.email:String!
The field's parent type; e.g. "User" for User.email:String!
relative to the trace's start_time, in ns
relative to the trace's start_time, in ns
represents a node in the query plan, under which there is a trace tree for that service fetch. In particular, each fetch node represents a call to an implementing service, and calls to implementing services may not be unique. See https://github.com/apollographql/apollo-server/blob/main/packages/apollo-gateway/src/QueryPlan.ts for more information and details.
Used in:
, , ,This represents a node to send an operation to an implementing service
Used in:
XXX When we want to include more details about the sub-operation that was executed against this service, we should include that here in each fetch node. This might include an operation signature, requires directive, reference resolutions, etc.
This Trace only contains start_time, end_time, duration_ns, and root; all timings were calculated **on the federated service**, and clock skew will be handled by the ingress server.
relative to the outer trace's start_time, in ns, measured in the gateway.
Wall clock times measured in the gateway for when this operation was sent and received.
This node represents a way to reach into the response path and attach related entities. XXX Flatten is really not the right name and this node may be renamed in the query planner.
Used in:
This represents a set of nodes to be executed in parallel by the Gateway executor
Used in:
Used in:
This represents a set of nodes to be executed sequentially by the Gateway executor
Used in:
A sequence of traces and stats. An individual trace should either be counted as a stat or trace
Used in:
required; eg "User" for User.email:String!
Used in:
,Key is (eg) "email" for User.email:String!