So observability , signals play a central role 
→ it’s the intel we’re basing our decisions on oky , 

Any system under obserbvability emits some signals , 
These signals can be used to understand the system and make decisions to influence it 


Q- m3nha el signal howma all “singnal” el system y emit fihom y5alik tnjm 
T3rf el state mt3o and tnjm t3ml influence 3lih (proactive or reactive oky ) 


→ donc in terms of signals (and sources) we can differentialte betwenn two cases : 

Source , such as code, that you own and can instrument yourself (that is , decide where and what kind of signals to emit ) 
Sources you don’t own , meaning any signals will be predefined , Your task is limited to selecting which signals to consume , 
* — code that is a dependency of your code (library ,package , module , etc..) 
— The component’s source code is not available (eg a binary file ) 
– the component only offers a (networked ) api , any managed service from your cloud provider of choice falls into this category oky 


→ no matter you own or do not own you the code , you need to collect these signals and send them to a central palace for processing and storage , 
This what we call the “Telemetry part “ 


→ also in to think in term of “(ROI) not only you need to understand this singls but also understznd the cost of they 

In the context of observability, signals play a central role: this is the intel we’re basing our decisions on. On a high level, we can differentiate between signals numerical in nature (e.g., the number of service invocations) and signals that carry textual payload that requires human interpretation (e.g., a log line). As discussed in chapter 1, the system under observation, or just system (e.g., a Kubernetes application or a serverless app based on Lambda functions), emits signals from various sources. You, as a human, or equally a piece of software, then use these signals to understand the system and make decisions to influence it. There is a one-to-many relation between the system and sources. Your system typically involves compute, storage, and network, each of these representing a signal source. We will cover the sources in detail in chapter 3. This chapter covers  What different signal types are  When and how to use a certain signal type  The costs and benefits of each signal type  How to figure out which signals are relevant  Determining signal baselines 2.1 Reference example 15 In terms of signals (and sources), we can differentiate between two cases:  Sources, such as code, that you own and can instrument yourself (that is, decide where and what kind of signals to emit).  Sources you don’t own, meaning any signals will be predefined. Your task is limited to selecting which signals to consume, in this case. This might be due to several reasons: – Code that is a dependency of your code (library, package, module, etc.). – The component’s source code is not available (e.g., a binary file). – The component only offers a (networked) API. Any managed service from your cloud provider of choice falls into this category. No matter whether you own the code and can decide what signal types to emit or are working with a component you don’t own, at some point in time, you want to collect the signals and send them to a central place for processing and storage. This is the telemetry part. With observability, you want to take an approach driven by return on investment (ROI). In other words, you not only need to understand the different signals available but also the costs of each signal type and what they enable you to do. In this chapter, we will review the most common signal types, examine how to instrument and collect each, and discuss the costs and benefits of doing so

Q- so let’s take an hands on approch here oky 
  Let’s say my operational application use microsrices architeture oky 

With a product , order , inventory service oky 
(the stack is java spring ecosutem oky ) 

Q- first tell implement a minilste crud application for each service oky here