|
| 1 | +--- |
| 2 | +title: Troubleshoot managed private endpoint connection issues |
| 3 | +description: Troubleshoot connecting a managed private endpoint to a private link service in Azure Managed Grafana. |
| 4 | +author: maud-lv |
| 5 | +ms.author: malev |
| 6 | +ms.topic: troubleshooting |
| 7 | +ms.service: azure-managed-grafana |
| 8 | +ms.date: 04/25/2025 |
| 9 | +ai-usage: ai-assisted |
| 10 | +--- |
| 11 | + |
| 12 | +# Troubleshoot connecting managed private endpoint to a private link service |
| 13 | + |
| 14 | +This article guides you to troubleshoot and fix issues related to connecting a managed private endpoint to a private link service. |
| 15 | + |
| 16 | +## Symptom |
| 17 | + |
| 18 | +Connection from services running on an AKS cluster to Managed Grafana using a Managed Private Endpoint is not working. Users may encounter errors such as **"504 Gateway Time-out"** when attempting to connect. |
| 19 | + |
| 20 | +## Possible causes |
| 21 | + |
| 22 | +The issue may occur due to one or more of the following reasons: |
| 23 | + |
| 24 | +- The managed private endpoint is not approved. |
| 25 | +- The private DNS zone is not configured correctly, leading to DNS resolution failures. |
| 26 | +- Network security group (NSG) rules are blocking the connection. |
| 27 | +- The AKS cluster does not have the correct outbound internet access configuration. |
| 28 | +- The private link service is not properly configured to accept connections from the managed private endpoint. |
| 29 | + |
| 30 | +## Resolution |
| 31 | + |
| 32 | +Follow these steps to resolve the issue: |
| 33 | + |
| 34 | +### Step 1: Verify managed private endpoint approval |
| 35 | + |
| 36 | +1. In the Azure portal, navigate to the **Setting** > **Networking** > **Managed Private Endpoint** section of your Azure Managed Grafana resource. |
| 37 | +1. Check the state of the managed private endpoint. If it's "Pending", approve the connection. |
| 38 | +1. Ensure the private endpoint is connected to the correct private link service. |
| 39 | +1. Verify that the private link service owner has approved the connection request. |
| 40 | + |
| 41 | +> [!NOTE] |
| 42 | +> Two approvals are required: one by the person who created the managed private endpoint and one by the private link service owner. Ensure both approvals are completed. |
| 43 | +
|
| 44 | +### Step 2: check private DNS zone configuration |
| 45 | + |
| 46 | +1. Verify that the private DNS zone is linked to the virtual network where the AKS cluster or other service is deployed. |
| 47 | +1. Ensure the DNS zone contains the correct records for the private link service (e.g., `privatelink.<service>.azure.com`). |
| 48 | +1. Test DNS resolution from the AKS cluster or other service to confirm it resolves to the private IP address of the private link service. |
| 49 | +1. For more information, see [Create and manage private DNS zones using the Azure portal](https://learn.microsoft.com/en-us/azure/dns/private-dns-portal). |
| 50 | + |
| 51 | +### Step 3: Review Network Security Group (NSG) rules |
| 52 | + |
| 53 | +1. Check the NSG rules applied to the subnet where your resource (e.g., AKS cluster or other service) is deployed. |
| 54 | +1. Ensure there are no rules blocking outbound traffic to the private link service. |
| 55 | +1. Add an allow rule if necessary to permit traffic to the private endpoint. |
| 56 | + |
| 57 | +### Step 4: Validate outbound configuration |
| 58 | + |
| 59 | +1. Confirm that your resource (e.g., AKS cluster or other service) has outbound internet access configured correctly. |
| 60 | +1. If using a custom route table, ensure it allows traffic to the private endpoint. |
| 61 | +1. Test connectivity from your resource to the private endpoint using tools like `curl` or `ping`. |
| 62 | + |
| 63 | +### Step 5: Verify private link service configuration |
| 64 | + |
| 65 | +1. Ensure the private link service is configured to accept connections from the managed private endpoint. |
| 66 | +1. Check the private link service's settings to confirm it is correctly associated with the target resource. |
| 67 | +1. Verify that the private link service is healthy and operational. |
| 68 | + |
| 69 | +### Step 6: Analyze Port Configuration for AKS Clusters |
| 70 | + |
| 71 | +If you are working with an AKS cluster, ensure that the port configuration is consistent across the monitored service, the load balancer, and the private link service. Incorrect port configurations can lead to data source connection failures. |
| 72 | + |
| 73 | +For example, for a self-managed Prometheus server running on an AKS cluster: |
| 74 | + |
| 75 | +- The port configuration for the monitored service should follow the structure : access port + protocol + port name (target port). This can be verified in the **Services and ingresses** page of the AKS cluster in the Azure portal. |
| 76 | + |
| 77 | +- The load balancer created for the service should have a matching port configuration: access port + protocol + port number (target port). |
| 78 | + |
| 79 | +If the port configurations do not match: |
| 80 | + |
| 81 | +1. Edit the YAML file for the load balancer to ensure the port configuration matches the monitored service. |
| 82 | +1. Apply the updated configuration to the AKS cluster. |
| 83 | +1. Test the Grafana data source connection to confirm it is successful. |
| 84 | + |
| 85 | +## Related content |
| 86 | + |
| 87 | +- [Troubleshoot common issues](troubleshoot-managed-grafana.md) |
| 88 | +- [Find help or open a support ticket for Azure Managed Grafana](find-help-open-support-ticket.md) |
0 commit comments