rectify typos in learning guide

This guide provides a step-by-step procedure to deploy MEC Sandbox in a lab environment for learning and educational purposes. There are two modes of deployment:

1. [MEC Sandbox integrated with a seperate long-term storage VM](#mec-sandbox-with-long-term-storage)

1. [MEC Sandbox integrated with a separate long-term storage VM](#mec-sandbox-with-long-term-storage)

2. [Standalone MEC Sandbox without long-term storage](#mec-sandbox-without-long-term-storage)

Once the Sandbox is deployed, developers can learn how different services are running inside the kubernetes cluster. For each logged in user, a new sandbox instance (essentially a k8s namespace) is created, containing some base platform services as well as MEC Services that are enabled for the selected network scenario. Creation of namespaces and their pods for different users that log into the Sandbox can be monitored using [k9s](https://k9scli.io/).

Playing around with a 'live' deployment of MEC Sanbox offers great insight into the [Software Architecture](../Software-Architecture/README.md) of AdvantEDGE and its different components & subsystems. How different microservices are communicating with each other in the backend can be investigated by interacting with the Sandbox frontend and invoking HTTP requests toward MEC Service APIs using the Swagger UI. See the [wiki page](https://mecwiki.etsi.org/index.php?title=MEC_Sandbox_Help) for more details on how to interact with the Sandbox.

Playing around with a 'live' deployment of MEC Sanbox offers great insight into the [Software Architecture](../Software-Architecture/README.md) of AdvantEDGE and its different components & subsystems. How different micro-services are communicating with each other in the backend can be investigated by interacting with the Sandbox frontend and invoking HTTP requests toward MEC Service APIs using the Swagger UI. See the [wiki page](https://mecwiki.etsi.org/index.php?title=MEC_Sandbox_Help) for more details on how to interact with the Sandbox.

Container logs from pods running the microservices can be a great source of examining the messages and HTTP calls that are being exchanged between different services. To see the logs of a particular pod or a microservice, use the following command:

Container logs from pods running the micro-services can be a great source of examining the messages and HTTP calls that are being exchanged between different services. To see the logs of a particular pod or a microservice, use the following command:

```sh

$ kubectl logs <pod-id> -n <user-namespace-id>

AdvantEDGE uses a Monitoring Engine coupled with Metrics Subsystem

See AdvantEDGE's [Monitoring Subsystem](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/features/monitoring/) for more details on all the components of Monitoring and Metrics subsystems. Just to summarize here, there are four main components of the metrics subsystem:

1. _Prometheus_: time-series database used to collect metrics about platform microservices, number of active sessions, API calls etc.

1. _Prometheus_: time-series database used to collect metrics about platform micro-services, number of active sessions, API calls etc.

2. _InfluxDB_: time-series database to monitor scenario network characteristics, events & custom user metrics

3. _Thanos_: used for storing metrics in an outside object store for long-term storage

4. _Grafana_: used for visualizing data from Prometheus and influxDB

From learning perspective, developers can play around with the deployed MEC Sandbox and simulate different use cases listed [here](../../mec-sandbox-scenarios/Macro-Network-Scenario/README.md#mec-sandbox-use-cases).

There will be an added advantage of being able to inspect container logs from different microservices in the backend, combined with monitoring dashboards for statistics in real time.

There will be an added advantage of being able to inspect container logs from different micro-services in the backend, combined with monitoring dashboards for statistics in real time.

This level of understanding will provide a solid foundation for working on the development of a new feature, i.e., implementting a new MEC service in the MEC Sandbox. See [Development Guide](./development-guide.md) for the next steps in this feature development journey.

This level of understanding will provide a solid foundation for working on the development of a new feature, i.e., implementing a new MEC service in the MEC Sandbox. See [Development Guide](./development-guide.md) for the next steps in this feature development journey.