Observability demo

Watch a live demo of observability in Adobe Commerce. This demo shows how webhooks and event workflows connect different services to make order tracking and problem-solving easier. See how orders are placed, errors are fixed, and processes are checked. Learn about synchronous and asynchronous flows. It also explains how traces and logs appear in Grafana and New Relic for troubleshooting. Learn why correlation is important for finding slow spots and keeping systems working smoothly.

Who is this video for?

  • Adobe Commerce Developer
  • Solutions Architect
  • Technical Product Manager

Video content

  • Demonstrates Adobe Commerce observability with real order workflows
  • Explains correlation of webhooks and events for traceability
  • Shows integration with Grafana and New Relic for logs and traces
Transcript

Hi, this is Russell with Adobe. This session was taken from a previously recorded demo where the Adobe team was going over observability. We’re going to pick up where the speaker is starting the demo, and so you can get a real example for how this works. I’m going to go to the catalog, add a new item to the cart.

So now we’re going to buy two of these hoodies, check out. The webhooks are working normally as I showcased before.

Let’s complete the order, which this time it failed again. Okay, let’s see. Now we’re seeing things as expected. We have the webhook, we just started in Adobe Commerce, you can see here in the service name. This is the checkout batch of the webhooks about checkout with the shipping rates hook.

Then this webhook is invoking this App Builder project, which is named Commerce Checkout Starter Kit, Absolutely related demo, and it’s creating this shipping operation.

This is how correlation works between commerce and App Builder. You are able to see a trace that started in Adobe Commerce, and the App Builder trace is automatically attached to the original trace. You can see everything as a single flow. This works only for webhooks because they are a synchronous process, so everything is part of the same trace. For events, we’re going to see now it works a bit differently because events is essentially an asynchronous workflow, so you cannot attach an event that it’s executed from App Builder to the commerce that emitted it, because they are two separate processes, but you can still correlate them via the ID. We’re going to see if we are able to make an order.

You can see here the webhook that validated the order with AppOrderManagement, it failed again. Now if I go to here, I’m going to be able to see why, because the random number was 31 and valid is false. Let me deploy a change to ensure that this may succeed easier or I’m going to just return true, so we don’t get this to be much longer.

So it’s going to be- In time that the problem is happening, just let me reiterate the importance of all correlation is in that case. An example that I was putting before about what happened before the order placement, the example that you are doing three different checks to complete three different App Builder applications. In that case, we will have a unique trace and then we’ll have three attached spans each one of them for one of the individual apps. So for you will be visually really easily to understand, A, the ERP is taking like 80 percent of the time, versus the rest of the calls are really quick, basically which are different things that I am logging in each one of the app for traceability perspective. So you will be able to see from a single plugin on commerce, all the different things that are attached and who could be the one that is generating the trouble, if it’s any. So continuing where we left, because I’ve changed now the validation to always be true. Now we were able to make our order, and if I go to the traces again, we should get here another Sales API order. This is the one from before and this is the one from now. Oh no, I actually got confused. Let me see if I can order this one. Yeah, this is the one that succeeded now because the validation was successfully set to true.

If you want to see the logs of this specific trace, this is the power of correlation that Danny was talking. I can check, for example, this span and click here, logs for this span, and I’m going to see here these are the logs that commerce generated because that span was from commerce. So these are the logs that commerce locked. So send your request to a URL, this one, which is the app builder URL. If I go back and, for example, click on the logs for this span, which is the app builder one, I’m going to see here, validating order, blah, blah, blah. So this is a cut-off, but this is the log that you get on your app builder site. You can also see the logs per service and not only per span. So for example, I have here my checkout starter kit logs and my head of commerce logs.

Because now we have successfully placed the order, we should be able to see the event that fired after completing the order, which should be this one. This is the consume main. Again, as I said, because events are asynchronous workflows, you can correlate as part of the same trace when the event was emitted and when it was actually executed because they are different processes. But from here, which is the span of the app builder execution that picked that event, you are going to receive here a trace ID, which you can copy and then go to your logs, for example. Filter in Adobe Commerce by this trace ID equals, and this one.

This is the log that commerce emitted at the time of emission, which you can also use to debug and these things. As of today, observability subscriptions for events only support, I think, logs, not traces, yeah, logs, eventing. Yeah, so eventing only supports logs for now. Probably in the future, it’s going to support also traces. But now traces, which means this span that you are seeing in Raffana, are only supported by webhooks. Let’s see now quickly how it also works with New Relic. I have here the services that were ingested by New Relic. I’m going to go, for example, to the logs and you’re going to see here that every log was also received by New Relic because commerce had this dual subscription, one with Raffana and another one with New Relic, which you can see it works with both exactly the same. As it works with New Relic, it can work with any other provider.

Let’s see if traces appear because they are really bit slow to ingest. You can see for the webhook, shipping rates, the get rates webhook. I can see all these spans from previous executions and the most recent one, which is the four minutes ago one.

I also have the service of SurtiDemo, which probably it’s not going to show anything because I’ve deleted it. But let’s see if something appears.

This is because I deleted from the code just to be able to make it work again. But you are going to receive things in both services just fine.

Well, that’s it for this session on the live demo for observability. I hope you watch the rest of the videos in this series, as well as you continue to learn more about Adobe Commerce and all of the other Adobe products here in Experience League.

recommendation-more-help
3a5f7e19-f383-4af8-8983-d01154c1402f