Hi guys,
Does anyone here know if it's possible to track AEM's installation progress from any of the logs? From the stdout.log I can tell when the installation started and when it finished, but I was unable to find a way to track the installation progress from the logs the same way the installation progress is tracked in the window that pop ups when you install aem with the "-gui" option.
Needless to say being able to track installation progress from logs is awfully useful in automation scripts.
Any ideas?
Thanks,
何塞.
Solved! Go to Solution.
Just looking at the logs for certain statements might be sufficient, but it's not a very elegant way. I don't think that it's reliable enough and start levels are also just an Apache Felix thing.
Also the framework is dynamic in a way, that services come and go, and this is not reflected in startlevels.
Instead I would propose that you query the capabilities of AEM in a way, that you say "I need the services X, Y and Z to function properly" and implement that into a Sling Healthcheck. And then you can query this healthcheck if you want to know if the system is ready. And this appraoch is universally applicable.
Views
Replies
Total Likes
Hi,
You can check error.log
Views
Replies
Total Likes
Dear Jose,
++ To Arun's Answer,
Grep in log "[Workflow Starter Thread] com.adobe.granite.workflow.core.launcher.WorkflowLauncherListener Startup finished, workflow queue processing starting" once this message get's printed it means that your instace is ready to process your requests.
Additionally, AEM Community has not been sleeping for the past few years of DevOps activity, there are plenty of automation's already available as open source projects[0], community does it in a slightly different way, simply make request to health servlet and wait until it becomes actives or wait for process specific state as reported by services, please do check examples for reference implementations:
~Chef (Credit Jakub Wądołowski)
# ---------------------------------------------------------------------------
# Wait until CQ is fully up and running
# ---------------------------------------------------------------------------
ruby_block "cq-#{local_id}-start-guard" do # ~FC014
block do
require 'net/http'
require 'uri'
# Pick valid resource to verify CQ instance full start
uri = URI.parse(
"http://localhost:#{node['cq'][local_id]['port']}" +
node['cq'][local_id]['healthcheck']['resource']
)
# Start timeout
start_timeout = node['cq']['service']['start_timeout']
# Save current net read timeout value
current_http_timeout = node['cq']['http_read_timeout']
response = '-1'
start_time = Time.now
# Keep asking CQ instance for login page HTTP status code until it
# returns 200 or specified time has elapsed
while response != node['cq'][local_id]['healthcheck']['response_code']
begin
# Reduce net read time value to speed up start guard procedure
node.default['cq']['http_read_timeout'] = 5
response = Net::HTTP.get_response(uri).code
Chef::Log.debug("HTTP response: #{response}")
rescue => e
Chef::Log.debug(
"Error occurred while trying to send GET #{uri} request: #{e}"
)
ensure
# Restore original timeout
node.default['cq']['http_read_timeout'] = current_http_timeout
end
sleep(5)
time_diff = Time.now - start_time
Chef::Log.debug("Time elapsed since process start: #{time_diff}")
abort "Aborting since #{daemon_name} start took more than "\
"#{start_timeout / 60} minutes " if time_diff > start_timeout
end
Chef::Log.info("CQ start time: #{time_diff} seconds")
end
action :nothing
end
File: definitions/cq_instance.rb:288
[0] GitHub - jwadolowski/cookbook-cq: Chef cookbook for Adobe CQ (aka AEM)
~Puppet (Code credit to Bryan Stopp)
# Checks the system to for a state, loops until it reaches that state
def monitor_site(desired_state = :on)
# If context root is not blank, need to ensure URI has a trailing slash,
# otherwise the system redirects, thus shutting down before installation is complete.
uri_s = "http://localhost:#{@property_hash[:port]}/"
uri_s = "#{uri_s}#{@property_hash[:context_root]}/" if @property_hash[:context_root]
uri = URI.parse(uri_s)
Timeout.timeout(@property_hash[:timeout]) do
Kernel.loop do
begin
response = Net::HTTP.get_response(uri)
case response
when Net::HTTPSuccess, Net::HTTPRedirection, Net::HTTPUnauthorized
return if desired_state == :on
end
rescue
return if desired_state == :off
end
sleep @property_hash[:snooze]
end
end
end
lib/puppet/provider/aem_installer/default.rb:123
~Ansible (Credit Tobias richter)
- name: Start AEM.
service:
name: "{{ aem_service_name }}"
state: started
register: aem_service_start_result
- name: "Wait for AEM startup. [{{ inventory_hostname }}]"
uri:
url: "{{ aem_service_login_url }}"
return_content: yes
register: result
until: result.content.find("QUICKSTART_HOMEPAGE") != -1
retries: "{{ aem_service_timeout // 10 }}"
delay: 10
when: aem_service_start_result.changed
tags:
- skip_ansible_lint
[2] ansible-aem-service/start_aem.yml at master · wcm-io-devops/ansible-aem-service · GitHub
Hope it helps with your implementation!
Regards,
Peter
Hi guys,
Thanks for replying. Just to clarify, I already knew how to check if my AEM instance is up and running. What I'm asking is rather how to check the progress of the installation in the logs, kinda like what you see on the pop up when you run aem with the -gui option.
Something that would allow me to read a percentage % progress on the overall installation. I thought perhaps there would be something in the logs, but so far I haven't been able to find any information in the logs that would allow me to determine the installation progress (percentage %).
If it's not in the logs, is it recorded or reported somewhere else?
Thanks again for your ideas!
何塞.
Views
Replies
Total Likes
Hello,
AEM operates on the basis of bundles and the progress of AEM install can be measured based on the STARTLEVEL reached for those bundles.
The STARTLEVEL ranges from 1 to 30 and messages such as the following can help give you an understanding of how far AEM is along the installation process. And then you'd see a message stating Startup finished in certain number of seconds confirming the 100% install.
08.10.2018 13:26:38.763 *INFO* [FelixDispatchQueue] org.apache.felix.framework FrameworkEvent STARTLEVEL CHANGED to 11
08.10.2018 13:29:44.274 *INFO* [FelixDispatchQueue] org.apache.felix.framework FrameworkEvent STARTLEVEL CHANGED to 30
08.10.2018 13:29:44.274 *INFO* [FelixDispatchQueue] org.apache.felix.framework Startup finished in 203461ms
I'd go by getting this %age by taking the <STARTLEVEL reached>/30
I hope this helps.
Best Regards,
Aneet Arora
Hi Aneet,
Thanks! That's a very useful response. One more question. Is there a way to get the maximum number of STARTLEVELs from some config file? I was trying to find some documentation on this but didn't find any.
Thanks again for your help.
何塞.
Views
Replies
Total Likes
Hi Aneet,
Thanks! That's a very useful response. One more question. Is there a way to get the maximum number of STARTLEVELs from some config file? I was trying to find some documentation on this but didn't find any.
Thanks again for your help.
何塞.
Views
Replies
Total Likes
Just looking at the logs for certain statements might be sufficient, but it's not a very elegant way. I don't think that it's reliable enough and start levels are also just an Apache Felix thing.
Also the framework is dynamic in a way, that services come and go, and this is not reflected in startlevels.
Instead I would propose that you query the capabilities of AEM in a way, that you say "I need the services X, Y and Z to function properly" and implement that into a Sling Healthcheck. And then you can query this healthcheck if you want to know if the system is ready. And this appraoch is universally applicable.
Views
Replies
Total Likes
Thanks Jörg!
One more quick question. The progress bar on the pop up window when you run AEM with "-gui", do you happen to know how it calculates the progress?
何塞.
Views
Replies
Total Likes
I don't know. But I would assume that it's more a hack than an elegant solution :-)
Views
Likes
Replies