Tailing Logs on AEM as a Cloud Service
June 9, 2020In order to monitor or debug AEM environments (or virtually any web environment) one needs data, and that data generally comes from server logs. Adobe’s new AEM as a Cloud Service product, given that it’s entirely a managed web service, does not give you the ability to SSH on to individual containers to view logs, nor does it give you access to any sort of Splunk or Elastic or similar log aggregator.
At this point, to get access to your AEM logs is one of two ways:
- You can download whole logs out of Cloud Manager, and view them on your local, or
- You can use the Adobe I/O Cloud Manager CLI to tail logs on any of your AEM as a Cloud Service instances.
Note: there is a current issue with both the Adobe IO CLI as well as Cloud Manager’s log downloads, that large stack traces will currently be truncated, a limitation coming from the internal Splunk integration that the AEM as a Cloud Service infra uses on the back end to aggregate the logs. (The Adobe team uses Splunk themselves at this stage, but the capability hasn’t been added to turn this over to end users).
That being said, it’s still extremely useful to be able to tail logs on any AEM instance, even if one isn’t able to do critical time-correlation, graphing, historical queries, and all the other things you do with a log aggregator. So, here are the steps to go through to tail logs on an AEM as a Cloud Service environment:
Table of Contents
Step 1: Adobe IO Access for Cloud Manager
The first step you’ll want to check is to make sure your Adobe account is provisioned with access to create a service integration on Adobe IO with Cloud Manager. If you go to https://console.adobe.io with your Adobe ID and create a new project, select “Add an API”. You should see “Cloud Manager” under Experience Cloud in the list of integrations available to you.
If you don’t see Cloud Manager in there (like I didn’t, at first) send an email either to your Adobe Sales rep or to SPP Help (in the case of a Sandbox instance) who can get you sorted.
Step 2: Create an Adobe IO Project for your Cloud Manager (and logs) Access
You’ll then need to create a public/private keypair which generates a new service account (JWT) credential, which you’ll use later on to make your Adobe IO console authenticate to your Cloud Manager env as you. Make sure to save this public/private keypair on your local, as you will need it shortly.
Then, tell the integration what services it will get access to:
And then hit “SAVE CONFIGURED API”.
Step 3: Install the Adobe IO Runtime
This page gives the full installation instructions for installing the Adobe IO runtime. But in short, after installing NodeJS on your workstation, you:
$ npm install -g @adobe/aio-cli
Post install, you should see:
$ aio -v
@adobe/aio-cli/3.5.0 win32-x64 node-v12.18.0
Step 4: Install & Configure the Adobe IO Cloud Manager CLI Plugin
The full install instructions are here, but in short, run:
$ aio plugins:install @adobe/aio-cli-plugin-cloudmanager
Then, after that is installed, you’ll need to get the elements from the Adobe IO integration you created, and paste them into a config.json file which you can use to configure cloud manager. It will consist of:
//config.json
{
"client_id": "value from your CLI integration (String)",
"client_secret": "value from your CLI integration (String)",
"jwt_payload": { value from your CLI integration (JSON Object Literal) },
"token_exchange_url": "https://ims-na1.adobelogin.com/ims/exchange/jwt"
}
Put that file on your workstation, then run the following to configure the credentials:
aio config:set jwt-auth PATH_TO_CONFIG_JSON_FILE --file --json
Then tell it about your private certificate which you saved from Adobe IO above:
aio config:set jwt-auth.jwt_private_key PATH_TO_PRIVATE_KEY_FILE --file
Step 5: Tell AIO what your Default Program Is
Next, tell the Adobe IO runtime what your “Default Program” is. In AEM as a Cloud Service, the “Program” is the collection of environments that make up a single web property. Navigating to my.cloudmanager.adobe.com, you’ll see a URL after logging in like “https://experience.adobe.com/#/@the_cool_name_of_my_company/cloud-manager/home.html/program/{PROGRAM_NUMBER}”
That number at the end is your program number, and you can tell AIO about it like this (assuming “1234” is your program ID):
$ aio config:set cloudmanager_programid 1234
Step 6: List your Environments
Then, running the following command will list the environments in your program that you have access to:
$ aio cloudmanager:list-environments
Environment Id Name Type Description
10001 consulting-sandbox-dev dev Created to experience pain
10002 Consulting-Sandbox-PRD prod Created by Tad Reeves to test AEM as a Cloud Service
10003 Consulting-Sandbox-STG stage Created by Tad Reeves to test AEM as a Cloud Service
Step 7: List Logs from an Environment
Note the number that each of your environments have as an Environment ID. If you use this ID you can list what logs are available for that environment:
$ aio cloudmanager:list-available-log-options 19090
Environment Id Service Name
10001 author aemaccess
10001 author aemerror
10001 author aemrequest
10001 publish aemaccess
10001 publish aemerror
10001 publish aemrequest
10001 dispatcher httpdaccess
10001 dispatcher httpderror
10001 dispatcher aemdispatcher
Step 8: Tail the Desired Log
$ aio cloudmanager:tail-log 10001 author aemerror
09.06.2020 02:20:10.394 [cm-p1234-e10001-aem-author-674d744bf5-q862v] *INFO* [67.189.6.206 [1591669210392] POST /content/dam.initiateUpload.json HTTP/1.1] com.adobe.cq.assetcompute.impl.servlet.InitiateUploadAssetServlet initiate upload asset: Mountain Biking the Uetliberg in Zurich.mp4, size: 74013446, mimeType: video/mp4
09.06.2020 02:20:10.397 [cm-p1234-e10001-aem-author-674d744bf5-q862v] *INFO* [67.189.6.206 [1591669210392] POST /content/dam.initiateUpload.json HTTP/1.1] com.adobe.cq.assetcompute.impl.servlet.InitiateUploadAssetServlet initiate upload complete asset : Mountain Biking the Uetliberg in Zurich.mp4, size: 74013446, mimeType: video/mp4
It’s cumbersome, it has a lot of steps, and no, it’s not Splunk. But it’s far better than nothing and is definitely needed if you’ll be doing any sort of development work on the instance.
Hopefully this helps you out!
Nice blog. A few notes:
* You don’t need to generate the ssh key yourself. The I/O Console will do that. Of course, many people will want to generate it themselves.
* Step 5 is optional. If you don’t do that, you just need to pass the program ID to the other commands.
Thanks for the notes on that Justin. Yep, saw that Step 5 is indeed optional, but it does make for less typing in the future for what amounts to a rather typing-heavy process, which is the main reason I included it. Hopefully, one day, there will be legit log aggregation on this such that one could search & dashboard & alert to their heart’s content. A man can hope.
Great to hear from you though – it’s been a few years.