In this blog post, it's the kick-off of the AZ-400 notes coming from myself on my experience with studying for the AZ-400 and some help tech tips. The notes under the Tech Tips section will showcase a few of the different things I learn each week and my hope is that it's helpful for you. Even if you aren't taking the AZ-400, this is still information you should know as a DevOps professional in the Azure space.
Right off the bat, the only thing I can say is wow. The AZ-400 really dives into a lot of different areas, which makes sense considering it's an expert level certification.
So far for the first set of studying it's been fun. I'll definitely go over the notes I wrote down below a few times and see if I'm missing anything. There are a few things that I want to further lab, for example, app center crash SDKs.
The biggest gripe for me right now is truthfully, the way things are explained for the exam topics. The screenshot below shows one example.
The above screenshot could honestly mean so many different things. Assess and configure a log frame - what? Which log framework? I mean, there are a ton of logging mechanisms in Azure. Since the AZ-400 is known for not sticking to just Azure, it could also mean another framework. Not to mention if you Google that, you aren't going to come up with a lot of great information. Because the AZ-400 just got updated June 15th, 2020 (14 days ag0), there isn't any AZ-400 information out there that's up to date and valid. Because of that, you're kind of relying on Microsoft to give you proper explanations of what you need to know.
Overall, besides that one gripe, it's been a pretty solid experience so far and I'm learning a ton!
Tech Tips and Study Notes
Logging and Log Aggregation
There are a ton of different implementations for log frameworks. Not just how the logs are logged, but what the underlying operating system offers.
For example, let's take a look at log frameworks for app services. Depending on what type of application is being run and what the underling OS is (Windows or Linux), the logging mechanism and what's offered will be different.
For .NET Windows Apps:
- Trace.TraceError("Message"); // Writes an error message
- Trace.TraceWarning("Message"); // Writes a warning message
- Trace.TraceInformation("Message"); // Writes an information message
- Trace.WriteLine("Message"); // Writes a verbose message
For APT.NET Core (.NET Core) Apps:
- logger.LogCritical("Message"); // Writes a critical message at log level 5
- logger.LogError("Message"); // Writes an error message at log level 4
- logger.LogWarning("Message"); // Writes a warning message at log level 3
- logger.LogInformation("Message"); // Writes an information message at log level 2
- logger.LogDebug("Message"); // Writes a debug message at log level 1
- logger.LogTrace("Message"); // Writes a detailed trace message at log level 0
When you get into running applications from a container in app services, for example, a Node.js app, the logging alters as well. Because you're using a container, the basic logging that's used is redirections, for example, STDERR or STDOUT, plus the Docker logs themselves.
Within an app service, under Monitoring --> App Service logs, you can see the different logging options. For example, below is a screenshot of a Windows OS app service running.
Below is a screenshot that summarizes the different logging capabilities.
For example - below are a few screenshots. The first set of screenshots are a Linux OS running on app services, which doesn't allow for application insights.
The second set of screenshots are from Windows OS's running in app services, which indeed allows application insights.
To enable logging on the Azure Command-Line Interface (AZ CL):
az webapp log config --application-logging true --level verbose --name <app-name> --resource-group <resource-group-name>
Log aggregation is a step in the overall management process in which you consolidate different log formats coming from different sources all into one place to make it easier for you to analyze, search, and report on your data.
For example, take an app service running a Windows OS. When you go to Monitoring --> App Service logs, there will be several log frameworks available.
Under Application Logging and Web server logging, you have the ability to storage the logs inside of a storage account. This provides for log aggregation and the practice of storing logs in one location.
Log Aggregation with Azure Monitor
Azure monitor has several built in ways for having a one-stop-shop of logs. The great thing is, it's built into Azure. Typically with log aggregation, you need to specify where those logs are going. Maybe something like Graylog or Splunk, for example.
With Azure Monitor, you don't have to worry about a third-party tool.
When you go to the Azure Monitor blade, the first thing in the Overview pane is the Get started page. The middle option will show Query & Analyze logs.
Clicking on the blue Search Logs button will bring you to the getting started page for log analytics.
Under the getting started page, you'll see that you can pick a scope based on resource group, or if you drill down, specific resources.
Once you click the blue Apply button, you'll see that there is now an official log in Azure Monitor for the services.
Manage Access to Logs
Azure Monitor stores log data in a Log Analytics workspace. A workspace is a container that includes data and configuration information. To manage access to log data, you perform various administrative tasks related to your workspace.
You can implement access control modes, AKA, who and what has access to the logs, with the following:
- Azure Portal
- Azure PowerShell
- Azure Resource Manager template (ARM)
Access control uses role-based access control (RBAC) for granting users or groups permissions to logs.
The first way is via the UI, which you can do by going into the Log Analytics blade.
Once in the log analytics blade, click on the workspace that you wish to work with.
Under General, click on Properties.
You will now see the Access control mode option.
Automation with code for managing access control is not only faster, but far more scalable. The code via PowerShell can be found here.
App Center Diagnostics is a cloud service that helps developers monitor the health of an application, delivering the data needed to understand what happens when an app fails during testing or in production. The App Center Diagnostics SDK collects information about crashes and errors in your apps and uploads them to the App Center portal for analysis by the development team - eliminating the guesswork about what really happened in the app when it failed.
App Center is outside of the Azure portal and you can interact with it here.
When/if you sign up for App Center, you will see some sample applications for Android and IOS.
Under Android, for example, App Center will give you instructions on how to implement the
AppCenter namespaces for crashing and analytics into the code.