OK. This is a bunch of issues. I'm going to make multiple replies
1- the error in getRuleSnapshot
On older AES releases, when AES creates a case, it tries to look up the rule closest associated with the core issue of the case and bring in various information including who last touched the rule and generated java from the rule. The rule snapshot is retrieved by making a connect-SOAP to the node that first reported the alert / exception that hast triggered case case creation. The code assumes that the PegaAES-Data-Nodes record for that node has the proper fully qualified URL of the PRSOAPServlet for the node, and the node is accessible for SOAP calls from AES. In your case, the node record(s) have the literal "[unable to determine]" and the code is being stupid and trying to SOAP there, triggering an exception. The simplest way to stop these alerts is to go into the admiminstration harness, look at the AES settings for each system, and uncheck the option to get rule information.
2 - Problem saving Java source file to filesystem - java.io.IOException: No space left on device
This server is not configured properly. Pega engine builds code from rules by generating Java code, compiling the code into classes then storing most of the generated classes into the database for future re-use (there is some stuff that is generated and accessed locally, but that doesnt change the main theme). The drive / file-system that has the PRGenJava and PRGenClasses directory (under the pega tempdir tree) is out of space
If you've had compilation and generation issues, I question the integrity of the rule base and the code stored to pr_assembledclasses. You might need to down system, truncate the cache and generation tables, and let everything regenerate after restart. Contact GCS for instructions for "killing the caches" and "assemblies"
now that one's a mystery. HTTP data is commonly sent in chunks to application server. Application server has not received the full data for a POST - there is an invalid chunk header This exception is happening prior to Pega engine processing the POST so there's not much in Pega to offer guidance. Look to load balancer or firewall -- enabling logging outside of PRPC, search for HTTP 503 response messages from Pega, and try to find both patterns in source IP or URL with errors,