WEBVTT
00:00:00.380 --> 00:00:02.500
Welcome to Microsoft Build 2017.
00:00:02.500 --> 00:00:05.310
I'm Rahul Bagaria, and
today I'm going to show you
00:00:05.310 --> 00:00:07.950
some of the ways in which
you can gain more visibility
00:00:07.950 --> 00:00:11.540
in to your web apps and services
with Azure Application Insights.
00:00:13.260 --> 00:00:15.320
What does visibility
mean to you?
00:00:15.320 --> 00:00:17.540
Now, visibility has
different definitions for
00:00:17.540 --> 00:00:19.220
different people.
00:00:19.220 --> 00:00:21.750
If you are an IT professional,
or a developer, or
00:00:21.750 --> 00:00:24.700
a product manager, or
even a business executive,
00:00:24.700 --> 00:00:26.790
visibility has
a different connotation.
00:00:26.790 --> 00:00:29.970
It might mean performance
optimizations, debugging, and
00:00:29.970 --> 00:00:30.600
diagnostics.
00:00:30.600 --> 00:00:33.603
It might mean end to end
visibility across your VMs and
00:00:33.603 --> 00:00:34.560
network.
00:00:34.560 --> 00:00:36.550
It might mean KPI dashboards,
00:00:36.550 --> 00:00:40.380
or, even tracking your customer
engagement and retention.
00:00:40.380 --> 00:00:44.630
So what we want to enable
with Application Insights is
00:00:44.630 --> 00:00:48.950
a continuous monitoring solution
across your DevOps lifecycle.
00:00:48.950 --> 00:00:51.280
Like we all know about
continuous integration and
00:00:51.280 --> 00:00:54.290
continuous deployment,
similarly, monitoring
00:00:54.290 --> 00:00:58.520
needs to be a part of your
entire end to end lifecycle.
00:00:58.520 --> 00:01:01.660
Whether you are a developer
working in, say, Visual Studio
00:01:01.660 --> 00:01:04.890
or you are publishing your app
to production monitoring and
00:01:04.890 --> 00:01:07.030
supporting it while
it is in production.
00:01:07.030 --> 00:01:10.090
Or, even when you are in
the next planning cycle and
00:01:10.090 --> 00:01:13.030
figuring out some
data insights or
00:01:13.030 --> 00:01:16.490
usage insights to make
better product decisions.
00:01:16.490 --> 00:01:20.550
So monitoring is going to be
part of your entire lifecycle,
00:01:20.550 --> 00:01:24.599
and this is one of our strong
teams for Application Insights.
00:01:25.620 --> 00:01:29.960
Now, Application Insights
has three phases to itself.
00:01:29.960 --> 00:01:33.320
So you ingest data from various
different sources, then,
00:01:33.320 --> 00:01:35.040
you explore that data,
00:01:35.040 --> 00:01:38.000
play with that data on
our various portals.
00:01:38.000 --> 00:01:39.320
And then, you can export and
00:01:39.320 --> 00:01:41.600
correlate that with
other data sources.
00:01:41.600 --> 00:01:45.320
So let's look at in some detail.
00:01:45.320 --> 00:01:49.280
Now, to ingest data into
Application Insights, we have
00:01:49.280 --> 00:01:53.780
a bunch of open source SDKs that
you can install in your project.
00:01:53.780 --> 00:01:57.470
And as a special example,
if you had using Visual Studio,
00:01:57.470 --> 00:02:00.010
Application Insights
comes within the box.
00:02:00.010 --> 00:02:01.560
So you just need right-click,
00:02:01.560 --> 00:02:03.740
Add Application Insights,
and that's it.
00:02:03.740 --> 00:02:06.390
No need to write a single
line of code to start getting
00:02:06.390 --> 00:02:06.910
telemetry.
00:02:08.070 --> 00:02:10.770
Then, we have a status monitor
configuration tool, so
00:02:10.770 --> 00:02:14.210
if your app is already there in
production, you can use status
00:02:14.210 --> 00:02:17.260
monitor to start correcting
telemetry without redeploying or
00:02:17.260 --> 00:02:18.270
without changing your code.
00:02:19.470 --> 00:02:21.040
We also have Azure Extensions.
00:02:21.040 --> 00:02:24.430
So if you are using Azure Cloud
Services or App Services,
00:02:24.430 --> 00:02:27.030
you can just simply enable the
extension from the Azure portal.
00:02:28.180 --> 00:02:31.300
We also have a management pack
in Systems and Operations
00:02:31.300 --> 00:02:34.430
Manager that you can send out
the data to Application Insight.
00:02:34.430 --> 00:02:38.980
Or, if you have any custom
data definition or data files,
00:02:38.980 --> 00:02:42.890
you can just simply upload them
using our open schema capability
00:02:42.890 --> 00:02:45.640
for running a hoc
analytics over your data.
00:02:47.210 --> 00:02:50.100
Now, once all that data is in,
we have
00:02:50.100 --> 00:02:53.070
various different portals that
you can take advantage of.
00:02:53.070 --> 00:02:54.660
On the Azure portal,
00:02:54.660 --> 00:02:57.920
Applications Insights is fully
integrated into Azure monitor.
00:02:57.920 --> 00:02:59.960
So you can run all
the auto scaling,
00:02:59.960 --> 00:03:03.610
alerts, all the metrics
views and everything.
00:03:03.610 --> 00:03:06.250
We have an end to end
application map within
00:03:06.250 --> 00:03:08.830
Application Insights which
can give you a topology
00:03:08.830 --> 00:03:11.660
view of your client side and
server side components
00:03:11.660 --> 00:03:13.711
as well as all the dependencies
and their health.
00:03:14.920 --> 00:03:16.170
We have a Live Metrics Stream
00:03:16.170 --> 00:03:19.050
that can give you a real-time
information about your traces,
00:03:19.050 --> 00:03:21.280
performance counters,
custom metrics, and so on.
00:03:22.510 --> 00:03:26.350
Plus, for developers,
we have deeper profiling and
00:03:26.350 --> 00:03:28.830
debugging capabilities that
we are launching at Build.
00:03:30.500 --> 00:03:31.100
More servers,
00:03:31.100 --> 00:03:34.920
so if you are working in Visual
Studio, you don't need to go out
00:03:34.920 --> 00:03:39.070
of Visual Studio context to get
access to all your telemetry.
00:03:39.070 --> 00:03:41.690
Application Insights data
is available right within
00:03:41.690 --> 00:03:44.240
Visual Studio as part of
code lance integration,
00:03:44.240 --> 00:03:46.249
diagnostics hubs,
search, and so on.
00:03:47.730 --> 00:03:51.230
Also, we have ad hoc query
language where you can do
00:03:51.230 --> 00:03:52.140
analytics queries,
00:03:52.140 --> 00:03:55.845
kind of big analytics queries
on top of your data, go deep,
00:03:55.845 --> 00:03:59.790
deep down into your data, and
get any insights that you want.
00:03:59.790 --> 00:04:02.530
We even have some machine
learning operators available as
00:04:02.530 --> 00:04:05.310
part of the query language
that can help you
00:04:05.310 --> 00:04:07.390
identify patterns and
do data mining.
00:04:08.890 --> 00:04:11.610
Now, you might want to
export this data out,
00:04:11.610 --> 00:04:13.450
correlate this data with
other data sources.
00:04:13.450 --> 00:04:16.380
So we have an OMS connector
that can help you take
00:04:16.380 --> 00:04:20.660
the data to your OMS, Operations
Management Suite work spaces and
00:04:20.660 --> 00:04:22.250
run log analytics
on top of that.
00:04:23.400 --> 00:04:26.950
We even have a Power BI
connector where you can
00:04:26.950 --> 00:04:28.660
just export your
data to Power BI.
00:04:28.660 --> 00:04:30.880
Or, if you have written
any analytics queries,
00:04:30.880 --> 00:04:32.630
you can export them
to Power BI as well.
00:04:32.630 --> 00:04:36.570
All your charts can be pinned
to Azure dashboards if you're
00:04:36.570 --> 00:04:39.640
building a consolidated
view to monitor regularly.
00:04:39.640 --> 00:04:43.440
Last, we have various data
access capabilities like a Blob
00:04:43.440 --> 00:04:46.680
storage where you can
continuously export your data,
00:04:46.680 --> 00:04:51.634
or you can use the REST APIs to
access your events metrics or
00:04:51.634 --> 00:04:52.550
queries.
00:04:52.550 --> 00:04:55.490
Also, when I mentioned
continuous monitoring,
00:04:55.490 --> 00:04:58.280
our integration with
Visual Studio Team Services and
00:04:58.280 --> 00:05:00.190
GitHub really proves the point.
00:05:00.190 --> 00:05:03.580
Because, once you discover some
exceptions or things you want to
00:05:03.580 --> 00:05:07.600
do next, you can file VOC item
using these integrations.
00:05:07.600 --> 00:05:11.480
Or, you can take advantage
of released annotations or
00:05:11.480 --> 00:05:14.220
cloud load testing to really
check your application,
00:05:14.220 --> 00:05:15.650
if it's ready for production.
00:05:17.230 --> 00:05:20.610
Now, Application Insights
supports a huge variety of
00:05:20.610 --> 00:05:24.840
platforms, languages,
frameworks, and so on, to date.
00:05:24.840 --> 00:05:28.310
Most of these are available
as open source on our
00:05:28.310 --> 00:05:29.840
GitHub repository.
00:05:29.840 --> 00:05:32.760
And more and
more are coming regularly.
00:05:32.760 --> 00:05:34.429
For example, in this list,
00:05:34.429 --> 00:05:38.534
we have just launched Kubernetes
support, Azure Function support,
00:05:38.534 --> 00:05:42.360
ETW/EventSource support,
right here at Build.
00:05:42.360 --> 00:05:44.000
So you'll see much
more coming soon.
00:05:45.700 --> 00:05:47.780
Now, what's new in
Application Insights?
00:05:47.780 --> 00:05:51.054
Let's spend a couple of
minutes talking about that.
00:05:51.054 --> 00:05:55.650
We have four key investment
areas that we are working on for
00:05:55.650 --> 00:05:57.180
addressing your scenarios.
00:05:57.180 --> 00:05:58.170
Holistic monitoring,
00:05:58.170 --> 00:06:01.910
smart machine learning powered
insights, key developer support,
00:06:01.910 --> 00:06:04.370
and enabling business value.
00:06:04.370 --> 00:06:07.930
So in holistic monitoring,
as I talked before, we have
00:06:07.930 --> 00:06:11.430
enabled support for your Service
Fabric Apps, Node JS Apps,
00:06:11.430 --> 00:06:15.740
Azure Functions, even .NET
Core Apps running on Kubernetes.
00:06:15.740 --> 00:06:18.258
If you have used our Application
Map capability before,
00:06:18.258 --> 00:06:20.468
we have just added
Azure Health integration dev.
00:06:20.468 --> 00:06:22.813
And now,
you can see multi-component,
00:06:22.813 --> 00:06:24.756
multi-role topologies as well.
00:06:24.756 --> 00:06:27.567
In Live Metrics Stream,
you can now check your custom
00:06:27.567 --> 00:06:29.692
metrics and
performance counters, and
00:06:29.692 --> 00:06:32.080
do real-time filtering
on top of your data.
00:06:33.180 --> 00:06:36.510
Plus, this has been a major
ask from our customers.
00:06:36.510 --> 00:06:39.701
Now, you can do client side
JavaScript auto-instrumentation
00:06:39.701 --> 00:06:42.970
directly from Azure portal for
your Azure Web Apps.
00:06:42.970 --> 00:06:43.773
No need to copy and
00:06:43.773 --> 00:06:46.085
paste that JavaScript onto
your project anymore.
00:06:47.975 --> 00:06:49.495
Smart Insights, so
00:06:49.495 --> 00:06:52.245
we have enabled a new capability
in Smart Detection, which can
00:06:52.245 --> 00:06:55.305
automatically discover your
performance degradations and
00:06:55.305 --> 00:06:58.840
lead you to some next steps
with some profiler examples.
00:06:58.840 --> 00:07:00.620
We also have new
machine learning
00:07:00.620 --> 00:07:02.800
query operators in
the Analytics Portal.
00:07:02.800 --> 00:07:05.860
As well as, a capability that
we call Smart Diagnostics,
00:07:05.860 --> 00:07:09.610
that enables you to detect any
sudden changes in your data and
00:07:09.610 --> 00:07:11.780
figure out the most
probable root cause or
00:07:11.780 --> 00:07:13.350
pattern that could
have led to that.
00:07:15.310 --> 00:07:17.030
Talking about Developer Support,
00:07:17.030 --> 00:07:21.030
we have a new Snapshot Debugging
capability, where you can
00:07:21.030 --> 00:07:23.280
debug your exceptions
with local variables and
00:07:23.280 --> 00:07:27.280
everything, right there in
the cloud, in Azure Portal.
00:07:27.280 --> 00:07:30.471
We have
Azure App Insights Profiler,
00:07:30.471 --> 00:07:32.780
that's going ga at Build.
00:07:32.780 --> 00:07:36.020
And you can use it for
performance optimizations for
00:07:36.020 --> 00:07:38.950
your App Services and
there is a preview available for
00:07:38.950 --> 00:07:41.630
Compute, VM scale sets, and
cloud services as well.
00:07:42.820 --> 00:07:45.320
Also, we are launching
some support for
00:07:45.320 --> 00:07:48.380
EventFlow, ETW EventSource
based for high-scale logging
00:07:48.380 --> 00:07:52.025
that can enable you to go deep
into these scenarios as well.
00:07:53.660 --> 00:07:56.000
Last, but not the least,
Business Value.
00:07:56.000 --> 00:07:57.620
So, you might have known,
00:07:57.620 --> 00:08:01.780
we had this usage monitoring
capability for long, but we have
00:08:01.780 --> 00:08:06.190
really started to invest much
more into usage going forward.
00:08:06.190 --> 00:08:07.290
So you'll see more and
00:08:07.290 --> 00:08:11.230
more usage kind of capabilities
targeted to product managers,
00:08:11.230 --> 00:08:13.760
business leaders, and
so on, very soon.
00:08:13.760 --> 00:08:17.342
As an example, in my demo I'll
show you how you can use some
00:08:17.342 --> 00:08:19.978
segmentation filtering
capabilities and
00:08:19.978 --> 00:08:23.580
get more insights about user
sessions and custom events.
00:08:23.580 --> 00:08:26.804
Last, how you can understand
your customer retention and
00:08:26.804 --> 00:08:30.028
discover what happens to people
when they start using your
00:08:30.028 --> 00:08:32.350
feature, how does it impact,
and so on.
00:08:34.650 --> 00:08:37.220
So let's look at the demo and
00:08:37.220 --> 00:08:39.690
jump right into
Application Insights.
00:08:39.690 --> 00:08:43.530
Okay, so this is Azure Portal
and I have opened the customized
00:08:43.530 --> 00:08:46.430
dashboard that where I have
pinned various charts.
00:08:48.210 --> 00:08:49.800
Sorry, I need to restart that.
00:08:51.580 --> 00:08:55.910
Okay, so this is Azure Portal,
and I have a customized
00:08:55.910 --> 00:08:59.350
dashboard open, where I have
pinned various charts, metrics,
00:08:59.350 --> 00:09:02.630
and reports, from various
parts of Application Insights.
00:09:02.630 --> 00:09:04.570
I even have some metrics
from Azure Monitor,
00:09:04.570 --> 00:09:07.850
some analytics queries, I even
have an availability vectors
00:09:07.850 --> 00:09:11.180
chart which is showing
me 76.6% availability.
00:09:11.180 --> 00:09:11.860
Not good, and
00:09:11.860 --> 00:09:15.034
I would want to figure out
how to make that better.
00:09:15.034 --> 00:09:17.120
Now, all these charts and
metrics,
00:09:17.120 --> 00:09:19.630
you can pin to your Azure
dashboard, customize it
00:09:19.630 --> 00:09:22.730
according to your needs, and
share it with your colleagues.
00:09:22.730 --> 00:09:26.620
Now, typically, how does
a monitoring experience start?
00:09:26.620 --> 00:09:29.590
If you recently made
a deployment or
00:09:29.590 --> 00:09:32.380
published a new version, you
might want to check out what's
00:09:32.380 --> 00:09:35.260
happening in real-time to
your application KPIs.
00:09:35.260 --> 00:09:38.290
Are you getting any exceptions,
or field requests, and so on?
00:09:38.290 --> 00:09:41.310
So we have this feature
called Live Metrics Stream,
00:09:41.310 --> 00:09:44.160
I already have it
opened in another tab.
00:09:44.160 --> 00:09:48.220
Now, you can see nine standard
metrics coming to your
00:09:48.220 --> 00:09:49.380
Live Metrics Stream.
00:09:49.380 --> 00:09:50.774
So we have request,
00:09:50.774 --> 00:09:55.127
dependencies, memory, CPU total,
exceptions, and so on.
00:09:55.127 --> 00:09:59.217
Now, these metrics are coming
in real-time, so if I open
00:09:59.217 --> 00:10:03.558
the application, press a button
It will instantly show me all
00:10:03.558 --> 00:10:08.600
the impact that has done to my
code right here on the screen.
00:10:08.600 --> 00:10:11.310
And you can split it or filter
it based on servers as well.
00:10:11.310 --> 00:10:13.370
So you can pick any
particular server and
00:10:13.370 --> 00:10:14.970
just see the data coming
from that server.
00:10:14.970 --> 00:10:20.080
So, on the right hand side
you can see simple telemetry.
00:10:20.080 --> 00:10:23.860
So, these are real time events,
event traces,
00:10:23.860 --> 00:10:25.310
requests, exceptions,
00:10:25.310 --> 00:10:28.370
everything in real time that's
coming to your application.
00:10:28.370 --> 00:10:31.320
Now you would notice that, since
it's a popular application in
00:10:31.320 --> 00:10:34.480
this case, there are a lot
of events coming regularly.
00:10:34.480 --> 00:10:38.110
And it might become difficult
to hone onto a particular one.
00:10:38.110 --> 00:10:42.540
So you can use our filtering
capabilities and probably set up
00:10:42.540 --> 00:10:49.650
a filter here saying my
message contains disconnected.
00:10:49.650 --> 00:10:51.910
I don't want to
see any requests.
00:10:51.910 --> 00:10:53.850
I don't want to see
any dependencies.
00:10:53.850 --> 00:10:55.810
No events, no traces, Save.
00:10:57.130 --> 00:11:01.910
Now, I'll only be seeing those
exceptions with the message
00:11:01.910 --> 00:11:04.930
containing disconnected as part
of this live metrics stream and
00:11:04.930 --> 00:11:05.600
nothing else.
00:11:05.600 --> 00:11:08.740
So it really helps you hone
down to a particular problem.
00:11:08.740 --> 00:11:11.480
And once you click on that
you can see stat race
00:11:11.480 --> 00:11:12.400
in real time as well.
00:11:13.580 --> 00:11:15.360
So this is live metrics stream.
00:11:16.470 --> 00:11:19.370
Now getting back to
the Azure dashboard, you see
00:11:19.370 --> 00:11:23.320
application map here, now this
is helpful when you want to get
00:11:23.320 --> 00:11:26.700
an end to end visibility about
your application topology.
00:11:26.700 --> 00:11:29.150
Now application insights
plots this graph for
00:11:29.150 --> 00:11:32.260
you without you needing to
anything special about it.
00:11:32.260 --> 00:11:34.090
So you can see all your
client side components,
00:11:34.090 --> 00:11:37.390
service side components, any
dependencies that it is calling.
00:11:37.390 --> 00:11:40.260
So, in this case, I have
a couple of SQL databases,
00:11:40.260 --> 00:11:42.285
some Azure blob storage queues,
and
00:11:42.285 --> 00:11:46.376
a couple of other things that
I'm using for this application.
00:11:46.376 --> 00:11:48.970
And in one single
view it tells me that
00:11:48.970 --> 00:11:51.260
one of my components
is unhealthy,
00:11:51.260 --> 00:11:54.810
even in my SQL database there
are some 1.8% failures.
00:11:54.810 --> 00:11:57.190
Now that one,
I really did not expect.
00:11:57.190 --> 00:11:59.250
So let me jump on to that.
00:11:59.250 --> 00:12:01.770
I'll see what those
failures are about.
00:12:01.770 --> 00:12:04.980
Now it's a failed dependency
in my service ticket creation.
00:12:04.980 --> 00:12:06.840
Now that's an important
scenario for me.
00:12:06.840 --> 00:12:08.170
And I want to know
what's happening there.
00:12:09.610 --> 00:12:13.025
So I open that dependency, I see
the error message that there was
00:12:13.025 --> 00:12:15.200
some read-only constraint.
00:12:15.200 --> 00:12:18.740
I can see the actual command was
sent, but I really want to know
00:12:18.740 --> 00:12:22.350
what was happening, what was
the request where it happened.
00:12:22.350 --> 00:12:25.240
So I can click the request in
which this dependency call was
00:12:25.240 --> 00:12:27.790
made, open that actual
request instance.
00:12:30.177 --> 00:12:32.350
And while it's loading, so yeah.
00:12:32.350 --> 00:12:34.390
It's showing me all
the details about that request,
00:12:34.390 --> 00:12:36.970
what was the client IP
address with the last
00:12:36.970 --> 00:12:39.249
update like [INAUDIBLE].
00:12:39.249 --> 00:12:41.830
It shows me any custom
data I was sending.
00:12:41.830 --> 00:12:44.520
There were various
exceptions coming in.
00:12:44.520 --> 00:12:46.450
I can even see
a dependency graph.
00:12:46.450 --> 00:12:49.290
So in this request two
dependency calls were made and
00:12:49.290 --> 00:12:50.270
one of them failed,
00:12:50.270 --> 00:12:54.280
which probably led to the
failure of this request as well.
00:12:54.280 --> 00:12:57.330
Now, I want to see more
details about the exception.
00:12:57.330 --> 00:13:00.270
So once I click on it, I can see
the call stack and everything,
00:13:00.270 --> 00:13:02.180
all the message details.
00:13:02.180 --> 00:13:05.450
Now, if I want my team to
work on it subsequently,
00:13:05.450 --> 00:13:09.140
I can file it as a new work item
which will just set it up on my
00:13:09.140 --> 00:13:09.980
team services account.
00:13:11.230 --> 00:13:15.150
So this is a typical example how
you use diagnostics capability.
00:13:15.150 --> 00:13:17.120
Now, you can use
application insight for
00:13:17.120 --> 00:13:19.220
performance optimizations
as well.
00:13:19.220 --> 00:13:20.900
I already have that open.
00:13:20.900 --> 00:13:23.800
So on my application
overview blade
00:13:25.270 --> 00:13:26.996
you can see all the latest
different graphs,
00:13:26.996 --> 00:13:29.660
server response time,
client side performance,
00:13:29.660 --> 00:13:31.840
all the failures that's coming,
and so on.
00:13:31.840 --> 00:13:35.248
We also have some curated
investigation blades that can
00:13:35.248 --> 00:13:38.860
help you go deeper into
those kinds of scenarios.
00:13:38.860 --> 00:13:43.470
Now, in the performance grid, I
have the open, so I'm seeing for
00:13:43.470 --> 00:13:46.030
the last 24 hours,
there has been a spike.
00:13:47.280 --> 00:13:50.140
Many of my requests
I'll find the 95
00:13:50.140 --> 00:13:51.510
percentile is showing here.
00:13:51.510 --> 00:13:54.820
Now I really want to
see a seven day view.
00:13:54.820 --> 00:13:57.240
So last seven days and
00:13:57.240 --> 00:13:59.870
I want to sort it based
on my 95th percentile.
00:14:01.062 --> 00:14:05.380
Okay, so most of my requests
which are taking more than
00:14:05.380 --> 00:14:08.130
a couple of seconds
are very low in number.
00:14:08.130 --> 00:14:13.140
This one is interesting,
get home index, 35,000 calls and
00:14:13.140 --> 00:14:16.150
95 percentile is one second,
that's really is not good.
00:14:16.150 --> 00:14:19.270
I can click on an example to
jump right to the thread level
00:14:19.270 --> 00:14:23.820
view of that request and figure
out the hot path of that request
00:14:23.820 --> 00:14:26.290
and where it was spending
most of its time.
00:14:26.290 --> 00:14:29.020
It even gives me
a performance tip saying that
00:14:29.020 --> 00:14:31.300
much of this request
was pending waiting.
00:14:31.300 --> 00:14:33.130
We should wait for
the request to be available.
00:14:33.130 --> 00:14:36.200
And it has documentation links
that can enable me to do
00:14:36.200 --> 00:14:37.720
these performance optimizations.
00:14:39.195 --> 00:14:40.735
So all this is interesting.
00:14:40.735 --> 00:14:44.315
These are curated experiences
for you to try out, but what if
00:14:44.315 --> 00:14:48.245
you want to jump deep into your
data, ask those specific queries
00:14:48.245 --> 00:14:52.325
and just work with your data,
discover insights, and so on.
00:14:52.325 --> 00:14:56.425
So we have an analytics portal
that can help you just do that.
00:14:56.425 --> 00:14:59.795
So to navigate to an analytics
portal you basically
00:14:59.795 --> 00:15:02.170
come to your overview blade.
00:15:02.170 --> 00:15:03.970
Click on the analytics
button and
00:15:03.970 --> 00:15:07.790
you will navigate to the portal,
which I have already open here.
00:15:07.790 --> 00:15:11.210
So on the home page,
if you are new to analytics,
00:15:11.210 --> 00:15:13.545
you can see various examples,
some basic and
00:15:13.545 --> 00:15:16.290
advanced tutorials that can
help you get started and
00:15:16.290 --> 00:15:18.680
you accustomed with
the query language.
00:15:18.680 --> 00:15:22.741
And in my experience,
it just takes maximum and
00:15:22.741 --> 00:15:25.470
are, for
people to completely get
00:15:25.470 --> 00:15:28.370
addicted to this
analytics query language.
00:15:28.370 --> 00:15:31.570
So I have a couple of
queries already saved,
00:15:31.570 --> 00:15:33.620
that I can show you
the power of analytics.
00:15:34.840 --> 00:15:38.100
Now one thing you will notice,
it's quite a SQL like
00:15:38.100 --> 00:15:42.140
query language but designed in
a piped format and formatted for
00:15:42.140 --> 00:15:45.410
a diagnostics debugging drill
down kind of an experience.
00:15:45.410 --> 00:15:48.380
So on the left hand side you
can see the various data
00:15:48.380 --> 00:15:51.480
points that we are capturing
traces, events, page views,
00:15:51.480 --> 00:15:54.400
availability, performance
counters, metrics, and so on.
00:15:54.400 --> 00:15:57.190
Now this is what application
insights collects.
00:15:57.190 --> 00:16:00.420
If you have any custom data
file that you want to upload,
00:16:00.420 --> 00:16:03.570
as I said before you can use
this open schema capability,
00:16:03.570 --> 00:16:05.570
give a definition
of your data and
00:16:05.570 --> 00:16:08.120
run telemetry on top
of that as well.
00:16:08.120 --> 00:16:11.250
So let's see some
requests as an example.
00:16:11.250 --> 00:16:13.480
So I'm starting with
a very basic request.
00:16:13.480 --> 00:16:17.420
Just show me the last 100
requests that came in.
00:16:17.420 --> 00:16:22.600
So you click go and it shows
me the last 100 requests with
00:16:22.600 --> 00:16:25.160
all the dimensions
that are available for
00:16:25.160 --> 00:16:27.270
this particular data type.
00:16:27.270 --> 00:16:31.680
So that's interesting, but
what I really want to focus on
00:16:31.680 --> 00:16:36.380
here is all those requests which
took more than three seconds.
00:16:36.380 --> 00:16:40.159
And I want to just rename
them or tag them as too long.
00:16:41.650 --> 00:16:44.790
Because you remember
in our performance
00:16:44.790 --> 00:16:47.650
tab we saw some of the requests
taking multiple seconds.
00:16:47.650 --> 00:16:50.150
And that is really where
I want to focus on.
00:16:50.150 --> 00:16:53.690
So there are various requests,
so most of them are okay, so
00:16:53.690 --> 00:16:55.910
not very easy to visualize here.
00:16:55.910 --> 00:16:59.170
And for that reason I can
convert this to a time chart and
00:16:59.170 --> 00:17:04.080
see an actual SLA kind of
a graph, that can enable me
00:17:04.080 --> 00:17:08.810
to figure out if ever a request
takes more than three seconds,
00:17:08.810 --> 00:17:11.810
it means that my
application is not really
00:17:11.810 --> 00:17:14.020
available from
a SLA perspective.
00:17:14.020 --> 00:17:18.220
So that's a great way to monitor
the health of your application,
00:17:18.220 --> 00:17:18.940
in a practical way.
00:17:20.252 --> 00:17:22.050
Now another interesting
capability and for
00:17:22.050 --> 00:17:24.620
this, I'm showing you an actual
incident that happened
00:17:24.620 --> 00:17:26.948
in this application
way back in January.
00:17:26.948 --> 00:17:29.700
So, we had been monitoring
the requests for
00:17:29.700 --> 00:17:31.380
this particular application and
00:17:31.380 --> 00:17:35.010
we suddenly saw a spike coming
in the middle of January.
00:17:35.010 --> 00:17:38.870
So suddenly the requests started
spiking, and we wanted to know
00:17:38.870 --> 00:17:41.750
what was the root cause,
was it leading to any failures?
00:17:41.750 --> 00:17:45.460
It was basically bombarding all
our databases for no reason.
00:17:45.460 --> 00:17:48.756
So this is where smart
diagnostics can help you.
00:17:48.756 --> 00:17:51.280
And it is powered by machine
learning algorithms in
00:17:51.280 --> 00:17:52.620
the backend.
00:17:52.620 --> 00:17:55.360
So it detects any sudden
changes into your data.
00:17:55.360 --> 00:17:58.090
So for example in this case
you see this purple blip,
00:17:58.090 --> 00:18:01.310
this is basically a spike that
it automatically detected.
00:18:01.310 --> 00:18:02.541
And once you click on it,
00:18:02.541 --> 00:18:05.482
it runs those machine learning
algorithms in the backend.
00:18:05.482 --> 00:18:09.457
And it can identify and give you
the most probable pattern which
00:18:09.457 --> 00:18:12.760
could have been the root
cause of this sudden spike.
00:18:15.020 --> 00:18:16.380
So it's taking a few seconds.
00:18:20.614 --> 00:18:22.300
Okay, it took a few seconds.
00:18:22.300 --> 00:18:27.520
So in this case it's telling me
that this spike most probably
00:18:27.520 --> 00:18:30.280
came from requests coming in
from somewhere in Russia with
00:18:30.280 --> 00:18:33.320
this IP range and
all these various details.
00:18:33.320 --> 00:18:37.030
And in the bottom, I can
see that the spike actually
00:18:37.030 --> 00:18:40.450
was caused only from this
pattern and request coming in
00:18:40.450 --> 00:18:43.290
from other patterns,
other locations and stuff,
00:18:43.290 --> 00:18:46.890
all were behaving regularly in
the normal pattern, and so on.
00:18:46.890 --> 00:18:49.465
So, this can actually help
you go deeper into your data.
00:18:49.465 --> 00:18:51.464
Ask those questions
that you care about.
00:18:51.464 --> 00:18:54.690
And once you have a graph that
you want to regularly monitor,
00:18:54.690 --> 00:18:57.663
you can pin them on Azure
dashboard or even export them to
00:18:57.663 --> 00:19:00.020
Excel or Power BI for
monitoring purposes.
00:19:01.310 --> 00:19:04.864
So this is all great for
developers, IT professionals,
00:19:04.864 --> 00:19:06.425
and support engineers.
00:19:06.425 --> 00:19:09.865
But what about product managers
and program managers in our team
00:19:09.865 --> 00:19:14.715
or even the developers who are
actually trying to identify how
00:19:14.715 --> 00:19:17.205
they can make more
feature improvements,
00:19:17.205 --> 00:19:19.515
take better product decisions,
and so on.
00:19:19.515 --> 00:19:22.105
So we have done a huge
amount of investment
00:19:22.105 --> 00:19:24.805
in our usage capabilities,
helping you provide those
00:19:24.805 --> 00:19:27.050
customer insights
that you really need.
00:19:27.050 --> 00:19:30.860
So, I have the user's
chart opened here.
00:19:30.860 --> 00:19:34.730
So, in this user chart,
you can see various different
00:19:34.730 --> 00:19:37.260
insights that are automatically
powered for you.
00:19:37.260 --> 00:19:40.865
Let me zoom it a bit so
you can see better.
00:19:40.865 --> 00:19:43.851
Okay, so on the right hand side,
you can see some automatic
00:19:43.851 --> 00:19:46.861
segmentation that application
insights has done for you.
00:19:46.861 --> 00:19:52.218
So, across all your users,
you can see that 99% of of them
00:19:52.218 --> 00:19:57.997
came from United States, 11%
of users are using Chrome 57,
00:19:57.997 --> 00:20:03.691
37% went to the CSP net overview
page, and so on and so forth.
00:20:03.691 --> 00:20:05.389
So interesting insights or
00:20:05.389 --> 00:20:09.523
trivia that can Actually help me
discover any unexpected patterns
00:20:09.523 --> 00:20:12.520
that I was really
not looking for.
00:20:12.520 --> 00:20:15.920
So on the left hand side,
you can see a graph of your
00:20:15.920 --> 00:20:18.430
unique users across
the timeline.
00:20:18.430 --> 00:20:21.160
So in this case,
it's A 24 hour timeline.
00:20:21.160 --> 00:20:23.330
And you can change
all of those things.
00:20:23.330 --> 00:20:28.320
Now, you can segment this based
on whatever details you want,
00:20:28.320 --> 00:20:31.940
so you can use this split
by capability here.
00:20:31.940 --> 00:20:35.460
So any custom properties that
you are sending on any default
00:20:35.460 --> 00:20:37.900
properties that app
insights is collecting.
00:20:37.900 --> 00:20:40.690
In this case for example,
I want to split it on country or
00:20:40.690 --> 00:20:46.000
region So you can see all your
users split automatically.
00:20:46.000 --> 00:20:48.840
So you can actually help you
give those interesting insights
00:20:48.840 --> 00:20:50.890
and help you play
with that data.
00:20:50.890 --> 00:20:54.070
On the bottom you can see some
other curated charts as well.
00:20:54.070 --> 00:20:57.520
So I have my top custom events,
00:20:57.520 --> 00:20:59.780
graph about my
application version.
00:20:59.780 --> 00:21:02.860
Some data about the browsers
that customers are using,
00:21:02.860 --> 00:21:04.210
page views and so on.
00:21:04.210 --> 00:21:07.260
And there is a shortcut
here to enable segmentation
00:21:07.260 --> 00:21:07.980
from these as well.
00:21:07.980 --> 00:21:11.050
So if I want segmentation
based on page views
00:21:11.050 --> 00:21:15.590
I just click on that and
I can see it by page name.
00:21:15.590 --> 00:21:24.490
So Going to retention.
00:21:24.490 --> 00:21:27.220
So retention is another
capability in our
00:21:27.220 --> 00:21:29.210
usage monitoring repository.
00:21:29.210 --> 00:21:32.300
So basically this
helps you identify
00:21:32.300 --> 00:21:35.030
what happened to those
customers who came or
00:21:35.030 --> 00:21:38.040
visited your application at
a particular point in time.
00:21:38.040 --> 00:21:40.610
Did they really came back
within the next few days,
00:21:40.610 --> 00:21:43.810
within a week, two weeks, three
weeks, four weeks and so on.
00:21:43.810 --> 00:21:47.280
Can really help you identify the
stickiness of your product and
00:21:47.280 --> 00:21:51.500
maybe you might need to make any
usability changes, experience
00:21:51.500 --> 00:21:55.130
changes to help them engage
with your product much better.
00:21:55.130 --> 00:21:57.750
So, in this case, for
this particular application,
00:21:57.750 --> 00:22:01.910
I am seeing that almost 100% of
my customers come back within
00:22:01.910 --> 00:22:05.170
a few days, but there is
a steep drop off after that.
00:22:05.170 --> 00:22:09.110
And most of them are retained
with us for the next 3 weeks.
00:22:09.110 --> 00:22:10.860
But then many of
them drop out and
00:22:10.860 --> 00:22:13.100
don't come back within a month.
00:22:13.100 --> 00:22:15.980
So, an interesting bit of
insight that can actually
00:22:15.980 --> 00:22:19.200
help you figure out
product experiences.
00:22:19.200 --> 00:22:22.720
On the bottom you can see
those actual segmentations, so
00:22:22.720 --> 00:22:24.530
this is really helpful.
00:22:24.530 --> 00:22:26.440
You do a new feature release and
00:22:26.440 --> 00:22:30.420
you want to identify whether
that release really impacted or
00:22:30.420 --> 00:22:33.900
enhanced your stickiness or
engagement with customers.
00:22:33.900 --> 00:22:36.790
So you might want to see that
you released a feature on April
00:22:37.930 --> 00:22:41.310
2nd and
you want to see what happened to
00:22:41.310 --> 00:22:45.600
customers who visited the
product on that particular day.
00:22:45.600 --> 00:22:48.988
Did they really have an improved
experience and so on?
00:22:48.988 --> 00:22:52.114
And you can define what
your entry point means,
00:22:52.114 --> 00:22:54.620
what your retention point means.
00:22:54.620 --> 00:22:57.690
So in this case, I have
selected that people who did
00:22:57.690 --> 00:22:59.380
anything on the first day and
00:22:59.380 --> 00:23:01.930
did anything when they came
back, that's my definition.
00:23:01.930 --> 00:23:03.620
You can have your
own definition.
00:23:03.620 --> 00:23:04.600
For example,
00:23:04.600 --> 00:23:08.370
if you clicked on a particular
button on the first day,
00:23:08.370 --> 00:23:10.960
you only want to track attention
of those particular customers.
00:23:10.960 --> 00:23:13.790
So you can customize
it as per your needs.
00:23:13.790 --> 00:23:16.190
So this is retention.
00:23:16.190 --> 00:23:19.560
Now how to get started
about all of these things.
00:23:19.560 --> 00:23:22.150
How to actually enable
application insights.
00:23:22.150 --> 00:23:26.820
Now if you're using
Visual Studio it's very simple.
00:23:26.820 --> 00:23:29.261
So you have the project open,
right-click.
00:23:29.261 --> 00:23:32.715
Application Insights, and in
this case I already have added
00:23:32.715 --> 00:23:36.680
Application Insights, but you'll
see add Application Insights.
00:23:36.680 --> 00:23:39.870
So, you just click on that
button and automatically
00:23:39.870 --> 00:23:42.310
instruments your application,
adds them in your package.
00:23:42.310 --> 00:23:43.600
Sets everything up.
00:23:43.600 --> 00:23:45.540
So you don't need to write
a single line of code
00:23:45.540 --> 00:23:47.420
to start collecting data metric.
00:23:47.420 --> 00:23:50.420
Plus, if you want to send the
any custom events, metrics or
00:23:50.420 --> 00:23:53.720
addresses, you have an API
surface available for you.
00:23:53.720 --> 00:23:56.170
That you can use to
send those data points.
00:23:56.170 --> 00:23:59.950
Now, I just want to talk to
you about one advantage of
00:23:59.950 --> 00:24:03.300
using Visual Studio here, and
that's code lines integration.
00:24:03.300 --> 00:24:07.270
So when you're working on your
code actually in Visual Studio,
00:24:07.270 --> 00:24:10.140
you can see live production
telemetry right as part of
00:24:10.140 --> 00:24:11.020
your methods.
00:24:11.020 --> 00:24:14.625
So in this case, I can see 7.2K
requests are actually live
00:24:14.625 --> 00:24:15.968
pinging this method,
00:24:15.968 --> 00:24:19.320
the version which is
available in production.
00:24:19.320 --> 00:24:21.070
And if there were
any Failed Requests,
00:24:21.070 --> 00:24:23.730
I could have clicked
to investigate that.
00:24:23.730 --> 00:24:24.510
For this particular
00:24:24.510 --> 00:24:27.060
method there are some
Failed Requests actually.
00:24:27.060 --> 00:24:29.990
So I can actually click on
investigate here, jump down
00:24:29.990 --> 00:24:33.310
deeper, figure out what's going
on with this particular request.
00:24:33.310 --> 00:24:37.360
So, that's about
Application Insights.
00:24:37.360 --> 00:24:41.040
Let me get back to my deck.
00:24:41.040 --> 00:24:43.970
So, let's summarize
what we saw today.
00:24:43.970 --> 00:24:47.790
Application Insights can
proactively help you identify
00:24:47.790 --> 00:24:51.310
issues and fix them before they
start impacting your customers.
00:24:52.540 --> 00:24:55.228
Whenever you want, you can
go deeper into your data,
00:24:55.228 --> 00:24:57.680
get to ad-hoc analytics and
00:24:57.680 --> 00:25:00.160
ask those questions that
you want answers for.
00:25:00.160 --> 00:25:02.620
And even use machine
learning powered insights
00:25:02.620 --> 00:25:06.580
to get those data mining and
path recognition capabilities.
00:25:06.580 --> 00:25:10.105
Plus, you can diagnose problems
right where you are in
00:25:10.105 --> 00:25:13.385
your development environment as
part of your DevOps workflows.
00:25:13.385 --> 00:25:15.746
So App Insights is
fully customizable for
00:25:15.746 --> 00:25:17.725
your particular scenarios.
00:25:17.725 --> 00:25:21.192
You can use our APIs, you can
use our open source SDK's and
00:25:21.192 --> 00:25:23.182
use it how you see fit.
00:25:23.182 --> 00:25:24.722
You can get started for
free today.
00:25:24.722 --> 00:25:28.032
Just follow this link here,
and you can revisit more
00:25:28.032 --> 00:25:31.132
of our build session
recordings on channel nine.
00:25:31.132 --> 00:25:31.632
Thank you.