Hello my dear readers 
During my customers visits the very question I get is: I am using Azure Monitor to monitor my workloads; how can I split monitoring costs across projects?
Given the question, the answer is not too difficult but may vary depending on the architecture and the monitoring targets which are part of the scenario.
To better explain, chargeback, this is what we are talking about, can be easily done when all the resources are Azure resources and monitoring data is sent to specific separate workspaces. In this situation all you have to do is to use either Cost Analysis or Usage and Estimated Costs.
Given the above, that we will name scenario #1, what if instead of separating workspaces we would like to concentrate monitoring data into a single one like the schema below?
This can be hence considered the scenario #2.
But this is not enough. I would like to add some more complexity. I would like to consider as scenario #3, resources, like virtual machines, hosted on-prem and/or on 3rd party cloud providers.
How to calculate the chargeback in this case?
Given the simplicity of scenario #1, let’s skip it and start focusing on scenario #2 for which we need to introduce a key concept: the concept of resourceId property. For those who are not familiar with it, you can simply look at this key property as the “unique identifier of a resource” which in short correspond to the path of the given resource starting with the subscription and ending with the resource itself.
This property is native and hence embedded into any Azure resource. Leveraging the format of ResourceId, in particular the resource group part, and assuming that your infrastructure has had a good governance, we can make the assumption e that every project correspond to a management group.
This way, it makes really easy to calculate and assign cost for ingested billable data. All you have to do is to make a sum of the amount of billable data coming from the given resource group and multiply it by the Azure Monitor rate. (the public rate upon which you will apply your discount if any). To perform that math, you can create your Log Analytics query similar the one below in which I am calculating Log Analytics cost for my projects:
// ## Cost analysis by project where a project correspond to a Resource Group logging to a centralized workspace
// specify the resource Group name
let rgName = dynamic(["ch1-fabrikamrg", "myProjectBasedResourceGroup"]);
let excludedTables = dynamic(['Usage','myOtherTable']);
union withsource=table *
| where TimeGenerated > ago(31d)
| where table !in (excludedTables)
| extend projectRG = toupper(tostring(split(ResourceId,"/")[4]))
| where projectRG has_any (rgName)
| where _IsBillable == true
| summarize recNum = count(), GBytes=((sum(_BilledSize))/1000/1000/1000) by projectRG
// public price in €€
| extend costInEuro = (GBytes*2.694)
// public price in $$
| extend costInDollar = (GBytes*2.99)
| project TimeGenerated=now(), ResourceGroup = projectRG, recNum, GBytes, costInEuro, costInDollar, Note = "Decimal separator is set according to your regional settings for the Azure Portal."
Using the above on a sample log analytics for the Fabrikam projects, I would get the situation in the sample screenshot below:
So far, things looks easy enough. Time to focus on scenario #3 then. The biggest difference between scenario #3 and the other two is that, regardless the centralized or de-centralized approach, we were speaking azure resources. Servers hosted on-prem or on 3rd party clouds, are not azure resources hence monitoring data they send, will not include ResourceId property field.
In this scenario we will have to introduce a good actor called Azure Arc-enabled servers.
As short description, Azure Arc-enabled servers projects your on-prem and/or 3rd party cloud providers servers (either physical or virtual machines) into Azure as it was an Azure resource. As part of this projection, each connected machine will have a ResourceID enabling the machine to be included in a resource group.
This is exactly what enable us to calculate costs using the same approach of scenario #1 and #2.
To connect or onboard what is often referred as to hybrid machine, you can refer to Azure Connected Machine agent deployment options.
It should be noted that having to onboard the servers, these can be organized into different resource groups corresponding to the various projects. Should you need some reference on how to build a foundation for your onboarding journey, you can read the Plan and deploy Azure Arc-enabled servers documentation.
Once we got the stage where all your non-Azure (or hybrid) resources have the ResourceId, meaning everything in scope has been onboarded onto Azure Arc-enabled servers, the above query can still be used to do your chargeback for non-Azure resources monitored through Azure Monitor.
Hope this will help and enable you to estimate the chargeback as necessary, and remember that the official total amount is alone and alone the one appearing on the bill created by Azure 
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.