So while working at a customer location we fell into the troubles of trying to confirm what was broken in our environment. You know that period when you see the error, you know there is an issue but you don’t know where the issue exactly comes from. In this particular case, we had a website error which we could see in the content service as another error and this seemed to lead to a discovery service problem. In a nutshell, we could not load a DXA page, this was because, Content Service said "I don’t know this localization", however we could see from Topology Manager that all was right…….. Though in reality all wanted to be left-alone! The question was which of these was really the issue or were these 3 different problems? This is the point in our microservice world where you just want to run the exact URL causing problems in the browser and see whats up? The result was the ever famous (and annoying) "invalid grant" message. OK, I know what invalid means, I know what grant means, but invalid grant, what the ……………. I digress. All I want for Christmas is a valid grant! Is that too much to ask?
Now, "granted", there are ways to work-around this minor hiccup, which includes shutting down OAuth security so that you can get the damn data you need (actually its an error I want ….. but you get the point). Another work around is to simply provide the security requirements so that I can get to the URL directly. This led to the usual focused and painstaking research, (aka googling) and brought me to an article that led me to writing the script below. Following up on this article by the ever loquacious Dominic Cronin, I decided to cook up a script that can simply check if the services are running. So here it is in PowerShell:
#you know what this is right?
[CmdletBinding()]
Param(
[Parameter()]
[string]$discoveryurl = (Read-Host -Prompt "discovery service url")
)
#Default value for discovery url in case you don’t want to type in the prompt
if(!$discoveryurl){$discoveryurl= 'http://localhost:8082/discovery.svc'}
#this is data that you need to get authorization to query the microservices
$params = @{
client_id='cmuser'
client_secret='CMUserP@ssw0rd'
grant_type='client_credentials'
resources='/'
}
#Here I am getting the token service url from the discovery service url. Generally below is true.
$tokenurl = $discoveryurl.Replace( "discovery.svc", "token.svc")
$token = Invoke-RestMethod -Uri $tokenurl -Method POST -Body $params
#based on the line above we can get the Authorization we need
$Authorization = $token.token_type + ' ' + $token.access_token
#List of capabilities to check. Use discovery service storage config to know capabilities you want to check
$Capabilities = @('ContentServiceCapability', 'DeployerCapability', 'PreviewWebServiceCapability', 'WebCapability')
#Phase 1: Check if discovery service is running if not, you can stop……. What? I said stop!
Write-Host("Checking if Discovery Service is alive and kicking")
Try{$dstatus = Invoke-WebRequest $discoveryurl -Headers @{Authorization=$Authorization}
if($dstatus.StatusCode -eq 200)
{
Write-Host "Discovery service working, other services checks now continues"
"=========================================================================="
}
}
Catch{Write-Host $_; Break}
#Phase2: Now we go through each capability find its url from discovery service and test if its running fine then return the result.
ForEach($capability in $Capabilities){
$query = '/Environment/' +$capability
$discoveryUri = $discoveryurl + $query
$result = $null
Try{
[xml]$discoveryData = Invoke-WebRequest $discoveryUri -Headers @{Authorization=$Authorization}
$serviceUrl = $discoveryData.entry.content.properties.URI
$result = Invoke-WebRequest $serviceUrl -Headers @{Authorization=$Authorization}
}
Catch{
Write-Host "There seems to be an issue, please see the exception from " $capability " service:" `
$Error[0].Exception.Message -ForegroundColor Red
Continue
}
if($result.StatusCode -eq 200){
Write-Host $capability " service is working fine"
}
}
The script should give you a simple tool to check the basic health status of your microservices attached to one discovery service. It should also help us to have a foundation to build scripts for more specific needs. We may want to check a specific URL or we may simply want the tool to be more specific to a capability etc.
So about that issue that led to all of these, we fixed it, turns out that discovery service was broken and needed a hotfix. I am not sure you were interested in the end but there you have it! Now go cook up some script, but before that like, comment or contact me about this one.
Top Comments