We now have pretty great NodeNorm ES spans in OTel traces. Along with the rest of Translator, we should figure out the best baggage and attributes to include in this request.
Some ideas for attributes:
- The query parameters (conflations, descriptions, explicit types, etc): will help us identify which settings are particularly slow
- Number of CURIEs being queried: will help us identify how performance varies by number of CURIEs
- Number of (simultaneous?) ElasticSearch queries needed: the trace linked above suggested these are run sequentially -- running them in parallel might be more efficient.
- Cache information: if NodeNorm ES keeps an in-memory cache in front of ElasticSearch, we could track its size/hit ratio here.
Some ideas for baggage (assuming we can retrieve them later; this information might be more usefully collected in the logs rather than in OTel):
- Actual list of CURIEs sent for normalization
- List of CURIEs that could not be normalized (could be useful for identifying incorrect normalization as well as priorities for adding new identifiers)
We now have pretty great NodeNorm ES spans in OTel traces. Along with the rest of Translator, we should figure out the best baggage and attributes to include in this request.
Some ideas for attributes:
Some ideas for baggage (assuming we can retrieve them later; this information might be more usefully collected in the logs rather than in OTel):