August, 28 2019

[buskamuza]

Please add your topic as a comment to the issue. Use following format:
Topic description and link to PR, if any (duration in min)

Time: 10:30am CST/CDT

BlueJeans Meeting - https://bluejeans.com/7385677850

🎥 Recording

[buskamuza]

Problem Statement
There is an issue with some customers having thousands, hundreds of thousands and sometimes more one million of files in <magento_root>/var/report. In this case, there are so many files that it is impossible to work with them, and in some cases, it is very difficult to remove. This problem is especially relevant for Magento Cloud because Magento Cloud uses GlusterFS for sharing catalogs.
In connection with this problem, the task was set to reduce the number of report files.
Use Cases
This situation occurs if developers ignore the exception in the exception logs and existing report files.
Naturally, the presence of a report or community in the exception logs should be evaluated by the developer as a mistake with a higher priority and should be fixed immediately, but in reality, this is not so.
Sometimes the careless attitude of developers to projects and journaling leads to the fact that the log files and reports for a day grow to incredible sizes, I'm talking about hundreds of gigabytes. Which leads to the fall of the project.
Solution
I suggest the following solution
To create only unique reports and associate them with the corresponding message in the exception log. For communication, to use a hash that will be generated using exception trace, exception message, $_SERVER['REQUEST_URI'] и $_SERVER['SCRIPT_NAME'].
The hash will be used to name the report file. The hash will be indicated in the report and in the exception log message
In this way, we save a chronology of exceptions in the exception log and associate reports with them. This report will be unique to each request.

A proposal document is coming.

[buskamuza]

GraphQL - Generic Filtering Proposal

[buskamuza]

Meeting minutes:

• GraphQL - Generic Filtering Proposal
  • @zetlen : we need attributes in GraphQL schema so it's possible to optimize PWA application at build time
• Logging
  • ✅ @joni-jones : Look at Adobe logging
  • ✅ @kandy : we're going to remove reporting, keep only exception.log. Involve PO
  • @kokoc : have only one exception.log
  • @jemccabe : Logs may be centralized to levels and not individual, with log rotation implemented
  • @jemccabe : We should have stack trace logged somewhere
  • DevDocs have recommendation on post-installation to setup log rotation
  • @melnikovi : add some tooling for logs monitoring/visualization
  • @melnikovi : look at OM confusing stack trace
  • ✅@jemccabe : Docs on best practices of configuring the system, with logs aggregation, log streaming, metrics, monitoring, etc.
  • @jemccabe logs should be structured for better consumption into a log aggregation and
    analytics systems
  • @melnikovi : Talk to Data team if they need any data from those logs