Tracking the entire path of execution of a service or a function from start until end. e.g. During an upload, tracking when a file handle is received, opened, sanitized and uploaded to the cloud.
The unit of traversal during tracing. Each span might have a children spans within it or it might be the first in its generation and called a root.
The first span in a trace; this span does not have a parent.
A span with a parent span; it represents a call that originates from an already traced one.
A span MAY or MAY NOT be a child and spans can coexist as siblings on the same level.
A tree of spans. A trace has a root span that encapsulates all the spans from start to end, and the children spans being the distinct calls invoked in between.
Is the mechanism that determines how often the system will trace a request.
There are 3 types of sampling:
Any quantifiable measurement/metric that you would like to track, it could be number of requests, number of failed responses, bytes downloaded, cache misses, number of radios purchsed etc.
The style of characterizing measures. We have 4 types of Aggregations:
Tags are key-value pairs that are used to store information about metrics for example;
A view is a mechanism for grouping measures, aggregations, tags as well as the timing information, essentially characterizing your metrics for visualization and inspection.
The grouping of a set of rows that uniquely describe the collection of a measure, its start and end times and the associated view.
It groups the data aggregation with distinct tags.
Remote Procedure Call. The mechanism of invoking a procedure/subroutine in a different scope/address space.
The mechanism by which identifiable information about a span, e.g. traceId, spanId and traceOptions are sent over RPC scope boundaries. This span can then be linked as a remote parent. This movement could translate to getting information such as “the data storage team” invoked delete on the “database records” service which then invoked the “data consistency service”.
The adapters that allow for metrics and traces collected by OpenCensus to be consumed by other services.
OpenCensus adds minimal overhead to your applications while still giving you the ability to export metrics and traces in near real-time to various backends of your choice, simultaneously e.g Stackdriver Monitoring and Tracing, Prometheus, SignalFX, Jaeger. The multiplicity and convenience enables many application performance monitoring teams and even administrators visualize your applications. Your teams don’t have to expend precious time in maintenance and integration; OpenCensus should just work. We have some examples that you can check out to instrument your backends too. With the ability to introspect your applications, you can apply sound engineering practices making your teams even more productive.