Injest AEM logs into Dynatrace

[#1]

Request for Feature Enhancement (RFE) Summary:	Enable log collection from Adobe Experience Manager (AEM) in Dynatrace as part of the monitoring integration
Use-case:	We have successfully integrated Dynatrace with Adobe Experience Manager (AEM) for performance and application monitoring. However, the current integration does not support log collection from AEM servers. Having the ability to collect and analyze logs directly within Dynatrace would significantly enhance our monitoring and troubleshooting capabilities.
Current/Experienced Behavior:	Dynatrace is integrated with AEM for monitoring, but logs from AEM servers are not being collected, as this feature is not supported. We previously created a support ticket about this, and we were advised that currently, there is no solution for log collection through Dynatrace in AEM
Improved/Expected Behavior:	We expect Dynatrace to support log collection from AEM servers, in addition to the existing monitoring features. This would allow us to have a more unified and efficient approach to monitoring and troubleshooting within Dynatrace
Environment Details (AEM version/service pack, any other specifics if applicable):	Adobe Experience Manager 6.5.19.0
Customer-name/Organization name:	BT ENTERPRISE
Screenshot (if applicable):
Code package (if applicable):

[#2]

@btnikhil 

Thanks for proposing this idea.

This has been reported to the engineering under the internal reference SITES-25113. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to the Jira status.

[#3]

@kautuk_sahni By the way: as it is, the https log forwarder is almost but not quite able to ingest data into dynatrace. The only problem is that Dynatrace returns a status code 204 but the https log forwarder rejects that and expects http 200. By temporarily introducing a reverse proxy that changes http status 204 into 200 we could log forwarding to Dynatrace work. So it'd be very beneficial if you make that little change - after all, there is no real reason for the https forwarder to reject 204, right? It doesn't need actual response content, anyway.

Thanks and best regards,

Hans-Peter Störr