Logs are for humans, metrics are for machines.

Metrics tell you there's a problem. They're an application's way of reporting metadata or state. They are designed to be small and frequent and machine readable/writeable, with small bits of useful information that are of themselves quite useless, but are very useful in aggregate.

Logs describe the problem in detail to a human. They're a developer's way of diagnosing problems in an application. They can have machine-readable components to them, but being machine-readable is not the point. The point is for a human to quickly diagnose and fix an arbitrary problem, however you decide to do that. It's extremely annoying if you can't read a log because it was machine-formatted.

From the article:

  Invest time in designing your log structure

Don't. Eventually you will have to deal with logs with a random structure. Invest in telemetry management and distributed tracing.

  Log as much as possible.

Don't. It's about quality, not quantity. Too many logs with too little information leaves you buried and unable to diagnose quickly. And too much information is bad for security; always mask sensitive information. I can't tell you how many giant companies have been hacked because of this. And cost is a factor: I have seen people stop logging because it was costing them too much money, when they should have been logging smarter (fewer messages with more useful info) and utilizing metrics.

  Keeping consistency is everone’s priority

It is guaranteed that you will have to deal with some metrics and logs in arbitrary formats. Do not worry about making them perfect. Invest in telemetry management and distributed tracing.