 We're going to be talking about application insights today. My name is Isaac Levin. I'm an application development manager at Microsoft, and what I do for my job is I work with customers. I work with customers to better the developer experience. One of the things that I like to talk about with my customers is, how we can do better as it pertains to getting data from our applications to help us fix issues, iterate faster, and bring value to our customers. I have a website, it's listed, and I also have a Twitter and GitHub, if you'd like to follow me there, I would greatly appreciate it. I'm going to say this word a lot over the course of this talk. The word telemetry, so what is the definition of the word telemetry? The Wikipedia slash Webster definition is, telemetry is a collection of measurements or other data at remote or inaccessible points, and they're automatic transmission to receiving equipment for monitoring. That is a very long definition, but how I submiss it for applications is, all the data that our application creates, that's not immediately related to things that the user sees on the screen. When we say that, what questions do we consider when we can think about telemetry and how we can do better by our customers? I'm not going to drain these obviously, but one of the things that I like to see from a customer's perspective is how we can report on how our application functions and some of this data to provide insights that are going to better the business. We're here to talk about App Insights, so maybe we should talk about what is App Insights. App Insights in its purest form, it's a REST API. It's a REST API that's hosted in Azure that allows you to collect telemetry related to your applications. It's a REST API and the data is stored behind the scenes in a NoSQL data store. You send your JSON data from your application to the REST API. It goes through a process to aggregate the data and make it available in that data store. Obviously, from a .NET perspective, since we're at .NETConf, there is an existing SDK owned by Microsoft for application insights, both for the web. I believe that there's one for the desktop, it was created by Orin Novotny, and for every other application that wants to use application insights, there's either an SDK for it or you can create one yourself. When we talk about telemetry, what kind of telemetry are we referring to? Out of the box, application insights collects all of the telemetry that you see here. Request response information, third-party calls such as SQL or HTTP, page views for browser-based applications, and everything that you see here. One thing to call out as well that's really exciting about the release of .NET Core is that application insights now collects event counter data. For instance, like garbage collection and more intricate performance data around .NET Core application, so that's available as of .NET Core 3.0. One of the great things about application insights is since it's a NoSQL solution, you can basically use or pass any data that you like into App Insights and be able to report on it. Think about domain data that you could use to be able to report on in some capacity. I like to show this slide when I talk about application insights because it's really valuable to think about what application is at a holistic level way up top. On the left-hand side, you have your web pages and your services and then all of your dependencies. Web pages, client apps, that would be like your static site or a front-end-only app like a spa. Web service obviously is any back-end type of service that you use. Then dependencies are all the things I mentioned here, mostly SQL and HTTP. All that data gets sent into App Insights and it gets massaged in a way that allows you to report on it in a bunch of different capacities. You can build Power BI reports, or you can look at the data in Visual Studio. Also, there's an Arrest API that's available for application insights that can you can get the raw data out and do with it whatever you like. So the first thing you're probably thinking is, okay, this sounds interesting. I imagine it costs a lot. Well, what if I told you that the cost for applications that you're actually, it scale a pretty inexpensive, right? So you get five gigabytes per customer per month. So what that means is that putting data into App Insights and taking data out of App Insights. You get five gigabytes of Flatten JSON per month. Then if you need additional storage, it's $2.30 per gigabyte per month. One thing to call out about the data retention as well is that application insights just recently changed the data retention so it's now configurable on the portal. So you have the ability to change how long you want that data to be stored for. So when we're moving on, how do we actually get application insights turned on in our applications? So for a.NET developer, most more than likely the easiest way for us to do it is inside of Visual Studio. You have other ways to do it, especially if you're in the IT Pro world, you can install an extension on Azure App Service or Azure VM. If you have an application that's hosted on-prem, you can still leverage application insights by using a status monitoring tool, which instruments an iOS web server. So when you configure it through Visual Studio, all you have to do is right-click on your CS Proj, go to Add, Add Application Insights Telemetry, and it'll come up with a UI or a wizard that looks like this, right? So it asks you to specify what your Azure subscription is and what you want the resource to be. But one thing to call out at the bottom is that you can just add the SDK to try local only. So what that allows you to do is play around with application insights and see if you actually are going to get the value out of it. That is warranted by lighting it up in Azure. So what that'll do is it'll just add the SDK and the wiring for it. Then in the situation where you do want to deploy it to the Cloud, you would just follow this wizard again and create the resource inside of the Azure portal. So once you click Register, it goes through a couple of things. In the.NET Core world, it's going to add some NuGet packages obviously, and it's going to add a line to your startups. Yes, and we'll see what that looks like in a second. But when you're all done, it's going to give you 100 percent and three green bars meaning that you're ready to go. So I think this is a good time to actually show how easy it is to turn on application insights. So what I'm going to do is I'm going to go into my Windows terminal, and what I'm going to do is I'm just going to create a new.NET project. So if I go.NET new web app, which is going to create a razor pages application, I'm going to call it No Insights, and then I'm going to specify the output folder as No Insights. So what that's going to do is that's going to scaffold out a razor page application in.NET Core 3, and I should probably type a bit, not as fast. So.NET new web app.noinsights. So again, this is going to scaffold out razor page for us, and what I'm going to do is I'm going to hop in here, and I'm going to open it up in Visual Studio, and then I'm going to instrument app insights on this application. So if I go inside here, and one of the cool things that I like using with the Visual Studio terminal, Visual Studio command line or PowerShells, I can actually just point it dev.nv, which is the executable that runs Visual Studio at my CS project. So I don't have to then hop out of my command line and go into Windows Explorer to find that particular file. So what this is going to do is it's going to load up Visual Studio for me, and Visual Studio is not responding, but it's back now. So as you can see here, this is just a really, really basic application. If I go into my dependencies, there's nothing really fancy in here. So there's some analyzers and some frameworks, and we'll wait for this to be restored in available in Visual Studio. If you look inside of my startup, all I do is all in my configure services, I just have add razor pages and then some static files. So once I actually want to light up application insights, I just right-click on it, right-click on the CS project, or maybe right-click is not going to work right now. But if you right-click on the CS project, you go down to add, and then you can actually specify ad application insights, and then go through the process of setting up that wizard. So it seems like Visual Studio is hanging. So one of the things that I can do is I have a similar version of this talk actually available on YouTube that you can take a look at as well. For whatever reason, Visual Studio is just having a hard time, and I don't want to have everybody look at Visual Studio lagging or whatever. So we're going to just move on to how we can consume our application data using application insights. So what do I do with this data? So one of the things that we have the ability to do in App Insights is take a look at some of the rich reporting that exists inside of the Azure portal. So this dashboard that you see here, this is a one-button click from your App Insights resource. So once you click that button, it'll generate a dashboard for you that's going to give you a lot of really valuable information. So you also have the ability to see an application map which is a holistic at a high level, all the dependencies and services, instances that you have for your application running. You also have the ability to look at profile information. So in the situation where you have a low-performance call, you can take a look and see line by line, execution by execution, what's taking all the time to run. That gives you a ton of insight into, okay, where can I clean up this application code flow to be a bit more performant. One thing that's great as well about looking at App Insights data in the Azure portal is you have the ability to create these visualizations in metric Explorer. So you can build them either using KQL inside of Log Analytics, which is the querying language for application Insights data, or you can just do it in a WYSIWYG fashion. Also, since application Insights does do some things behind the scenes once you send the data into it, the data that you see, it does take, it couldn't take a couple of minutes to get in there. But if you need to see what's going on your application in real time, you have Live Metric Stream, which is over the wider viewing of the telemetry that's being passed into your App Insights resource. Obviously, in the world of reporting, we have the ability to export our application Insights telemetry into Power BI and do all sorts of things with it. This is just a default user report that's built out for you when you connect application Insights to it. So you have the ability to see some demographic information like where the users are coming from, as well as what operating systems they're using. I was going to show pulling up applications that did in Visual Studio. One of the things that you can do is, while you're debugging locally, you can actually see all the data that's being passed into the App Insights resource at runtime while you're collecting all this, and be able to see some of the details and operations that are flying around. Then finally, I mentioned one of the things that there is a data retention. The application Insights doesn't hold onto your data forever. So if you do value having long-term storage of your application telemetry, you have the ability to use what's called continuous export, which frankly what it does is it exports the data into an Azure Blob Storage container, and from there you're able to do whatever you like with it for as long as you'd like. So I think now we took a look at how you light up an application that's like a .NET new. What I want to show is a more baked solution. So I have an application here, which is a Angular 8 application that uses the .NET Core 3 Web API back-end. So as you can see here, this is just a tour of heroes and some of the heroes here, some of the folks that we're familiar with in the .NET Conf world. So if I take a look here, I can fly around them. But one thing that I see is that whenever I do a search, I get an exception, and I don't know why. However, if I wanted to just look at this at application Insights, I can fly over to Live Metric Stream right here, and what this will do is this will actually pull up the over-the-wire viewing of what's going on with my application, and I can actually jump around here and you'll see some of the things on the left-hand side start to light up. So you'll see that there's dependencies information going on, there's incoming requests, and I can see the CPU utilization for my app service and the commuted memory. But one thing as well that's really valuable is I can actually see sample telemetry over the wire. So if I do a search here for Scott for a mistype name and it'll show, oh, there's a request that returned to 500, and I can see that exception here. If I drill into this exception, it says that it's an argument out of range, and if I scroll, it gives me line numbers. So that's really, really valuable. So in taking a look at some of the ways that we can help triage issues in production, that's really, really valuable. Once the data is actually in App Insights, I can click Investigate and Application Map, and it'll show at a holistic level all things that are going on. So I have one central instance, it's hitting a SQL database, I have some availability tests that are checking the application. If I drill on the SQL side here, I can take a look and do an investigation of some of the performance for some of these calls. So the average duration for my SQL calls is actually very good, it's 77.1, but if it was milliseconds, but if that was too slow, I could have the ability to drill in and then look at sample data for these particular SQL calls. So if I click on one of these end-to-end transactions, I can actually see the SQL query that gets executed on my database behind the scenes. So obviously this is just a select, but if you had a more complex database call, it would be all in there. And that's one of the really valuable things that you can do with App Insights, is you can see the end-to-end transaction. So let's take a look at a particular example here. So if I go back into that App Insights resource, and if I look at my failures, I can see all the failures that have happened over a particular time slice. So as you can see here, I have two types of exceptions, the file not found in argument out of range. I saw earlier when I looked at live stream that I was getting some argument out of range exceptions when I do a search, and what I can do is I can click on the operations and then view one of these particular end-to-end transaction details and it'll tell me what's going on. So if I minimize all of this, it'll see that it made a call and then there was an exception before we'll hit the database. And when I click on that, it gives me a bunch of information about the exception, which I think is really valuable. But if I scroll all the way to the bottom, I got a call stack. And since I'm using async to do a lot of this, some of the sometimes the call stack can be confusing to read. So if I click just my code, it'll actually show the code, right? So line 53 in my hero service and line 31 in my heroes controller. So it gives me the ability to get a ton of value for when I'm triaging application issues in production. And finally, one of the great things about application insights that you can take a view of is you can look at all this data great in tools, but sometimes people just wanna see the data. So if I click on view in logs, I can take any of these things, top exception types for instance, and view them in log analytics directly. So like I said earlier, log analytics is the story mechanism for all application size data as well as all Azure monitor data, which application sites is a part of. So as you can see here, it's gonna load up a query and then it's gonna show me that particular data. Let me just maximize this and scroll all the way over. All right. So as you can see here, I have 139 argument out of range and 24 files. That's really, really valuable. But let's say for instance, the business comes to me with a particular request and they say, hey, Isaac, I really wanna get a slice over the last day where our users are from. And I could easily say, okay, well, I know that all requests are stored. And maybe I wanna summarize that account of all of the unique client or countries by that client or country. So, right? And then they, and I can run this. And then it gives me a table in the last 24 hours. So 23,000 folks from the United States, but also it looks like we have people from Brazil and the Netherlands and Singapore viewing our application. And they say, well, this is a data table. I really don't like that. Well, I would way rather prefer, is I'd rather prefer a chart. And then you provide them this chart. And they say, well, this is a bar chart and our stacked column. I really don't want that. In the past, when we've been building reports for customers, this process of just building reports takes a long time. But they say, oh, I want a donut. And then one click and you have a donut for them. So just think of how quickly you were able to provide that request to your user. And they say, well, I don't really want to go to this particular page to see this report. And you say, okay, that's fine. I can just export it to Power BI. Or if you want to look at the data yourself, I can export to CSV for you. So again, we're talking about adding tools to our tool belt that are gonna make things more successful. One thing as well, like I mentioned earlier with, especially with.NET Core, is you can collect extra performance data. So I want to just show you what that looks like. So if I look at just the performance counters table or collection, I'm sorry. It's gonna show me all sorts of information, right? So I have exceptions thrown per second. I have private bytes and system runtime. But then as you see here, I have information about garbage collection. So in a situation where your application isn't handling memory very well, you can take a look and see what are the GC count values in particular situations with a thread pool count is. And this gives you the ability to get even deeper into why your application isn't performing the way you want. So that's how some of the quick ways that we can take a look at telemetry in our application to be more successful. So moving on to the final part of this talk, one of the things that I think the application has a ton of value in is, you know, our triaging production issues. So I showed some of the cool things that you can do there, but there's additional tools that exists out of App Insights and Visual Studio Enterprise that gives you even more tools to be successful. So how many times have we been in a situation where somebody comes to our desk and says, there's an issue in production, I don't care what you're doing, fix it now, right? So what are the first things that we think of that can cause production issues, right? So I think of the primary things is there's changed the environment, there's some data that's causing issues with code and you have scaling issues, but really anything else can cause issues in production. And when we look to actually try to fix these things, what are some of the things that we actually do? We can copy down some form of production data to a local environment to test, you know, in some situations that's just not scalable, especially for large applications. You know, in some, in other scenarios, we have the ability to look at a production staging environment which maybe has more telemetry turned on or we can actually, you know, spin up an environment to actually look at things a bit better. We can read logs if we really don't like our lives. We can read IAS logs and DB logs and what have you. And then, you know, at the end of the day, sometimes it's just really, really valuable to see what's going on live. So a lot of people will do something like this, right? They'll attach a debugger to production and there's a ton of reasons to why you don't want to do that. The biggest one is that if anybody wants to use your site, they can't anymore. So I'm going to say that's not a good idea, right? We don't want to be in a position where we're affecting the experience of our users to fix an issue, right? We want to be able to create an environment where we can outside of the scope of that production application get more information. And one of the ways that you can do that is using Snapshot Debugger. So Snapshot Debugger, like I said, it's a tool inside of Visual Studio Enterprise that allows you to connect to a point in time exception for your application that's lit up with App Insights. So that doesn't mean that it's only an Azure only feature. So you can have a VM hosted on-prem and still take advantage of Snapshot Debugger. So a Snapshot Debugger actually look like. So when you go into the Azure portal, you have the ability to look at the call stack as well as some of the local variables that existed for a particular point in time of the exception. And one of the things that's important to call out here is you can actually download that snapshot. So what I want to do is I want to show you what that looks like because I think it's really, really awesome. So if I open up, whoops, clicked on the wrong thing. So if I go to one of these failures, right, one of these failures that we saw earlier, I'm gonna drill into that. And when we're inside our Intent Transaction Details for an exception, we can take a look and there's a little button here that says Open Debug Snapshot. So what I can do is I can click on that and what it's gonna do is it's gonna initialize a gateway and it's actually going to start to process what's going on. So what actually is Snapshot Debugger? So Snapshot Debugger is a process that runs side by side with your application. And what it's doing is it's basically collecting information while your application is running and then it's taking the PDBs that are deployed to your production server and it's massaging them into a way that you can take a look at the exception. So as you can see here on the left hand side I have a call stack and I'm gonna click into right here. So it looks like I did a search for Scott and it threw an argument out of range exception. So that's really, really valuable but maybe the exception is a bit more complex. One of the things that I have the ability to do is I can actually download that Snapshot. If I click download Snapshot it's gonna start to download a file. So that download can take some time. So what I did is I actually downloaded one from earlier today, about 45 minutes ago. When you open up that file, which is a diaccession file you get this very interesting message I always think it's kind of cute that we get a warning that we got something from a source, an uninterested source and that source just happened to be Azure in this case. You open up this file in Visual Studio and what it's gonna do is it's gonna give you a mini dump summary. And what that mini dump summary is is it's a collection of all the data related to this exception. So as you can see there's modules here there's times when the exception occurred. So the OS and the CLR version and I have this ability to click a debug with manage only. And what that's gonna do is it's going to load all the symbols that exist for this particular exception. And it's going to actually spin up an experience similar to when you're breaking an application in production. And one thing to call out here is that the actual exception was thrown inside of throwhopers.cs which is part of system core lib. That might not be valuable to a lot of folks but I have the ability to look at the call stack and I see my heroes there and I see an exception was thrown line 53 of this particular class. And what is this exception actually doing? So it looks like I pass in a name, a string and then I make a query from a database and then I try to get the fourth item in that array. What could possibly go wrong when you're trying to access at the specific number of array that array might not have that particular instance. So you get an argument out of range exception. So this is obviously a silly example but I just want to show the thing that you have. So you have the ability to use tooltip and as you can see the name is Bill. If I take a look at the heroes, I have tooltip here. I also have watch and immediate window so I can actually pull up watch and type in name and it's say Bill and then if obviously I can go into the immediate window as well and type in name and that's going to give me Bill. So again, really, really simple scenario but it just shows you just the power of what snapshot debugger can do. So we have about five minutes left so I wanted to take some time for questions. So if you have, if you want to take a look at some of the samples or additional documentation for this talk, I'm using the URL list. So shout out to Burke and Cecil for putting that together, I use it all the time. So if you click on that particular URL or not click on it but if you go to that particular URL it'll give you a handful of links. So access to the GitHub repository to see the Tour of Heroes demo as well as some really valuable documentation on docs.microsoft.com about snapshot debugger and application insights. So we have about five minutes left, like I said so let's take some questions. Perfect, hey, Isaac, thank you so much. And Shane, you got any questions? We had one question that came up sooner but it looks like it got answered and I'll just let you speak to it real quick and the initial question was, is it only for web apps? I think we kind of know the answer. No, it's not just for web apps but if you want to kind of expand on maybe some of the capabilities of the SDK that's out there for other types of apps other than web apps. Yeah, so one in particular, so there is an SDK for WinForms. So that was built by the community and what that gives you is it gives you additional telemetry tracking for when you switch views in a WinForm, right? So that's one example. There's as well one thing to call out is that even though we talked about .NET a lot here any programming language can take advantage of app insights and there's SDKs that exist, not just for .NET but for Java, Node.js, PHP and a lot of the SDKs are either owned by Microsoft or owned by major community members. One good question that came up too is can I use a snapshot debugger in Docker? Yes, you can. So you have the ability to connect to, I believe it's, and I believe the AKS is in preview currently but you should be able to connect to Docker applications even hosted in Linux. Cool. And I think your URL list that you had up there does that have some links to the docs about finding out more about snapshot and websites and all that? It sure does. And one last question I think we might have some time for here is how can I migrate normal logging to app insights? Is it just a matter of using the SDK and things that are in the docs? Yeah, so there is some documentation around that. So if you're using a pretty well-known library like NLog or Log for Net or Serialog, so there are actually adapters that exist which will basically log all of the NLog data into app insights as well. So it's not a matter of you having to rewrite your login mechanism from scratch, you can just append onto that by adding it into app insights. And then obviously if you wanna extend app insights, you have the ability to do so with code in .NET. So you can write track events and track exceptions and all that sort of thing to get all the telemetry you want. Yeah, cool. I can add something too. So I say, my chair, if you know this, but we're actually using app insights on the .NET Conf website. So- I would hope so, because it's awesome. Yes, it's awesome. So we used it because Fritz and I talked about, well, originally it was written in .NET and .NET Framework with MVC5 and so forth. So we migrated to .NET Core 2.2 and we wanted to figure, okay, what's the performance? Are we missing anything? So by using app insights, we were able to figure out where we had missing files because we can actually see the 404. So we're doing, we can look at browser performance, JavaScript performance. So it was great for us to kind of fine tune it and go as we liked. So it's a great tool, especially for like migration or just to figure out what's going inside your app. And really all we did is we deployed it to an Azure app service, went to the left-hand side and said, app insights, enabled. And that was it. And the magic happened. Yeah, exactly. So that's one of the great things about app insights is that lighting it up is really easy. So even if you don't have an application that's hosted in Azure, it's pretty easy on-prem as well. So there's a UI-based instrumentation tool without code and there's also a PowerShell-driven one as well. So you don't need the code to actually turn on app insights, which is great. Yeah, no, and that's, some people in the chat, as you were talking about, we're also bringing about Google Analytics and it's like, should we use Google Analytics, app insights, and like for us, we're using both. Right? Yeah, why not? For us, Analytics is great to figure out how many people they're at, where they're coming from and it's a nice quick little dashboard overview, but it provides some information, not all the information that we care about how the website is performing. Like we were able to see CPU. A good example of this, when the keynote started, the CPU was getting hotter and hotter and hotter. We were at 75, 80% CPU on a really large app service instance and we were able to get those details thanks to app insights. Yeah, no, that's awesome. Sweet. All right, we're right on time. So we're gonna get finished here. So thank you so much, Isaac. We got Syed here talking about Visual Studio for Mac. So we're gonna flip here a little bit and we'll be right back.