Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
Duration histogram for non-cache-hit queries. (See docs/histograms.md for the histogram format.)
These per-version fields were used to understand what versions contributed to this sample when we were implementing the aggregation of this information ourselves using BigTable. However, since the per-version stats don't separate out latency, it makes more sense to have stats reported with contextual information so we can have the specific breakdown we're looking for. These fields are somewhat misleading as we never actually do any per-version awareness with anything reporting in the legacy "per_client_name" stats, and instead use "query_stats_with_context" to have more contextual information.
required
Duration histogram; see docs/histograms.md
TTL histograms for cache misses for the public cache.
TTL histograms for cache misses for the private cache.
Used in:
Used in:
Used in:
required; eg "email" for User.email:String!
required; eg "String!" for User.email:String!
Used in:
deprecated; only set when stored in TypeStat.field
required; eg "String!" for User.email:String!
Duration histogram; see docs/histograms.md
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. Agents should send traces for all requests in this report. Generally, buffering up until a large size has been reached (say, 4MB) or 5-10 seconds has passed is appropriate.
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).
Used in:
MemStats.Sys
MemStats.StackSys
MemStats.HeapSys
MemStats.HeapReleased
MemStats.GCSys
MemStats.StackInuse
MemStats.HeapAlloc
MemStats.HeapObjects
MemStats.TotalAlloc delta
MemStats.Mallocs delta
MemStats.Frees delta
MemStats.PauseTotalNs delta
MemStats.NumGC delta
Used in:
,Used in:
Used in:
Either per_client_name (for back-compat) or query_stats_with_context must be specified. If both are specified, then query_stats_with_context will be used and per_client_name will be ignored. Although the fields in ClientNameStats mention things "per-version," the information in the "per-version" fields will only ever be over the default version, the empty String: "", if arrived at via the FullTracesAggregator.
deprecated; use stats_with_context instead
deprecated; use type_stats_with_context instead
Key is the parent type, e.g. "User" for User.email:String!
deprecated; use type_stats_with_context instead
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"
The hex representation of the sha512 of the introspection response
Used in:
,Top-level message type for the server-side stats endpoint
required
These fields are about properties of the engineproxy and are not generated from FullTracesReports.
Beginning of the period over which stats are collected.
End of the period of which stats are collected.
Only used to interpret mem_stats and time_stats; not generated from FullTracesReports.
Maps from query descriptor to QueryStats. Required unless legacy_per_query_missing_operation_name is set. The keys are strings of the form `# operationName\nsignature` (literal hash and space), with operationName - if there is no operation name.
Older agents (Go engineproxy) didn't explicitly include the operation name in the key of this map, and the server had to parse it out (after a re-signing operation which is no longer performed). The key here is just the query signature. Deprecated.
Deprecated: it was useful in Optics where we had access to the whole schema but has not been ever used in Engine. apollo-engine-reporting will not send it.
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.
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?
-------------------------------------------------------------- Fields below this line are only set by the old Go engineproxy.
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.
Optional: this is the original full query before the signature algorithm is applied. Engineproxy always sent this in all traces, which meant that literal-masking done by the signature algorithm didn't fully hide sensitive data from Engine servers. apollo-engine-reporting does not include this by default. (The Engine frontend does not currently show this field.)
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/master/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:
Just a sequence of traces with the same statsReportKey.
Used in:
Top-level message type for the server-side traces endpoint
required
required
Used in:
required; eg "User" for User.email:String!
Used in:
,deprecated; only set when stored in QueryStats.per_type
deprecated; use per_field_stat instead
Key is (eg) "email" for User.email:String!