We want to promote APIs to adhere to Observability team's move to a common logging schema.
Make sure the logging in example-node-api adheres to this, and to do so we would need to update service-runner to do so. Document it as a requirement in the API notes.
ECS documentation: https://doc.wikimedia.org/ecs/
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hnowlan | T324222 Featured content feeds are returning 404 | |||
| Open | None | T324231 Add monitoring of API endpoints for API gateway | |||
| Open | None | T290772 Make logging adhere to common logging schema |
@Eevans We want the api platform to make sure it promotes ECS logging. But to do so, we'll need to change service-template-node and therefore service-runner. It's still worthwhile to do so while service-scaffolding-node (and consequently the future logging module) dont yet exist, right?
I think so. One thing we should work to figure out during CodeJam is what to do with existing projects, but presumably it means some period where the old s-t-node is deprecated. Depending how long the tail is on that deprecation window, you might want existing projects to start using ECS.
Or... maybe a librar-ized code that includes support for ECS is the right impetus for migrating older code bases? Maybe instead of updating s-t-node/service-runner and having folks do the merge dance, you have them step through the conversion to the new library?
Or... maybe a librar-ized code that includes support for ECS is the right impetus for migrating older code bases? Maybe instead of updating s-t-node/service-runner and having folks do the merge dance, you have them step through the conversion to the new library?
Ya ok I think that makes a lot more sense too, instead of patching what exists, spending the time to do it right and make a js version of your golang logger.