Track mapconfig id / template id in logs

[simon-contreras-deel]

Related to https://github.com/CartoDB/support/issues/2177

[dgaubert]

Why do we need this?

In Kibana we already have this info. Check layergroup_id and named_map_template_id fields.

[simon-contreras-deel]

The idea is to add more info to follow all the mapconfig flow:

• know where the map config was created or instantiated
• know where a template was created and instantiated
• know the relation between template and mapconfig

Makes sense?

[dgaubert]

know where the map config was created or instantiated
know where a template was created and instantiated

Do you mean the Maps API instance? If so, we already have that info. See: event_source_node field.

know the relation between template and map-config

That's more interesting. 🤔

[dgaubert]

You already have a header where the layergroup-id can be used to be added in the log entry. Check:

• https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/api/map/anonymous-map-controller.js#L104
• https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/api/template/named-template-controller.js#L109

[simon-contreras-deel]

Let me explain better:

• know in which request the map config was created or instantiated (now we don't know that, it is important to know when the mapconfig is created)
• know in which request a template was created and instantiated
• know the relation between template id and mapconfig id

With all this info, we can know the lifecycle of a mapconfig / template. The idea is to get more info to investigate lost mapconfigs.

I know I have added template id / mapconfig id in some places where we already have it (for example in the template update or delete where we get them from the URL) but I want to have a consistent place to have the info.

[dgaubert]

Yeah, I know what you want to accomplish here. 😄

Apart from the links that I shared above, which give you most of what you need to be able to add it in the log entry, you'll have to add a new header with the template id (X-Template-Id) when the template is created. Once you have it you need to use those headers to add them in the log entry.

See: https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/api/template/admin-template-controller.js#L135-L144

[dgaubert]

Now I understand better what you want to achieve. I left a couple of comments.

[dgaubert]

we don't need it, do we?

[simon-contreras-deel]

it is the only way I found the get the relation between template and mapconfig. But I see now it is possible using the logic from setLayergroupIdHeaderMiddleware

[simon-contreras-deel]

As I explained in the other comment, it seems more complicated to use the logic from setLayergroupIdHeaderMiddleware instead of saving mapconfig in locals (or simply the id if you see any memory problem)

[dgaubert]

you already have the layergroup token in multiple places:

• The raw token: req.params.token.
• The layergroup and the timestamp: https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/api/middlewares/layergroup-token.js#L13-L14

[dgaubert]

Sorry, I was mixing controllers we are in template.

[dgaubert]

You should use mapConfigProvider.getMapConfig() method instead.

[dgaubert]

In fact, why not move this to setTilerInfoHeader middleware as mapConfigProvider is already set in res.locals which is available in that middleware?.

[simon-contreras-deel]

Ok, I am going to extract the mapconfig id from mapConfigProvider in setTilerInfoHeader

You should use mapConfigProvider.getMapConfig() method instead.

As setTilerInfoHeader happens after all the controller middlewares, if everything goes fine, mapConfigProvider should already have the mapConfig property set and we can avoid doing a new redis request.

[dgaubert]

It's already cached after the first fetch, see:

• https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/models/mapconfig/provider/map-store-provider.js#L37-L39
• https://github.com/CartoDB/Windshaft-cartodb/blob/master/lib/models/mapconfig/provider/named-map-provider.js#L58-L60

Please, use the public interface methods. The member .mapConfig should be private...