Detailed Plan
*Set up environment*
Set up a Plutus-starter (with volumes for modified directories) or other PAB container in either docker compose or Kubernetes.
*Logging sidecar*
Build a sidecar for docker compose or Kubernetes that reads PAB logs from either a volume or socket. There will likely not be any service discovery and will have to be configured in YAML for the particular service/pod that is emitting the logs.
This sidecar will be a container image that is configurable through environment variables (which themselves are configurable through either a compose YAML or a pod/deployment YAML). The sidecar will be small and the purpose would be to process the logs and re-output them to either an Elasticsearch cluster.
*Why Elasticsearch?*
Since Elasticsearch is already a RESTful framework, this lends itself well to queries from any frontend and impressive search characteristics. You could put the Elasticsearch cluster behind an API gateway and restrict it based on the project's needs. The purpose of feeding the processed logs into ElasticSearch is that you could define your indexing based on the type of transaction or occurrence on the PAB.
*Existing systems*
Current working PAB on the testnet with the current release of the plutus-apps package. Several contracts (state machine and standard) are written for Loxe inc. as well as PPP contracts that can be used for testing.
*Plan*
Dec-Jan - Describe best outputs for transaction information from PAB and write a guide on Text logs for use in this system.
Dec-Jan - Bring PAB, node, chain index, and wallet-server up on docker compose and Kubernetes.
Feb - build sidecar with YAML configuration for processing logs in standard format.
Mar - Test sidecar with multiple PAB configurations (docker and kubernetes)
Mar - Test configuration for exporting to elasticsearch.
Apr - Test frontend with queries.
*Metrics*
Jan - Working PAB, chain index, node, and wallet-server on testnet in kubernetes cluster (Cost for cluster $400/mo, but for testing approx $200/month since it does not need to be consistently available).
Feb - Logs being viewed by sidecar service
Mar - Logs being consumed by sidecar and ingested into elasticsearch service
Apr - Logs queriable in test frontend in reliable fashion from elasticsearch.