|
| 1 | +--- |
| 2 | +description: SUSE Observability |
| 3 | +--- |
| 4 | + |
| 5 | +# Open Telemetry concepts |
| 6 | + |
| 7 | +This is a summary of the most important concepts in Open Telemetry and should be sufficient to get started. For a more detailed introduction use the [Open Telemetry documentation](https://opentelemetry.io/docs/concepts/) |
| 8 | + |
| 9 | +## Signals |
| 10 | + |
| 11 | +Open Telemetry recognizes 3 telemetry signals: |
| 12 | + |
| 13 | +* Traces |
| 14 | +* Metrics |
| 15 | +* Logs |
| 16 | + |
| 17 | +At the momemt SUSE Observability supports traces and metrics, logs will be supported in a future version. For Kubernetes logs it is possible to use the [SUSE Observability agent](/k8s-quick-start-guide.md) instead. |
| 18 | + |
| 19 | +### Traces |
| 20 | + |
| 21 | +Traces allow us to visualize the path of a request through your application. A trace consists of one or more spans that together form a tree, a single trace can be entirely within a single service, but it can also go across many services. Each span represents an operation in the processing of the request and has: |
| 22 | +* a name |
| 23 | +* start and end time, from that a duration can be calculated |
| 24 | +* status |
| 25 | +* attributes |
| 26 | +* resource attributes (see [resources](#resources)) |
| 27 | +* events |
| 28 | + |
| 29 | +Span attributes are used to provide metadata for the span, for example a span that for an operation that places an order can have the `orderId` as an attribute, or a span for an HTTP operation can have the HTTP method and URL as attributes. |
| 30 | + |
| 31 | +Span events can be used to represent a point in time where something important happened within the operation of the span. For example if the span failed there can be an `exception` or an `error` event that captures the error message, a stacktrace and the exact point in time the error occurred. |
| 32 | + |
| 33 | +### Metrics |
| 34 | + |
| 35 | +Metrics are measurements captured at runtime and they result in a metric event. Metrics are important indicators for application performance and availability and are often used to alert on an outage or performance problem. Metrics have: |
| 36 | +* a name |
| 37 | +* a timestamp |
| 38 | +* a kind (counter, gauge, histogram, etc.) |
| 39 | +* attributes |
| 40 | +* resource attributes (see [resources](#resources)) |
| 41 | + |
| 42 | +Attributes provide the metadata for a metric. |
| 43 | + |
| 44 | +## Resources |
| 45 | + |
| 46 | +A resource is the entity that produces the telemetry data. The resource attributes provide the metadata for the resource. For example a process running in a container, in a pod, in a namespace in a Kubernetes cluster can have resource attributes for all these entities. |
| 47 | + |
| 48 | +Resource attributes are often automatically assigned by the SDKs. However it is recommended to always set the `service.name` and `service.namespace` attributes explicitly. The first one is the logical name for the service, if not set the SDK will set an `unknown_service` value making it very hard to use the data later in SUSE Observability. The namespace is a convenient way to organize your services, especially useful if you have the same services running in multiple locations. |
| 49 | + |
| 50 | +## Semantic conventions |
| 51 | + |
| 52 | +Open Telemetry defines common names for operations and data, they call this the semantic conventions. Semantic conventions follow a naming scheme that allows for standardizing processing of data across languages, libraries and code bases. There are semantic conventions for all signals and for resource attributes. They are defined for many different platforms and operations on the [Open Telemetry website](https://opentelemetry.io/docs/specs/semconv/attributes-registry/). SDKs make use of the semantic convetions to assign these attributes and SUSE Observability also respects the semantic conventions and relies on them, for example to recognize Kubernetes resources. |
| 53 | + |
0 commit comments