[MUSIC]
>> Hi. We are happy to join this virtual event.
It is exciting to see all people that are connected.
These are unique and challenging days for all of us,
and we did our best to connect with you.
We hope this finds you and your beloved ones safe and healthy.
My name is Noa Kuperberg,
I'm PM of Azure Monitor Logs.
>> Hi. My name is Meir Mendelovich,
and I'm also a PM in the Logs team.
Today we will talk about Azure Monitor Logs workspaces,
or in short, workspaces.
We will see what they are,
how many of them you need,
and how to manage them.
I think the first question we need to answer,
is what are workspaces and how they are defined.
>> Workspaces are logical containers of data and settings.
Workspace data is consisted of sets of tables and logs.
In Azure Monitor Logs,
we don't handle logs as meaningless strings of text,
but instead organize them using well defined schemas.
This helps us analyze the data properly and efficiently.
The data ingested to the workspace is stored in a specific region.
Within the region, the data placement is optimized for
efficient storage and quick analytical queries.
The second aspect of a workspace is settings.
The workspace is an administrative scope
for many different settings.
Things like retention period,
access control, daily data cap,
pricing tier, and much more.
In many cases, we allow more granular scoping
of settings to specific tables within the workspace.
For example, you can set different retention and
different daily cap limits for each table in the workspace.
Meir, we are often asked,
what is the right size for a workspace?
What are its limits?
>> The answer is that workspaces have a wide range,
from few gigabytes to
gigantic workspaces it store petabytes of logs amount.
We've workspaces that receive just a sporadic logs here and there,
and workspaces that have
ingestion rate of tens of terabytes per day.
Of course, they are not handled by the system the same way.
Behind the scenes, the system is doing a lot of optimization.
It moves the data,
it scares the back-end,
and it adjust it for different usage patterns.
All these optimizations occur while taking into
consideration all the settings such as retention,
region, access control, and so many more.
The nice thing is that you as the administrator,
doesn't have to do anything.
You doesn't have to take care of that.
You can start small, testing your workspace,
and slowly increase the volume of data that is being sent.
Everything happens behind the scenes automatically.
We do ask customer to contact us if
they're ingesting more than few terabytes per day.
So we would have some visibility to do resource planning.
Until you reach this scale,
you don't have to do anything,
just send more logs.
>> Customers are also asking us
how many workspaces they should have.
The short answer is,
as few as your business requires.
Centralizing your logs in
just a few workspaces means less admin work.
You create your queries, alerts,
and dashboards only once,
and easily monitor all your data.
In other words, queries, alerts,
and dashboards are managed
separately for each workspace you create.
So centralizing your data in
just a few workspaces means less management work.
Our experience shows that 1-3 workspaces are usually enough.
If needed, Azure Monitor does support
querying blogs across multiple workspaces,
and we do see organizations that choose to
have even dozens of active workspaces.
That's also fine, if that's what you really need.
So how can you tell?
The main reason to have multiple workspaces is regulation.
Large organizations often have
a variety of data regulations to consider,
and this drives them to use
separate workspaces across their different geographies.
But regulations don't affect just the location of the data,
they may also affect settings and user access.
For example, many organizations require
different settings for production and pre-production environments.
While production environments often require
long data retention and storing every log record,
in dev or test environments, it's completely different.
It's common to use shorter retention and apply
data capping if large volumes of
data are sent through the workspace.
Another reason to use multiple workspaces is
to match the geographic spread of your resources,
and how you plan to manage them.
For example, if half of your resources are
located in Asia and half in Europe,
it may make sense to send their logs to local workspaces,
especially if you plan to set
separate alerts and dashboards for each of your regions.
This is also true if availability is a priority for you,
and you want to make sure that the monitoring of some regions
isn't affected by local incident that may cure in another region.
When there are no such requirements,
you can use one workspace to
monitor resources from different regions.
While there are somewhat
network charges for sending data across regions,
these charges are relatively very small,
and the benefit of simplifying
your monitoring work often outweighs them.
Customers also ask us
if they need a different workspace for each team.
The typical answer is no.
Most teams in an organization has the same workspace settings,
and the same IT group is usually expected to manage it.
So it would make more sense for them to use a single workspace.
There are also many vertical units
that need to be able to access logs across teams,
such as security, networking, and others.
The work of such vertical teams is much
easier if all logs are stored in one workspace,
without the need to run multiple queries
or cross workspace queries.
Still, there are organizations that have a different approach,
where each team is a completely separate unit
and there are no central functions.
If this is the case,
go ahead and use separate workspaces.
>> The next challenge is what happen if you follow this guidance,
and put all data in one place.
How do I control access to it?
We have designed Azure Monitor Logs exactly for this scenario.
We have built into Azure Monitor
two parallel mechanisms to control access.
Two mechanisms that work in tandem, side-by-side.
The first one is access to the entire workspace,
or to specific tables within the workspace.
We call this workspace contract.
If a user has access to the entire workspace,
he or she can access all data within the workspace.
This is good for users from vertical teams,
like security and central monitoring,
they need access to specific data across the entire organization.
The second type of access control is called Resource-Context.
This mode is unique to Azure Monitor Logs.
It is based on
the access rights to the resource that emitted the logs.
The idea is that if someone has access to
a virtual machine or to any resource,
they should be able to access its logs,
but only its logs.
If they don't have access to a resource,
they wouldn't be able to see the logs.
This mode is suitable for
DevOps teams that need access just to their resource logs.
When the system receives
the query that is sent in Resource-Context,
it verifies that the user has read access to this resource.
Then, it locates all the workspaces
that has data about this resource,
and executes the query so only this resource logs are accessible.
As an admin, to enable Resource-Context,
you just have to set
the workspace access mode property
to use workspace or resource permissions.
For workspaces that were created after March 2019,
it is owned by default.
Then, make sure that your users don't have workspace access,
and they are good to go.
They can click on a resource or a resource group,
and via the logs menu entry,
run their own queries.
In the context of this resource, always so full.
We recommend using resource-based access model whenever possible,
and not granting users access to the entire workspace.
That would assure granular access to logs in your organization.
>> Thanks Meir. There are
many aerobic options for many different business needs.
Azure Monitor Logs supports everything,
from small organizations that may log only specific events to
very large enterprises that use logs to keep
track of all infrastructure and applications.
Other than what we've covered today,
we have plenty of guides and documentation on these topics.
As you can see at the bottom-left corner of the slides,
we have articles on each topic we've discussed, and many more.
>> Indeed no. Yet the same time,
we're also investing in new functionality.
One topic that is top-of-mind for us,
especially these days, is
monitoring of mission critical workloads.
We will introduce soon functionality like
encryption of data at rest using customer-managed keys,
cluster management, and disaster recovery for workspace.
Keep following us, and we will keep
enhancing Azure Monitor Logs and make it even better.
I hope you all have a good understanding now,
on the first steps in administrating Azure Monitor Logs.
Here are some resources to help you.
Thank you for watching this session.
If you have any further question,
go ahead, ask them now.
We have more deep dive sessions coming up,
so stay tuned and enjoy the rest of the event. Thank you.
[MUSIC]