Monitoring and Troubleshooting

Azure tools

You can track CPU and memory usage by checking the PLM containers in the Azure Portal at AKS Cluster dashboard > Monitoring > Insights > Containers.

Troubleshooting

Logs

To troubleshoot issues with PLM, use logs from the corresponding Kubernetes Pod. Kubernetes logs must be configured to be consolidated in an Azure Log Analytics workspace. The PLM Pod writes approximately 200 megabytes of logs weekly. More than 90% of them contain information about health check requests.

Logging Format

Action Log

The Action Log allows you to track all changes made to PLM. In the Action Log, you can find the following information:

• Action type

• Date and time

• The operation status

• The user that performed an operation

• The service to which an action is related.

To access the Action log, complete the following steps:

1. In your UX1 for Providers, click Account > Action Log.
2. Click a log string to drill down to detailed information.

Performance

If the back-end container runs out of memory, you can allocate more by adjusting the resources.limits.memory and javaopts values of the Helm release.

Importing an Excel file

During import of an excel file PLM creates the applyConfig task and delegation tasks, which can be seen in the OSS task manager. Each task belongs to a particular queue.

• applyConfig in the PL:<product_line_id> queue is the configuration task at the plan owner level (usually, this is L0). A product line is represented as a service template in the classic panel. So, the product line ID is the service template ID.

• The delegation routine in the PL:<product_line_id> queue is a set of configuration tasks one level below the plan owner level if plans were shared with operating units or regular resellers by configuring the OpUnit_<CountryCode> or ResellerGroupName_(1...N) columns respectively in the ServicePlans sheet. This routine is started after the applyConfig task is successfully completed.

• The delegation routine in the R:<op_unit_id> queue is a set of configuration tasks one level below the operating unit level if plans were shared with resellers configured under the operating unit in the OpUnitServicePlans sheet. This routine is started after the delegation routine in the PL:<product_line_id> queue is successfully completed.

The delegation routine includes the following four tasks:

• delegate: configures plans for operating units or regular resellers and initiates synchronization of all involved resellers. This task can be rescheduled several times if any activity takes longer than 30 minutes.

• waitSync: waits for synchronization completion for all involved resellers. This task can be rescheduled multiple times after every addition of information on a number of non-synchronized resellers and IDs of those resellers.

• selfManage: copies plans delegated to operating units. This task can be rescheduled multiple times if the operation takes longer than 30 minutes.

• customize: customizes plans delegated to operating units (publication statuses and T&Cs), and delegates the customized plans to resellers of these operating units.

For example, if you want to share plans with the following accounts at the L1 level: three operating units and two resellers, the total number of created tasks will be 2*4 + 3*4 = 20.

If you additionally want to delegate plans to three L2 resellers of one of these operating units, the total number of tasks will be 2*4 (two L1 resellers) + 2*4 (two operating units) + 1*(4 + 3*4) (one operating unit with three L2 resellers) = 32.

12 additional tasks will be scheduled by the customize task for the operating unit with three L2 resellers.