-
Notifications
You must be signed in to change notification settings - Fork 22
Feat: use azure go sdk to get diagnostics settings #100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR migrates diagnostic settings retrieval from Azure CLI commands to Azure Go SDK, providing a more efficient and native approach to Azure resource interaction. The changes centralize Azure client management and improve performance through a shared client instance.
Key Changes:
- Shared Azure client initialization in the server service
- Migration from Azure CLI to Azure Go SDK for diagnostic settings operations
- Updated handler functions to accept Azure client parameters
Reviewed Changes
Copilot reviewed 10 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
internal/server/server.go | Centralized Azure client creation and shared across resource handlers |
internal/components/monitor/registry.go | Updated documentation with clearer parameter examples for diagnostics operations |
internal/components/monitor/handlers.go | Modified monitoring handler functions to accept and use Azure client parameter |
internal/components/monitor/diagnostics/handlers.go | Replaced Azure CLI calls with Azure SDK client for diagnostic settings retrieval |
internal/components/monitor/diagnostics/workspace.go | Migrated diagnostic settings parsing from JSON to native Azure SDK structures |
internal/azureclient/client.go | Added diagnostic settings client and GetDiagnosticSettings method with caching |
go.mod | Added Azure Monitor SDK dependency |
Test files | Updated test calls to include nil Azure client parameter for testing scenarios |
Comments suppressed due to low confidence (3)
internal/components/monitor/diagnostics/workspace.go:20
- The variable name 'azureClient' is redundant since there's already a parameter 'azClient'. Consider renaming to 'client' or 'actualClient' to avoid confusion.
var azureClient *azureclient.AzureClient
internal/components/monitor/diagnostics/workspace.go:102
- The variable name 'azureClient' is redundant since there's already a parameter 'azClient'. Consider renaming to 'client' or 'actualClient' to avoid confusion.
var azureClient *azureclient.AzureClient
internal/components/monitor/diagnostics/handlers.go:34
- The variable name 'azureClient' is redundant since there's already a parameter 'azClient'. Consider renaming to 'client' or 'actualClient' to avoid confusion.
var azureClient *azureclient.AzureClient
diagnosticResult, err := HandleControlPlaneDiagnosticSettings(params, cfg) | ||
// Get diagnostic settings using Azure SDK | ||
ctx := context.Background() | ||
diagnosticSettings, err := azClient.GetDiagnosticSettings(ctx, subscriptionID, clusterResourceID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM in general, but curous is the CLI results in a different format from API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the results are same, but in JSON format.
originally, it is handled by below codes, which looks ugly
for _, settingInterface := range settings {
if setting, ok := settingInterface.(map[string]interface{}); ok {
// Check if this setting has logs configuration
if logs, ok := setting["logs"].([]interface{}); ok {
// Check each log category in this setting
for _, logInterface := range logs {
if logConfig, ok := logInterface.(map[string]interface{}); ok {
if category, ok := logConfig["category"].(string); ok && category == logCategory {
if enabled, ok := logConfig["enabled"].(bool); ok && enabled {
// Found the category and it's enabled, now get workspace and table mode
workspaceResourceID, ok := setting["workspaceId"].(string)
if !ok || workspaceResourceID == "" {
continue // Skip if no workspace configured
}
// Determine table mode from logAnalyticsDestinationType
isResourceSpecific := false
if destinationType, ok := setting["logAnalyticsDestinationType"].(string); ok {
isResourceSpecific = strings.ToLower(destinationType) == "dedicated"
}
// Get diagnostic setting name for debugging
settingName := "unknown"
if name, ok := setting["name"].(string); ok {
settingName = name
}
// Debug log which setting and workspace is being used
log.Printf("Using diagnostic setting '%s' for log category '%s' in cluster '%s': workspaceId=%s, destinationType=%s, isResourceSpecific=%t",
settingName, logCategory, clusterName, workspaceResourceID,
setting["logAnalyticsDestinationType"], isResourceSpecific)
return workspaceResourceID, isResourceSpecific, nil
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, that's a good catch. We don't have a pre-defined data structure, and defining our own may not be a good option as it may change reguarly. Using SDK would fix those issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
it will be easier to handle the output of diagnostics setting when using golang sdk, and it also have cache mechanism.