Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
Key is type name. This structure provides data for the count and latency of individual field executions and thus only reflects operations for which field-level tracing occurred.
Used in:
required; eg "String!" for User.email:String!
Number of errors whose path is this field. Note that we assume that error tracking does *not* require field-level instrumentation so this *will* include errors from requests that don't contribute to the `observed_execution_count` field (and does not need to be scaled by field_execution_weight).
Number of times that the resolver for this field is directly observed being executed.
Same as `count` but potentially scaled upwards if the server was only performing field-level instrumentation on a sampling of operations. For example, if the server randomly instruments 1% of requests for this operation, this number will be 100 times greater than `observed_execution_count`. (When aggregating a Trace into FieldStats, this number goes up by the trace's `field_execution_weight` for each observed field execution, while `observed_execution_count` above goes up by 1.)
Number of times the resolver for this field is executed that resulted in at least one error. "Request" is a misnomer here as this corresponds to resolver calls, not overall operations. Like `errors_count` above, this includes all requests rather than just requests with field-level instrumentation.
Duration histogram for the latency of this field. Note that it is scaled in the same way as estimated_execution_count so its "total count" might be greater than `observed_execution_count` and may not exactly equal `estimated_execution_count` due to rounding.
Used in:
Used in:
,The number of requests that were executed without field-level instrumentation (and thus do not contribute to `observed_execution_count` fields on this message's cousin-twice-removed FieldStats).
Used in:
Contains (eg) "email" for User.email:String!
True if this type is an interface.
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
Total number of operations processed during this period.
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 "mygraph@myvariant"
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"
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:
,Wallclock time when the trace began.
required
Wallclock 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.
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?
Some servers don't do field-level instrumentation for every request and assign each request a "weight" for each request that they do instrument. When this trace is aggregated into field usage stats, it should count as this value towards the estimated_execution_count rather than just 1. This value should typically be at least 1. 0 is treated as 1 for backwards compatibility.
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.
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.
Wallclock 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 operation should either be described as a trace or as part of stats, but not both.
Used in:
This describes the fields referenced in the operation. Note that this may include fields that don't show up in FieldStats (due to being interface fields, being nested under null fields or empty lists or non-matching fragments or `@include` or `@skip`, etc). It also may be missing fields that show up in FieldStats (as FieldStats will include the concrete object type for fields referenced via an interface type).
This field is used to validate that the algorithm used to construct `stats_with_context` matches similar algorithms in Apollo's servers. It is otherwise ignored and should not be included in reports.
Used in:
,Key is (eg) "email" for User.email:String!