Software Architecture in Golang: Observability

hello my name is mario welcome to another software architecture and go video in today's episode i'm covering observability so what is observability back in 2018 cindy silhan wrote a report called distributed systems of servability published by o'reilly i will be leaving the link in the description so you can check it out she defined observability as a property of a system that has been designed built tested deployed operated monitored maintained and evolved in acknowledgment of failures and errors and i know that sounds like a lot but truly you need to acknowledge errors in order to work with observability now another quote i want to use would be the one by chris richardson that he wrote the book microservices patterns published by o'reilly also in 2018 and he said that observability allows us to understand behavior of an application and troubleshoot problems so what does this mean actually in real life so think about of a collection of services so we are talking about the distributed systems right here so we have our clients our customers that happen to be interacting with an api and that api happens to be also interacting with all apis the way to keep track of what is happening is by collecting different values and signals in each one of those steps one way to think about it would be a sequential timeline that we can refer to using an index or an id rather so when we are requesting from the customer that it happens to be on the left side requesting an api and that api happens to be accessing two different order services we can keep track of all that sequential requests or asynchronous they don't have to be sequential but are the steps that happen in between those via an id and this is just one step of one step of observability and that will be called instrumentation if you are collecting metrics as well like for example cpu usage or maybe you're collecting memory usage which are the typical metrics that you're collecting when dealing with micro services and services in general but you could be also collecting business metric metrics like for example if you have how many orders you deliver that day or maybe how many products you sold and you can react according to those signals and let's not forget about logs which happen to be also collected useful for collecting details specifics that we are as developers as engineers writing down to our a pipeline for collecting values in ops in in the system that we are using for accessibility now what i want to show you next is just a short demonstration of observability using open telemetry i previously cover a video doing this so i will be leaving the link in the description as well so please feel free to check that out the biggest difference will be that now i'm using the v1 version of the package which will be open telemetry and previously i was using an uh on release or non-v1 version not major version of open telemetry but rather than that is practically practically the same so give me a few as usual the link to this example will be in the description of this video i covered this previously briefly when i was discussing open telemetry uh when building micro services in go so this is sort of like a small example of collecting metrics and instrumentation using open telemetry now i want to show you this because open telemetry the v the v1 version was released in september if i correct recall correctly so basically this is already production ready however you need to keep in mind that open telemetry is an open source project and the options that you have for collecting metrics may not be what you need right now i want to be specifically and really honest with you because maybe you should be using open telemetry maybe you should be using a commercial version a commercial solution like maybe new relic or data dog or maybe light step again i will be leaving the links to those commercial tools in the description so just keep that in mind so the example i want to show you is specifically to creating a task and the example that i have right here again just refer to the the source code is pretty straightforward really the most complicated thing about setting up uh open telemetry will be the actual configuration in the beginning other than that every time we are supposed to be making or doing something with our service we should be calling and creating a new span via the tracer okay so that's practically what it is so what i'm going to be doing here is going to get in a new task that is going to be high and for this example i'm just going to be executing it and the task is created just think of if you're not familiar with this project it doesn't really matter what matters is that you have a new action via an http verve that happens to be do something and that something could be interacting with the database calling our main um caching data store and perhaps publishing some events some some to some sort of message bus just working with different data stores basically now jager which is one of the options for exporting data and metrics using open telemetry allows you to collect that information that we had before and then export it in a way that you can visually see it and and somehow determine how long it takes for each how long it takes how long each one of the actions take so you can see what i'm talking about so the red server that i call have defined here is basically our http server i have a task endpoint that is right here called tasks and if i select the one and find the traces you will notice that i use one minute ago i created a new task i interacted with it and this this is what i will show you in the beginning of the video that you have a few different actions which are expands and it demonstrates how long it takes for each one of them so for example you have the task creator is basically calling the internal service which will be the service package and that one is calling the create package will be referring to the memcached package and that one is calling then the postgresql package and i think you are getting the idea of what is happening right here so the whole point of defining this is that you interact or one of your customers interact with your api or service you're basically writing snapshots of the actions that you are doing and then you can collect that information to connect to different microservices and therefore you can determine the whole flow of your application right here obviously i don't have any other connection outside what i have right now but if you were using two different microservices that are connected to each other you will see under one of these lines that is actually calling one of those services and therefore you can connect the interaction to which one of them if you can imagine this in a different way this will be a call to for example a remote data store or a remote service that happened to be used for creating tasks but really in this example i'm just calling and talking to the specific repository that i have right here in my local instance for my service and again please refer to the previous video i recorded because that better explain is much more longer so i want to go and keep it this one as short as possible so give me a few so observability is important because when we are dealing with multiple services that talk to each other we need to have a way to determine how the communication happened in the first place and not only that but collect metrics along the way the way it works with open telemetry for example is that you define a bunch of different spans and each one of them can allow you to define attributes but really the important bit about this is that this logic and this configuration and this knowledge that you're going to be learning from using open telemetry applies to a bunch of commercial tools so if you're using your relic or data dog or light step the idea is basically the same you just define the beginning of your whole sort of quote-unquote transaction you apply a different concrete expanse and all of them indicate a piece of the code that happened in your whole transaction and again transaction is sort of like an overload term but basically it indicates a process that happened during a request or an action that happened to be accessing your api again the whole point of this is that you have a way to get information from these different services collect those metrics and keep an eye out for what happens with those details is another way to not only monitor your system making sure it's working correctly but also a way to indicate what could go wrong uh how things are happening what things are happening and how things are evolving making sure and making sure everything is okay and in a way you know determine the whole flow of your application yeah now going back to open telemetry i know this conclusion is taking too long but going back to open telemetry i think in this case because go is still not officially supported i believe that using open telemetry probably is not a good idea yet and perhaps you should be using a commercial solution instead of using open telemetry again is your decision when you're trying to either implement what we have using open source or going and maybe paying some money is up to you but i personally i think in this case specifically for for officer mobility also using open telemetry with go i think using something like new relic or data dock is a better option or even light light step of course well hopefully all of this makes sense and again observability is just a fundamental thing that you have to consider when building microservices and in general any distributed system because it allows you to you know know exactly what's happening when your systems are communicating with another external either external systems or internal ones and then you can determine how the things are you know communicating with each other and determine what could go wrong and what not so thank you for watching and i will talk to you next time take care

Channel: Mario Carrion

Views: 444

Keywords: golang, golang observability, golang software architecture, golang opentelemetry, golang software architecture opentelemetry, golang microservices

Id: r8JY1AQtkj8

Length: 11min 8sec (668 seconds)

Published: Tue Dec 14 2021